On Sun, 06 Dec 2020 09:34:36 +0100 Ard Biesheuvel <a...@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 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. Cheers, Diederik
signature.asc
Description: This is a digitally signed message part.
