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: 148146 Delivered-To: patch@linaro.org Received: by 2002:a2e:8595:0:0:0:0:0 with SMTP id b21-v6csp150892lji; Fri, 5 Oct 2018 01:13:42 -0700 (PDT) X-Google-Smtp-Source: ACcGV61baaXB85aC9JYp72npjuWVgCeQDHNsYggKQcUdCIQ9OChsAXnVzwgePkeEr3OZ79Zui9AO X-Received: by 2002:a63:89c1:: with SMTP id v184-v6mr8870117pgd.79.1538727222272; Fri, 05 Oct 2018 01:13:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538727222; cv=none; d=google.com; s=arc-20160816; b=OE4n6FZn1xk9BHmt/fLxqw+YqVZpQ6Cc+umM1+nHCJik1hyYEQjIPbbsZOpbz0uhP6 wWM9R/d2afSXu8yFiBCfDuiB+RlRD7zyAzc7sDcWV02Ebg8p4UPwD+TwJO/cwHFJbZFr UEyiiPumkkFGEiy3loj4u8zYfwqRVwiNwtp8Dm2fHmofoxZiQDPr0+gZz2YPtl856fJD 5nRwoc6Z44TIGuXRO9ZDYV+m16gNTxi+3CZ+ZUJJHsPkPLwpbUPVKGPf2KrcpwgRWwz2 t7XyVwlgN9Ed/FCeLZ6GCwWNpHyzJEl5kpYWdVapmzQBrGUCwTW1B3YReTK7YM01FFFU PjCQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :dkim-signature; bh=KnHDBIUvlzt9rTbfCGWIVDG2qN/TNs+CUrI8dKvj7bI=; b=BwbCC35hKJ0BYfaBF1o3lpwnqNUgyuJ0OsfGiPaRhtV9+OkeMkl5aka7S9ZFk7OOEc ziqy3enjoNKfAmTrbTvYI+QKdJX7eWasc6XCAfHH6MM0CEEkDHcEPBhqBDmqNXTe0e/x Ak21/BM133H1UJNw5QoMkZCwwWr+Zpr8RnFWEfEPUcrrptA3KPIRqwranMPm4Tyo2e2F qe7ycVMbEokfFpnefQkjJowb+39k0PYv5MXhKzaEINWIURekehGZ2d7ZKs6TzrLf0n/x IwhnL9oxM4QZx0us3AvjWrDgnhZKPkq89wEF5TfOX0AqBrQELqwIyqAIIc6sxX8LyI5Y Pcrw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=dcth4H3R; spf=pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id bd2-v6si7421266plb.382.2018.10.05.01.13.42; Fri, 05 Oct 2018 01:13:42 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=dcth4H3R; spf=pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728260AbeJEPLQ (ORCPT + 2 others); Fri, 5 Oct 2018 11:11:16 -0400 Received: from mail-wr1-f67.google.com ([209.85.221.67]:35608 "EHLO mail-wr1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727073AbeJEPLQ (ORCPT ); Fri, 5 Oct 2018 11:11:16 -0400 Received: by mail-wr1-f67.google.com with SMTP id w5-v6so12590004wrt.2 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=L/jmLAUCtil43nZgo2sbn8Oy4pmyR5vjQmTtgRQpH19QCWx0oazDu/IUIh7x9Iv0IL G/oqAGg9tu9iIj4cSO4ZA1uvlZmTbO8PhEERo2NnGT5tenX9j1Q9C7BSA1H8qXi8IdDF NzDTOjoSgbCUy8NcnTLlsOfU0KQ3RbswWyJ0H90c55+5XvHCJ/hhCWv5hnjQ8WX1EH+R qtvXeaY8GQUDpgVONPYWZBh4ZoVa0digd68eTnu2TWKE6kRHDm633hlwihfN14Oj/IEJ QQCK7qF+ILb0fJtFC7ndSQVEP5pOM55XooUnpP+Ln51peGS2+ZkX8L9YXgionzv0OmSO nGVw== X-Gm-Message-State: ABuFfoi+Dp/7bZ03Flu7n8eH5Jit4UV3IgZoPrJNun7FugXqnb/hRfgK tieeFhouBQv5iK6HVIzZx0iQIw== 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 Cc: Ard Biesheuvel , "Jason A . Donenfeld" , Eric Biggers , Samuel Neves , Andy Lutomirski , Arnd Bergmann , Herbert Xu , "David S. Miller" , Catalin Marinas , Will Deacon , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Thomas Gleixner , Ingo Molnar , Kees Cook , "Martin K. Petersen" , Greg Kroah-Hartman , Andrew Morton , Richard Weinberger , Peter Zijlstra , linux-crypto@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.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 Sender: linux-crypto-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org 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 -- 2.11.0