From patchwork Fri Oct 5 08:13:24 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ard Biesheuvel X-Patchwork-Id: 10627595 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 2FE5E15E2 for ; Fri, 5 Oct 2018 08:14:57 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 26FFE29272 for ; Fri, 5 Oct 2018 08:14:57 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 1AFD229286; Fri, 5 Oct 2018 08:14:57 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=unavailable version=3.3.1 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 2A0E629272 for ; Fri, 5 Oct 2018 08:14:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:MIME-Version:Cc:List-Subscribe: List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id:Message-Id:Date: Subject:To:From:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Owner; bh=PnkLNkwYkW+N6+f1Dj8CaVpao/1zhjP9uCD7FJ/1f34=; b=nmz a1xQxsTP2KsXA0ayWsN2HYaJ2CF9S0/KfvpsZFJhyhXraaSO5sBLyq87mkXF5T0lWi38FOiHCIaRQ KbcG1k1MsUKaA4p68dd6vZ4Smiy9z1uuWc8xGYP4kBM/RyNi+4GUl+0RddDfb3g2k2as7ICcJ2wr2 ms9y8KOGKmVJjsNkr1yCD8+amET0w9sNiJUeV0X8lRSEzRYhSKM6i4nzvHHqmobIGSNjhmj5sNHha BHEV1ybuibQw6u3YJi2Zt1P4r0TWpnvYQMU1egxC1eWAAgZg7fsTYbq/dfMf5m8HXk0cRNHr0W7/B HG3OYEGPXcaBIzJUJXlfr+NabYhS9sA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1g8LFw-0005LL-GW; Fri, 05 Oct 2018 08:14:40 +0000 Received: from mail-wr1-x443.google.com ([2a00:1450:4864:20::443]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1g8LF8-0004xQ-Bu for linux-arm-kernel@lists.infradead.org; Fri, 05 Oct 2018 08:13:56 +0000 Received: by mail-wr1-x443.google.com with SMTP id y11-v6so1834360wrd.4 for ; Fri, 05 Oct 2018 01:13:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id; bh=KnHDBIUvlzt9rTbfCGWIVDG2qN/TNs+CUrI8dKvj7bI=; b=dcth4H3ROnKOQyOKfGZ3wqLPn8mtEolJcGhLyx8/0zKIcQk4TJIm7O7z4G7SlOSTnz ADXuQ1jpCFX+vFMMbgmBjMQkAEEQ3illmAB8I++XTVHTRcT2xR7sGGL04uEWMhdHhSOY r+yZxtiB9ejQw2hkDIA3w4InTwEjYyP2DEysE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=KnHDBIUvlzt9rTbfCGWIVDG2qN/TNs+CUrI8dKvj7bI=; b=O7R86Y47cIRwi39JP5W/8ieJn1T+ZypFy5HOQIz2l0BOYOtHijj1WI4SRYPXfZd5bJ d97nZ0JpGUI6DKPgctxYtrSHaIivwil15xXAgrQp2R8jTL6SP5UYbAkcnXHpqh2XJVum qyAbNu1jZuEd4bRokKYtWfSIYzZ3iHXPyO6jnyPQeL0zxNC0np5s0aKks2Gs1qx3g5Vb T6m9BMejzpz6kX1xgJtW5rEzj1OQnxyAjT7F2Z53g2bzfpiGj6H7Ss5f8sFqSpIKhGRp Sl6gRDhmPx33dWsbUv5d8QF7ahUFJGT78UJr0W79PBGgw1obZG8jvoSg2/Yla6z+zeB5 kpkA== X-Gm-Message-State: ABuFfogU+Bm0xtOPaBsJGa5hFTA+M4gwmLqOSLm9zPqLAnXKzOoQuEjT LfqOpYB4nQzYqi9AXEhkYCyVCg== X-Google-Smtp-Source: ACcGV63IEf58R+KLekGZgZT0K0BuHu6Zlug6fS+8p3vaemq45QqA8lsXEqdU7RfrP0IjMws0XPZRLA== X-Received: by 2002:adf:8523:: with SMTP id 32-v6mr7729900wrh.72.1538727218578; Fri, 05 Oct 2018 01:13:38 -0700 (PDT) Received: from localhost.localdomain ([2a01:cb1d:112:6f00:697e:67d9:a05d:22c7]) by smtp.gmail.com with ESMTPSA id t4-v6sm6565620wrb.45.2018.10.05.01.13.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Oct 2018 01:13:37 -0700 (PDT) From: Ard Biesheuvel To: linux-kernel@vger.kernel.org Subject: [RFC PATCH 0/9] patchable function pointers for pluggable crypto routines Date: Fri, 5 Oct 2018 10:13:24 +0200 Message-Id: <20181005081333.15018-1-ard.biesheuvel@linaro.org> X-Mailer: git-send-email 2.11.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20181005_011350_453143_40C88CA5 X-CRM114-Status: GOOD ( 25.67 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "Jason A . Donenfeld" , Peter Zijlstra , Catalin Marinas , Will Deacon , Samuel Neves , Paul Mackerras , Herbert Xu , Richard Weinberger , Eric Biggers , Ingo Molnar , Benjamin Herrenschmidt , Kees Cook , Arnd Bergmann , Andy Lutomirski , Thomas Gleixner , linux-arm-kernel@lists.infradead.org, "Martin K. Petersen" , Ard Biesheuvel , Greg Kroah-Hartman , linux-crypto@vger.kernel.org, Michael Ellerman , Andrew Morton , linuxppc-dev@lists.ozlabs.org, "David S. Miller" MIME-Version: 1.0 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Virus-Scanned: ClamAV using ClamSMTP Linux's crypto API is widely regarded as being difficult to use for cases where support for asynchronous accelerators or runtime dispatch of algorithms (i.e., passed in as a string) are not needed. This leads to kludgy code and also to actual security issues [0], although arguably, using AES in the wrong mode can be done using any kind of crypto abstraction. At the moment, the Zinc library [1] is being proposed as a solution for that, and while it does address the usability problems, it does a lot more than that, and what we end up with is a lot less flexible than what we have now. Currently, arch specific implementations (based on SIMD or optimized assembler) live in arch/*/crypto, where each sub-community is in charge of its own specialized versions of the various primitives (although still under the purview of the crypto maintainer). Any proposal to change this model should be judged on its own merit, and not blindly accepted as the fallout of cleaning up some library code. Also, Zinc removes the possibility to plug different versions of a routine, and instead, keeps all versions in the same module. Currently, the kernel's module support permits user land to take charge of the policies that decide which version to use in which context (by loading or blacklisting modules). Instead, Zinc moves to a model where the policy is hardcoded into the module (e.g., ChaCha20 on ARM uses NEON unless on Cortex-A5 or A7). In the ARM community, we have always attempted to avoid hardcoding policy like that: the ARM SoC space is a very heteregeneous one, and putting policy like that into the code will lead to an endless stream of patches from silicon vendors that want tweaks for their cores into various parts of the kernel. Creating monolithic modules for algorithms also makes it very difficult to support driver based implementations. The kernel's driver model is heavily based on modules, using alias strings to match drivers against the hardware. As an example, there ARM ST platforms that support synchronous hardware based CRC32, and plugging that into the monolithic Zinc model is difficult if not impossible. The primary justification for moving away from the module system is that it depends heavily on function pointers, and in the post-Spectre world, those are vulnerable and costly. For this reason, this series proposes a patchable function pointer abstraction that, in its generic incarnation, consists simply of function pointers and some plumbing to set or reset them (patch #1) Patch #2 illustrates how architectures could optimize these abstractions by using code patching techniques to get rid of the indirect calls, and use fixed jumps instead. This has the side effect of making the function pointer const, making it more robust as well. The remainder of the series shows how we can use this abstraction to clean up the CRC-T10DIF handling in the kernel, which is a pretty depressing example of how cumbersome it is to expose crypto API algorithms as library routines. Note that the various arch specific implementations are kept in their original place as modules, which can be automatically dispatched by udev (as before) based on CPU feature bits. Cc: Jason A. Donenfeld Cc: Eric Biggers Cc: Samuel Neves Cc: Andy Lutomirski Cc: Arnd Bergmann Cc: Herbert Xu Cc: "David S. Miller" Cc: Catalin Marinas Cc: Will Deacon Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Kees Cook Cc: "Martin K. Petersen" Cc: Greg Kroah-Hartman Cc: Andrew Morton Cc: Richard Weinberger Cc: Peter Zijlstra Cc: linux-kernel@vger.kernel.org Cc: linux-crypto@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Cc: linuxppc-dev@lists.ozlabs.org [0] commit 428490e38b2e ("security/keys: rewrite all of big_key crypto") [1] https://lore.kernel.org/lkml/20180925145622.29959-3-Jason@zx2c4.com/ Ard Biesheuvel (9): kernel: add support for patchable function pointers arm64: kernel: add arch support for patchable function pointers crypto: crc-t10dif - make crc_t10dif a static inline crypto: crc-t10dif - use patchable function pointer for core update routine crypto: crc-t10dif/arm64 - move PMULL based code into core library crypto: crc-t10dif/arm - move PMULL based code into core library crypto: crct10dif/generic - switch crypto API driver to core library crypto: crc-t10dif/powerpc - move PMULL based code into core library crypto: crc-t10dif/x86 - move PMULL based code into core library arch/Kconfig | 3 + arch/arm/crypto/crct10dif-ce-glue.c | 78 +++------- arch/arm64/Kconfig | 1 + arch/arm64/crypto/crct10dif-ce-glue.c | 61 ++------ arch/arm64/include/asm/ffp.h | 35 +++++ arch/arm64/kernel/insn.c | 22 +++ arch/powerpc/crypto/crct10dif-vpmsum_glue.c | 55 +------- arch/x86/crypto/crct10dif-pclmul_glue.c | 98 ++----------- crypto/Kconfig | 1 + crypto/Makefile | 2 +- crypto/crct10dif_common.c | 82 ----------- crypto/crct10dif_generic.c | 4 +- include/linux/crc-t10dif.h | 24 +++- include/linux/ffp.h | 43 ++++++ lib/Kconfig | 2 - lib/crc-t10dif.c | 149 +++++++------------- 16 files changed, 235 insertions(+), 425 deletions(-) create mode 100644 arch/arm64/include/asm/ffp.h delete mode 100644 crypto/crct10dif_common.c create mode 100644 include/linux/ffp.h