user/sven/linux.git/lib/crypto/aesgcm.c, branch next/master

lib/crypto: aesgcm: Don't disable IRQs during AES block encryption

2026-04-01T00:19:22Z

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. Link: https://lore.kernel.org/r/20260331024430.51755-1-ebiggers@kernel.org Signed-off-by: Eric Biggers

lib/crypto: aesgcm: Use GHASH library API

2026-03-23T23:44:30Z

Make the AES-GCM library use the GHASH library instead of directly calling gf128mul_lle(). This allows the architecture-optimized GHASH implementations to be used, or the improved generic implementation if no architecture-optimized implementation is usable. Note: this means that no longer needs to include . Remove that inclusion, and include explicitly from arch/x86/crypto/aesni-intel_glue.c which previously was relying on the transitive inclusion. Acked-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20260319061723.1140720-20-ebiggers@kernel.org Signed-off-by: Eric Biggers

lib/crypto: aesgcm: Use new AES library API

2026-01-15T22:09:09Z

Switch from the old AES library functions (which use struct crypto_aes_ctx) to the new ones (which use struct aes_enckey). This eliminates the unnecessary computation and caching of the decryption round keys. The new AES en/decryption functions are also much faster and use AES instructions when supported by the CPU. Note that in addition to the change in the key preparation function and the key struct type itself, the change in the type of the key struct results in aes_encrypt() (which is temporarily a type-generic macro) calling the new encryption function rather than the old one. Acked-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20260112192035.10427-34-ebiggers@kernel.org Signed-off-by: Eric Biggers

lib/crypto: Explicitly include

2025-06-30T16:26:19Z

Fix build warnings with W=1 that started appearing after commit a934a57a42f6 ("scripts/misc-check: check missing #include when W=1"). While at it, also sort the include lists alphabetically. (Keep asm/irqflags.h last, as otherwise it doesn't build on alpha.) This handles all of lib/crypto/, but not arch/*/lib/crypto/. The exports in arch/*/lib/crypto/ will go away when the code is properly integrated into lib/crypto/ as planned. Link: https://lore.kernel.org/r/20250613184814.50173-1-ebiggers@kernel.org Signed-off-by: Eric Biggers

lib/crypto: Annotate crypto strings with nonstring

2025-06-16T01:14:49Z

Annotate various keys, ivs, and other byte arrays with __nonstring so that static initializers will not complain about truncating the trailing NUL byte under GCC 15 with -Wunterminated-string-initialization enabled. Silences many warnings like: ../lib/crypto/aesgcm.c:642:27: warning: initializer-string for array of 'unsigned char' truncates NUL terminator but destination lacks 'nonstring' attribute (13 chars into 12 available) [-Wunterminated-string-initialization] 642 | .iv = "\xca\xfe\xba\xbe\xfa\xce\xdb\xad" | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20250529173113.work.760-kees@kernel.org Signed-off-by: Eric Biggers

crypto: testmgr - replace CRYPTO_MANAGER_DISABLE_TESTS with CRYPTO_SELFTESTS

2025-05-12T05:33:14Z

The negative-sense of CRYPTO_MANAGER_DISABLE_TESTS is a longstanding mistake that regularly causes confusion. Especially bad is that you can have CRYPTO=n && CRYPTO_MANAGER_DISABLE_TESTS=n, which is ambiguous. Replace CRYPTO_MANAGER_DISABLE_TESTS with CRYPTO_SELFTESTS which has the expected behavior. The tests continue to be disabled by default. Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu

crypto: lib/aesgcm - Reduce stack usage in libaesgcm_init

2024-12-28T11:49:22Z

The stack frame in libaesgcm_init triggers a size warning on x86-64. Reduce it by making buf static. Signed-off-by: Herbert Xu Acked-by: Ard Biesheuvel Signed-off-by: Herbert Xu

crypto: lib/aesgcm - Add kernel docs for aesgcm_mac

2023-11-17T11:16:28Z

Add kernel documentation for the aesgcm_mac. This function generates the authentication tag using the AES-GCM algorithm. Signed-off-by: Sagar Vashnav Signed-off-by: Herbert Xu

crypto: lib/aesgcm - Provide minimal library implementation

2022-11-11T10:14:59Z

Implement a minimal library version of AES-GCM based on the existing library implementations of AES and multiplication in GF(2^128). Using these primitives, GCM can be implemented in a straight-forward manner. GCM has a couple of sharp edges, i.e., the amount of input data processed with the same initialization vector (IV) should be capped to protect the counter from 32-bit rollover (or carry), and the size of the authentication tag should be fixed for a given key. [0] The former concern is addressed trivially, given that the function call API uses 32-bit signed types for the input lengths. It is still up to the caller to avoid IV reuse in general, but this is not something we can police at the implementation level. As for the latter concern, let's make the authentication tag size part of the key schedule, and only permit it to be configured as part of the key expansion routine. Note that table based AES implementations are susceptible to known plaintext timing attacks on the encryption key. The AES library already attempts to mitigate this to some extent, but given that the counter mode encryption used by GCM operates exclusively on known plaintext by construction (the IV and therefore the initial counter value are known to an attacker), let's take some extra care to mitigate this, by calling the AES library with interrupts disabled. [0] https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-38d.pdf Link: https://lore.kernel.org/all/c6fb9b25-a4b6-2e4a-2dd1-63adda055a49@amd.com/ Signed-off-by: Ard Biesheuvel Tested-by: Nikunj A Dadhania Signed-off-by: Herbert Xu