Bug#976635: linux-image-arm64: Accelerated crypto modules missing from kernel config
Hello Diederik,
On Fri, 11 Dec 2020 at 12:21, Diederik de Haas <didi.debian@cknow.org> wrote:
>
> On Sun, 06 Dec 2020 09:34:36 +0100 Ard Biesheuvel <ardb@kernel.org> wrote:
> > Currently, arm64 kernel packages are built with the following Kconfig symbols
> unset:
> >
> > # CONFIG_CRYPTO_SHA512_ARM64 is not set
> > # CONFIG_CRYPTO_SHA512_ARM64_CE is not set
> > # CONFIG_CRYPTO_SHA3_ARM64 is not set
> > # CONFIG_CRYPTO_SM3_ARM64_CE is not set
> > # CONFIG_CRYPTO_SM4_ARM64_CE is not set
> > # CONFIG_CRYPTO_CRCT10DIF_ARM64_CE is not set
> > # CONFIG_CRYPTO_AES_ARM64_NEON_BLK is not set
> > # CONFIG_CRYPTO_AES_ARM64_BS is not set
> >
> > Please consider enabling these as modules. The latter two are especially
> relevant, given that scalar AES is susceptible to known-plaintext attacks on
> the key due to the fact that it is not time invariant. While most arm64 SoCs
> implement the AES instructions and therefore don't rely on these modules,
> notable SoCs such as the Raspberry Pi 3 and 4 can only use the NEON version
> which is not enabled here. (And on these platforms, these are substantially
> faster too)
>
> Are you the same Ard Biesheuvel that 'Signed-off-by' the patch in:
> https://salsa.debian.org/kernel-team/linux/-/commit/
> 8332600d1188a6d88881fc835dfcd392a20f6bfc
>
Presumably, yes. But I cannot access that link.
> In that commit a bunch of crypto modules got enabled, but (explicitly) not
> CONFIG_CRYPTO_AES_ARM64_NEON_BLK. Do you recall why that happened? (I realize
> it's from 2014)
> There's an important difference between an 'oversight' and explicitly disabling
> a module and I'd like to have a clarification wrt that.
>
This code was written before any hardware existed, and at the time, it
was not obvious whether it would perform well enough.
Six years later, we know that this code works fine, and is faster (and
safer!) than any of the non-NEON alternatives. (On Raspberry Pi 3, the
non-NEON AES takes 31.5 cycles per byte, whereas the NEON code takes
around 22 cycles per byte)
Reply to: