| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20250402002420.89233-1-ebiggers@kernel.org> Date: Tue, 1 Apr 2025 17:24:00 -0700 From: Eric Biggers <ebiggers@...nel.org> To: linux-crypto@...r.kernel.org Cc: linux-kernel@...r.kernel.org, x86@...nel.org Subject: [PATCH v2 0/9] crypto: x86 - stop using the SIMD helper Patches 2-9 are almost identical to https://lore.kernel.org/r/20250220051325.340691-3-ebiggers@kernel.org/ but now split into multiple patches. Patch 1 is just a resend of https://lore.kernel.org/r/20250320220648.121990-1-ebiggers@kernel.org/ which is needed for the series to apply cleanly but is otherwise unrelated. Description of patches 2-9 follows: Stop wrapping skcipher and aead algorithms with the crypto SIMD helper (crypto/simd.c). The only purpose of doing so was to work around x86 not always supporting kernel-mode FPU in softirqs. Specifically, if a hardirq interrupted a task context kernel-mode FPU section and then a softirqs were run at the end of that hardirq, those softirqs could not use kernel-mode FPU. This has now been fixed. In combination with the fact that the skcipher and aead APIs only support task and softirq contexts, these can now just use kernel-mode FPU unconditionally on x86. This simplifies the code and improves performance. En/decryption gets at least somewhat faster for everyone, since the crypto API functions such as crypto_skcipher_encrypt() now go directly to the underlying algorithm rather than taking a detour through crypto/simd.c which involved an extra indirect call. For example, on a Ryzen 9 9950X desktop processor, AES-256-XTS is now 23% faster for 512-byte messages and 7% faster for 4096-byte messages (when accessed through crypto_skcipher_encrypt() or crypto_skcipher_decrypt()). There's also a much larger performance improvement for crypto API users that only support synchronous algorithms. These users will now actually use the x86 SIMD (e.g. AES-NI or VAES) optimized en/decryption modes, which they couldn't before because they were marked as asynchronous. Eric Biggers (9): crypto: x86/aes - drop the avx10_256 AES-XTS and AES-CTR code crypto: x86/aegis - stop using the SIMD helper crypto: x86/aes - stop using the SIMD helper crypto: x86/aria - stop using the SIMD helper crypto: x86/camellia - stop using the SIMD helper crypto: x86/cast - stop using the SIMD helper crypto: x86/serpent - stop using the SIMD helper crypto: x86/sm4 - stop using the SIMD helper crypto: x86/twofish - stop using the SIMD helper arch/x86/crypto/Kconfig | 14 -- arch/x86/crypto/aegis128-aesni-glue.c | 13 +- arch/x86/crypto/aes-ctr-avx-x86_64.S | 47 ++---- arch/x86/crypto/aes-xts-avx-x86_64.S | 118 ++++++-------- arch/x86/crypto/aesni-intel_glue.c | 174 ++++++++------------- arch/x86/crypto/aria_aesni_avx2_glue.c | 22 +-- arch/x86/crypto/aria_aesni_avx_glue.c | 20 +-- arch/x86/crypto/aria_gfni_avx512_glue.c | 22 +-- arch/x86/crypto/camellia_aesni_avx2_glue.c | 21 +-- arch/x86/crypto/camellia_aesni_avx_glue.c | 21 +-- arch/x86/crypto/cast5_avx_glue.c | 21 +-- arch/x86/crypto/cast6_avx_glue.c | 20 +-- arch/x86/crypto/serpent_avx2_glue.c | 21 +-- arch/x86/crypto/serpent_avx_glue.c | 21 +-- arch/x86/crypto/serpent_sse2_glue.c | 21 +-- arch/x86/crypto/sm4_aesni_avx2_glue.c | 31 ++-- arch/x86/crypto/sm4_aesni_avx_glue.c | 31 ++-- arch/x86/crypto/twofish_avx_glue.c | 21 +-- 18 files changed, 227 insertions(+), 432 deletions(-) base-commit: 91e5bfe317d8f8471fbaa3e70cf66cae1314a516 -- 2.49.0
Powered by blists - more mailing lists