linux-rng/crypto, branch master

Merge tag 'fpsimd-on-stack-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux

2025-12-03T02:53:50Z

Pull arm64 FPSIMD on-stack buffer updates from Eric Biggers: "This is a core arm64 change. However, I was asked to take this because most uses of kernel-mode FPSIMD are in crypto or CRC code. In v6.8, the size of task_struct on arm64 increased by 528 bytes due to the new 'kernel_fpsimd_state' field. This field was added to allow kernel-mode FPSIMD code to be preempted. Unfortunately, 528 bytes is kind of a lot for task_struct. This regression in the task_struct size was noticed and reported. Recover that space by making this state be allocated on the stack at the beginning of each kernel-mode FPSIMD section. To make it easier for all the users of kernel-mode FPSIMD to do that correctly, introduce and use a 'scoped_ksimd' abstraction" * tag 'fpsimd-on-stack-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux: (23 commits) lib/crypto: arm64: Move remaining algorithms to scoped ksimd API lib/crypto: arm/blake2b: Move to scoped ksimd API arm64/fpsimd: Allocate kernel mode FP/SIMD buffers on the stack arm64/fpu: Enforce task-context only for generic kernel mode FPU net/mlx5: Switch to more abstract scoped ksimd guard API on arm64 arm64/xorblocks: Switch to 'ksimd' scoped guard API crypto/arm64: sm4 - Switch to 'ksimd' scoped guard API crypto/arm64: sm3 - Switch to 'ksimd' scoped guard API crypto/arm64: sha3 - Switch to 'ksimd' scoped guard API crypto/arm64: polyval - Switch to 'ksimd' scoped guard API crypto/arm64: nhpoly1305 - Switch to 'ksimd' scoped guard API crypto/arm64: aes-gcm - Switch to 'ksimd' scoped guard API crypto/arm64: aes-blk - Switch to 'ksimd' scoped guard API crypto/arm64: aes-ccm - Switch to 'ksimd' scoped guard API raid6: Move to more abstract 'ksimd' guard API crypto: aegis128-neon - Move to more abstract 'ksimd' guard API crypto/arm64: sm4-ce-gcm - Avoid pointless yield of the NEON unit crypto/arm64: sm4-ce-ccm - Avoid pointless yield of the NEON unit crypto/arm64: aes-ce-ccm - Avoid pointless yield of the NEON unit lib/crc: Switch ARM and arm64 to 'ksimd' scoped guard API ...

Merge tag 'arm64-fpsimd-on-stack-for-v6.19' into libcrypto-fpsimd-on-stack

2025-11-12T18:15:07Z

Pull fpsimd-on-stack changes from Ard Biesheuvel: "Shared tag/branch for arm64 FP/SIMD changes going through libcrypto" Signed-off-by: Eric Biggers

crypto: aegis128-neon - Move to more abstract 'ksimd' guard API

2025-11-12T08:52:01Z

Move away from calling kernel_neon_begin() and kernel_neon_end() directly, and instead, use the newly introduced scoped_ksimd() API. This permits arm64 to modify the kernel mode NEON API without affecting code that is shared between ARM and arm64. Reviewed-by: Eric Biggers Reviewed-by: Jonathan Cameron Acked-by: Catalin Marinas Signed-off-by: Ard Biesheuvel

crypto: testmgr - Remove polyval tests

2025-11-11T19:07:52Z

These are no longer used, since polyval support has been removed from the crypto_shash API. POLYVAL remains supported via lib/crypto/, where it has a KUnit test suite instead. Reviewed-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20251109234726.638437-9-ebiggers@kernel.org Signed-off-by: Eric Biggers

crypto: polyval - Remove the polyval crypto_shash

2025-11-11T19:03:38Z

Remove polyval support from crypto_shash. It no longer has any user now that the HCTR2 code uses the POLYVAL library instead. Reviewed-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20251109234726.638437-8-ebiggers@kernel.org Signed-off-by: Eric Biggers

crypto: hctr2 - Convert to use POLYVAL library

2025-11-11T19:03:38Z

The "hash function" in hctr2 is fixed at POLYVAL; it can never vary. Just use the POLYVAL library, which is much easier to use than the crypto_shash API. It's faster, uses fixed-size structs, and never fails (all the functions return void). Note that this eliminates the only known user of the polyval support in crypto_shash. A later commit will remove support for polyval from crypto_shash, given that the library API is sufficient. Reviewed-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20251109234726.638437-7-ebiggers@kernel.org Signed-off-by: Eric Biggers

crypto: polyval - Rename conflicting functions

2025-11-11T19:03:38Z

Rename polyval_init() and polyval_update(), in preparation for adding library functions with the same name to . Note that polyval-generic.c will be removed later, as it will be superseded by the library. This commit just keeps the kernel building for the initial introduction of the library. Reviewed-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20251109234726.638437-2-ebiggers@kernel.org Signed-off-by: Eric Biggers

crypto: sha3 - Reimplement using library API

2025-11-06T04:30:51Z

Replace sha3_generic.c with a new file sha3.c which implements the SHA-3 crypto_shash algorithms on top of the SHA-3 library API. Change the driver name suffix from "-generic" to "-lib" to reflect that these algorithms now just use the (possibly arch-optimized) library. This closely mirrors crypto/{md5,sha1,sha256,sha512,blake2b}.c. Implement export_core and import_core, since crypto/hmac.c expects these to be present. (Note that there is no security purpose in wrapping SHA-3 with HMAC. HMAC was designed for older algorithms that don't resist length extension attacks. But since someone could be using "hmac(sha3-*)" via crypto_shash anyway, keep supporting it for now.) Reviewed-by: Ard Biesheuvel Tested-by: Harald Freudenberger Link: https://lore.kernel.org/r/20251026055032.1413733-15-ebiggers@kernel.org Signed-off-by: Eric Biggers

crypto: jitterentropy - Use default sha3 implementation

2025-11-06T04:30:51Z

Make jitterentropy use "sha3-256" instead of "sha3-256-generic", as the ability to explicitly request the generic code is going away. It's not worth providing a special generic API just for jitterentropy. There are many other solutions available to it, such as doing more iterations or using a more effective jitter collection method. Moreover, the status quo is that SHA-3 is quite slow anyway. Currently only arm64 and s390 have architecture-optimized SHA-3 code. I'm not familiar with the performance of the s390 one, but the arm64 one isn't actually that much faster than the generic code anyway. Note that jitterentropy should just use the library API instead of crypto_shash. But that belongs in a separate change later. Reviewed-by: Ard Biesheuvel Tested-by: Harald Freudenberger Link: https://lore.kernel.org/r/20251026055032.1413733-14-ebiggers@kernel.org Signed-off-by: Eric Biggers

crypto: blake2b - Reimplement using library API

2025-10-30T05:04:24Z

Replace blake2b_generic.c with a new file blake2b.c which implements the BLAKE2b crypto_shash algorithms on top of the BLAKE2b library API. Change the driver name suffix from "-generic" to "-lib" to reflect that these algorithms now just use the (possibly arch-optimized) library. This closely mirrors crypto/{md5,sha1,sha256,sha512}.c. Remove include/crypto/internal/blake2b.h since it is no longer used. Likewise, remove struct blake2b_state from include/crypto/blake2b.h. Omit support for import_core and export_core, since there are no legacy drivers that need these for these algorithms. Reviewed-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20251018043106.375964-10-ebiggers@kernel.org Signed-off-by: Eric Biggers