From: Eric Biggers Date: Tue, 31 Mar 2026 02:44:14 +0000 (-0700) Subject: lib/crypto: aescfb: Don't disable IRQs during AES block encryption X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=1aa82df3eb4d1a28c02a9d0062c6ed0db1a59bac;p=thirdparty%2Fkernel%2Flinux.git lib/crypto: aescfb: Don't disable IRQs during AES block encryption aes_encrypt() now uses AES instructions when available instead of always using table-based code. AES instructions are constant-time and don't benefit from disabling IRQs as a constant-time hardening measure. In fact, on two architectures (arm and riscv) disabling IRQs is counterproductive because it prevents the AES instructions from being used. (See the may_use_simd() implementation on those architectures.) Therefore, let's remove the IRQ disabling/enabling and leave the choice of constant-time hardening measures to the AES library code. Note that currently the arm table-based AES code (which runs on arm kernels that don't have ARMv8 CE) disables IRQs, while the generic table-based AES code does not. So this does technically regress in constant-time hardening when that generic code is used. But as discussed in commit a22fd0e3c495 ("lib/crypto: aes: Introduce improved AES library") I think just leaving IRQs enabled is the right choice. Disabling them is slow and can cause problems, and AES instructions (which modern CPUs have) solve the problem in a much better way anyway. Reviewed-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20260331024414.51545-1-ebiggers@kernel.org Signed-off-by: Eric Biggers --- diff --git a/lib/crypto/aescfb.c b/lib/crypto/aescfb.c index 147e5211728f8..e38848d101e33 100644 --- a/lib/crypto/aescfb.c +++ b/lib/crypto/aescfb.c @@ -9,25 +9,6 @@ #include #include #include -#include - -static void aescfb_encrypt_block(const struct aes_enckey *key, void *dst, - const void *src) -{ - unsigned long flags; - - /* - * In AES-CFB, the AES encryption operates on known 'plaintext' (the IV - * and ciphertext), making it susceptible to timing attacks on the - * encryption key. The AES library already mitigates this risk to some - * extent by pulling the entire S-box into the caches before doing any - * substitutions, but this strategy is more effective when running with - * interrupts disabled. - */ - local_irq_save(flags); - aes_encrypt(key, dst, src); - local_irq_restore(flags); -} /** * aescfb_encrypt - Perform AES-CFB encryption on a block of data @@ -45,7 +26,7 @@ void aescfb_encrypt(const struct aes_enckey *key, u8 *dst, const u8 *src, const u8 *v = iv; while (len > 0) { - aescfb_encrypt_block(key, ks, v); + aes_encrypt(key, ks, v); crypto_xor_cpy(dst, src, ks, min(len, AES_BLOCK_SIZE)); v = dst; @@ -72,7 +53,7 @@ void aescfb_decrypt(const struct aes_enckey *key, u8 *dst, const u8 *src, { u8 ks[2][AES_BLOCK_SIZE]; - aescfb_encrypt_block(key, ks[0], iv); + aes_encrypt(key, ks[0], iv); for (int i = 0; len > 0; i ^= 1) { if (len > AES_BLOCK_SIZE) @@ -81,7 +62,7 @@ void aescfb_decrypt(const struct aes_enckey *key, u8 *dst, const u8 *src, * performing the XOR, as that may update in place and * overwrite the ciphertext. */ - aescfb_encrypt_block(key, ks[!i], src); + aes_encrypt(key, ks[!i], src); crypto_xor_cpy(dst, src, ks[i], min(len, AES_BLOCK_SIZE));