Describe the bug
On AL2023 kernel6.18 (x86_64), all in-kernel AES falls back to software fixed-time AES because the AES-NI/VAES accelerated implementation is not available to the kernel Crypto API. This causes a ~26–46x throughput regression for AES-XTS/AES-CBC (dm-crypt/LUKS, kTLS, AF_ALG, IPsec) versus kernel6.12.
On kernel6.12, AES-XTS uses xts-aes-aesni-avx (AES-NI/AVX, priority 500). On kernel6.18, AES-XTS uses xts(ecb(aes-fixed-time)) (priority 101), despite the CPU exposing AES/AVX/AVX2/AVX-512 and FIPS being disabled (fips_enabled=0).
Root cause (from on-host investigation):
On 6.18 x86_64, aesni_intel is not built-in (absent from modules.builtin) and there is no aesni_intel.ko on disk. On 6.12 it was built-in.
The standalone FIPS 140-3 module fips140.ko (CONFIG_CRYPTO_FIPS140_EXTMOD=y) is loaded unconditionally at boot (dmesg: "loading FIPS 140 Kernel Cryptographic Module") even with fips_enabled=0, and is a hard dependency of xts, cbc, dm_mod, algif_skcipher, and tls.
strings fips140.ko shows its AES algorithms are all aes-generic-based; no AES-NI/VAES strings are present. So the accelerated AES was not compiled into the FIPS module.
Net effect: the only AES providers registered on 6.18 are aes-fixed-time (prio 101) and aes-generic (prio 100), so every kernel Crypto API AES consumer uses software AES.
To Reproduce
On two instances (same CPU: Intel Xeon Platinum 8223CL, 36 vCPU; fips_enabled=0):
$ cryptsetup benchmark -c aes-xts -s 512
kernel 6.12.92-122.168.amzn2023.x86_64
aes-xts 512b 2000.9 MiB/s (enc) 2608.1 MiB/s (dec)
kernel 6.18.39-79.141.amzn2023.x86_64
aes-xts 512b 72.6 MiB/s (enc) 38.4 MiB/s (dec)
/proc/crypto for xts(aes):
6.12
name: xts(aes) driver: xts-aes-aesni-avx priority: 500 selftest: passed
6.18
name: xts(aes) driver: xts(ecb(aes-fixed-time)) priority: 101 selftest: passed
On 6.18, grep -iE 'aesni|vaes|xts-aes' /proc/crypto returns nothing (no accelerated AES providers at all).
Control: openssl speed -evp aes-256-xts is multi-GB/s on both (OpenSSL uses its own userspace AES-NI), confirming the CPU is capable and the regression is specific to the kernel Crypto API.
Expected behavior
On a CPU with AES-NI/AVX and with FIPS disabled, the kernel should register and select the AES-NI/VAES accelerated AES-XTS/AES-CBC implementation (as kernel6.12 does), giving hardware-accelerated throughput for dm-crypt and other in-kernel AES consumers.
Environment
OS: Amazon Linux 2023 (x86_64)
CPU: Intel Xeon Platinum 8223CL @ 3.00 GHz, 36 vCPU (flags: aes, avx, avx2, avx512)
Bad: kernel 6.18.39-79.141.amzn2023.x86_64
Good: kernel 6.12.92-122.168.amzn2023.x86_64
fips_enabled=0, crypto policy DEFAULT on both
Workload: LUKS2 / dm-crypt, aes-xts-plain64, 512-bit key, on EC2 NVMe instance storage
Additional context
Impact is not limited to dm-crypt — every in-kernel AES consumer is affected (kTLS, AF_ALG/algif_skcipher, IPsec/xfrm). Userspace crypto (OpenSSL etc.) is unaffected.
There is no user-side workaround: the accelerated AES code is absent from the kernel package, fips140 cannot be unloaded (xts/cbc/dm_crypt/tls depend on it), and enabling FIPS does not add the missing code.
Questions:
Why does the x86_64 kernel6.18 fips140 module omit the AES-NI/VAES accelerated AES that kernel6.12 had built-in?
Why is fips140 loaded and made a hard dependency of xts/dm_crypt when fips_enabled=0? Non-FIPS systems should retain hardware-accelerated AES.
Is there a planned kernel update that restores AES-NI/VAES AES-XTS performance (either by including it in the FIPS module or by providing aesni_intel outside it)?
Is there any supported configuration to regain hardware AES on 6.18 without enabling FIPS?
Current mitigation: remaining on the AL2023 6.12 kernel for LUKS/dm-crypt workloads.
Describe the bug
On AL2023 kernel6.18 (x86_64), all in-kernel AES falls back to software fixed-time AES because the AES-NI/VAES accelerated implementation is not available to the kernel Crypto API. This causes a ~26–46x throughput regression for AES-XTS/AES-CBC (dm-crypt/LUKS, kTLS, AF_ALG, IPsec) versus kernel6.12.
On kernel6.12, AES-XTS uses xts-aes-aesni-avx (AES-NI/AVX, priority 500). On kernel6.18, AES-XTS uses xts(ecb(aes-fixed-time)) (priority 101), despite the CPU exposing AES/AVX/AVX2/AVX-512 and FIPS being disabled (fips_enabled=0).
Root cause (from on-host investigation):
On 6.18 x86_64, aesni_intel is not built-in (absent from modules.builtin) and there is no aesni_intel.ko on disk. On 6.12 it was built-in.
The standalone FIPS 140-3 module fips140.ko (CONFIG_CRYPTO_FIPS140_EXTMOD=y) is loaded unconditionally at boot (dmesg: "loading FIPS 140 Kernel Cryptographic Module") even with fips_enabled=0, and is a hard dependency of xts, cbc, dm_mod, algif_skcipher, and tls.
strings fips140.ko shows its AES algorithms are all aes-generic-based; no AES-NI/VAES strings are present. So the accelerated AES was not compiled into the FIPS module.
Net effect: the only AES providers registered on 6.18 are aes-fixed-time (prio 101) and aes-generic (prio 100), so every kernel Crypto API AES consumer uses software AES.
To Reproduce
On two instances (same CPU: Intel Xeon Platinum 8223CL, 36 vCPU; fips_enabled=0):
$ cryptsetup benchmark -c aes-xts -s 512
kernel 6.12.92-122.168.amzn2023.x86_64
kernel 6.18.39-79.141.amzn2023.x86_64
/proc/crypto for xts(aes):
6.12
name: xts(aes) driver: xts-aes-aesni-avx priority: 500 selftest: passed
6.18
name: xts(aes) driver: xts(ecb(aes-fixed-time)) priority: 101 selftest: passed
On 6.18, grep -iE 'aesni|vaes|xts-aes' /proc/crypto returns nothing (no accelerated AES providers at all).
Control: openssl speed -evp aes-256-xts is multi-GB/s on both (OpenSSL uses its own userspace AES-NI), confirming the CPU is capable and the regression is specific to the kernel Crypto API.
Expected behavior
On a CPU with AES-NI/AVX and with FIPS disabled, the kernel should register and select the AES-NI/VAES accelerated AES-XTS/AES-CBC implementation (as kernel6.12 does), giving hardware-accelerated throughput for dm-crypt and other in-kernel AES consumers.
Environment
OS: Amazon Linux 2023 (x86_64)
CPU: Intel Xeon Platinum 8223CL @ 3.00 GHz, 36 vCPU (flags: aes, avx, avx2, avx512)
Bad: kernel 6.18.39-79.141.amzn2023.x86_64
Good: kernel 6.12.92-122.168.amzn2023.x86_64
fips_enabled=0, crypto policy DEFAULT on both
Workload: LUKS2 / dm-crypt, aes-xts-plain64, 512-bit key, on EC2 NVMe instance storage
Additional context
Impact is not limited to dm-crypt — every in-kernel AES consumer is affected (kTLS, AF_ALG/algif_skcipher, IPsec/xfrm). Userspace crypto (OpenSSL etc.) is unaffected.
There is no user-side workaround: the accelerated AES code is absent from the kernel package, fips140 cannot be unloaded (xts/cbc/dm_crypt/tls depend on it), and enabling FIPS does not add the missing code.
Questions:
Why does the x86_64 kernel6.18 fips140 module omit the AES-NI/VAES accelerated AES that kernel6.12 had built-in?
Why is fips140 loaded and made a hard dependency of xts/dm_crypt when fips_enabled=0? Non-FIPS systems should retain hardware-accelerated AES.
Is there a planned kernel update that restores AES-NI/VAES AES-XTS performance (either by including it in the FIPS module or by providing aesni_intel outside it)?
Is there any supported configuration to regain hardware AES on 6.18 without enabling FIPS?
Current mitigation: remaining on the AL2023 6.12 kernel for LUKS/dm-crypt workloads.