linux-toradex.git/lib/crypto/Makefile, branch master Linux kernel for Apalis and Colibri modules lib/crypto: powerpc/poly1305: Remove BROKEN implementation 2026-10-29T17:09:21+00:00 Eric Biggers ebiggers@kernel.org 2026-10-29T06:35:21+00:00 539436435fbe3954f98325f5ffee0b0c4057aaad The PowerPC implementation of Poly1305 has been marked as BROKEN for well over a year, since commit bc8169003b41 ("crypto: powerpc/poly1305 - add depends on BROKEN for now"). So, it's not being built or used. The justification for marking it BROKEN was that it didn't work in softirq context. That still fully applies. However, it turns out the assembly file actually also contains logic bugs that make it compute incorrect Poly1305 values in some cases. This is shown by it failing the test case test_poly1305_split_update_carry (if "depends on BROKEN" is removed). The cause of that appears to be a lost carry bit in Carry_reduction. However, there also appears to be a bug in do_final_update where it incorrectly assumes v6 is fully reduced. In addition, poly1305_emit_64 contains a secret-dependent branch. Let's just drop this code. A fixed version can be reconsidered later. Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://patch.msgid.link/20261029063522.124421-1-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org> 
The PowerPC implementation of Poly1305 has been marked as BROKEN for
well over a year, since commit bc8169003b41 ("crypto: powerpc/poly1305 -
add depends on BROKEN for now").  So, it's not being built or used.

The justification for marking it BROKEN was that it didn't work in
softirq context.  That still fully applies.

However, it turns out the assembly file actually also contains logic
bugs that make it compute incorrect Poly1305 values in some cases.  This
is shown by it failing the test case test_poly1305_split_update_carry
(if "depends on BROKEN" is removed).  The cause of that appears to be a
lost carry bit in Carry_reduction.  However, there also appears to be a
bug in do_final_update where it incorrectly assumes v6 is fully reduced.

In addition, poly1305_emit_64 contains a secret-dependent branch.

Let's just drop this code.  A fixed version can be reconsidered later.

Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://patch.msgid.link/20261029063522.124421-1-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
lib: Move SipHash into lib/crypto/ 2026-10-03T16:30:12+00:00 Eric Biggers ebiggers@kernel.org 2026-10-03T16:28:27+00:00 b73abee375f1c3e3d4e5ea9c0cf99a918d8fc9ef The addition of SipHash to lib/ predated the existence of the lib/crypto/ directory. Since SipHash is a cryptographic algorithm, move it from the top-level lib/ directory to lib/crypto/. (This does mean HalfSipHash comes with it too, as it's in the same files. But lib/crypto/ still seems like the proper place for both.) Specifically: - Move both siphash.c and siphash_kunit.c. Keep the header <linux/siphash.h> as-is for now. - Drop the dedicated MAINTAINERS entry for SipHash, as per the suggestion from Jason (https://lore.kernel.org/r/asB7QVFMlgKgbje2@zx2c4.com/). The C files now just fold up to the "CRYPTO LIBRARY" entry. Add the header explicitly, as it otherwise would be left unmaintained. - Move the kconfig option that controls the KUnit test. Put "CRYPTO_LIB" in its name and update the prompt and help text to make it consistent with the other crypto library test options. - Enable the KUnit test in lib/crypto/.kunitconfig. - Link to siphash.rst from the appropriate place in libcrypto-hash.rst. - Use obj-y instead of lib-y, for consistency with the fact that currently lib/crypto/ doesn't use kbuild's support for library file goals. We could keep it as lib-y, but virtually every kernel needs SipHash support anyway (with vsprintf, printk, IPv4, IPv6, etc. depending on it) so there is no practical difference in this case. Acked-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Jason A. Donenfeld <Jason@zx2c4.com> Link: https://patch.msgid.link/20261003162827.155527-1-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org> 
The addition of SipHash to lib/ predated the existence of the
lib/crypto/ directory.  Since SipHash is a cryptographic algorithm, move
it from the top-level lib/ directory to lib/crypto/.

(This does mean HalfSipHash comes with it too, as it's in the same
files.  But lib/crypto/ still seems like the proper place for both.)

Specifically:

- Move both siphash.c and siphash_kunit.c.  Keep the header
  <linux/siphash.h> as-is for now.

- Drop the dedicated MAINTAINERS entry for SipHash, as per the
  suggestion from Jason
  (https://lore.kernel.org/r/asB7QVFMlgKgbje2@zx2c4.com/).  The C files
  now just fold up to the "CRYPTO LIBRARY" entry.  Add the header
  explicitly, as it otherwise would be left unmaintained.

- Move the kconfig option that controls the KUnit test.  Put
  "CRYPTO_LIB" in its name and update the prompt and help text to make
  it consistent with the other crypto library test options.

- Enable the KUnit test in lib/crypto/.kunitconfig.

- Link to siphash.rst from the appropriate place in libcrypto-hash.rst.

- Use obj-y instead of lib-y, for consistency with the fact that
  currently lib/crypto/ doesn't use kbuild's support for library file
  goals.  We could keep it as lib-y, but virtually every kernel needs
  SipHash support anyway (with vsprintf, printk, IPv4, IPv6, etc.
  depending on it) so there is no practical difference in this case.

Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Jason A. Donenfeld <Jason@zx2c4.com>
Link: https://patch.msgid.link/20261003162827.155527-1-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
lib/crypto: riscv/aes-xts: Migrate optimized code into library 2026-09-30T16:42:10+00:00 Eric Biggers ebiggers@kernel.org 2026-09-27T22:43:11+00:00 69897f5e8552af8835a2c8a36aa7d597e1cf6689 Instead of exposing the riscv-optimized AES-XTS code via a riscv-specific crypto_skcipher algorithm, just implement the AES-XTS library functions. This is simpler, it makes the AES-XTS library functions be riscv-optimized, and it also fixes the longstanding issue where the riscv-optimized AES-XTS code was disabled by default. AES-XTS support still remains available through crypto_skcipher via crypto/aes.c, but individual architectures no longer need to handle it. To match what the library expects, update the assembly functions to operate on struct aes_key rather than struct crypto_aes_ctx, adjust the argument order, and remove the redundant ciphertext stealing support which is already implemented in a generic way in the library. Bump up the priority of the corresponding library-based algorithm on riscv now that it no longer has to be lower than arch/riscv/crypto/. Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://patch.msgid.link/20260927224418.109759-21-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org> 
Instead of exposing the riscv-optimized AES-XTS code via a
riscv-specific crypto_skcipher algorithm, just implement the AES-XTS
library functions.  This is simpler, it makes the AES-XTS library
functions be riscv-optimized, and it also fixes the longstanding issue
where the riscv-optimized AES-XTS code was disabled by default.  AES-XTS
support still remains available through crypto_skcipher via
crypto/aes.c, but individual architectures no longer need to handle it.

To match what the library expects, update the assembly functions to
operate on struct aes_key rather than struct crypto_aes_ctx, adjust the
argument order, and remove the redundant ciphertext stealing support
which is already implemented in a generic way in the library.

Bump up the priority of the corresponding library-based algorithm on
riscv now that it no longer has to be lower than arch/riscv/crypto/.

Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://patch.msgid.link/20260927224418.109759-21-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
lib/crypto: riscv/aes-ctr: Migrate optimized code into library 2026-09-30T16:42:10+00:00 Eric Biggers ebiggers@kernel.org 2026-09-27T22:43:10+00:00 f083f8de5290dc6384b2929306c0e99714c93d6f Instead of exposing the riscv-optimized AES-CTR code via a riscv-specific crypto_skcipher algorithm, just implement the AES-CTR library functions. This is simpler, it makes the AES-CTR library functions be riscv-optimized, and it also fixes the longstanding issue where the riscv-optimized AES-CTR code was disabled by default. AES-CTR support still remains available through crypto_skcipher via crypto/aes.c, but individual architectures no longer need to handle it. To match what the library expects, update the assembly functions to operate on struct aes_enckey rather than struct crypto_aes_ctx, and adjust the argument order. Bump up the priority of the corresponding library-based algorithm on riscv now that it no longer has to be lower than arch/riscv/crypto/. Also re-enable the library-based "ccm(aes)" and "gcm(aes)". Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://patch.msgid.link/20260927224418.109759-20-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org> 
Instead of exposing the riscv-optimized AES-CTR code via a
riscv-specific crypto_skcipher algorithm, just implement the AES-CTR
library functions.  This is simpler, it makes the AES-CTR library
functions be riscv-optimized, and it also fixes the longstanding issue
where the riscv-optimized AES-CTR code was disabled by default.  AES-CTR
support still remains available through crypto_skcipher via
crypto/aes.c, but individual architectures no longer need to handle it.

To match what the library expects, update the assembly functions to
operate on struct aes_enckey rather than struct crypto_aes_ctx, and
adjust the argument order.

Bump up the priority of the corresponding library-based algorithm on
riscv now that it no longer has to be lower than arch/riscv/crypto/.
Also re-enable the library-based "ccm(aes)" and "gcm(aes)".

Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://patch.msgid.link/20260927224418.109759-20-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
lib/crypto: x86/aes-xts: Migrate AVX-optimized code into library 2026-09-30T16:42:10+00:00 Eric Biggers ebiggers@kernel.org 2026-09-27T22:43:05+00:00 2bd6888849d6d2d5497c2470cc71c8d2cb170523 Migrate aes-xts-avx-x86_64.S into lib/crypto/, wiring it up to the XTS library functions instead of the crypto_skcipher API. It still remains available through crypto_skcipher via crypto/aes.c. Some adjustments to the assembly code were needed: - Take 'struct aes_key' instead of 'struct crypto_aes_ctx'. - Remove the ciphertext stealing support from the assembly code, as the library implements it in a generic way instead. (This does slightly reduce performance when the length isn't a multiple of 16 bytes; however, that case seems to never be reached in practice in the kernel. So it makes sense to not extensively optimize for it yet.) - Change 'int len' to 'long nblocks' for compatibility with the library's use of size_t lengths. - Remove the CFI stubs, as the functions are now called directly. - Adjust the argument order to match the caller. Not strictly required, but it's easiest to handle this now when changing the function prototypes anyway and adding the new glue code. This makes the remaining code in aesni-intel_asm.S (which just handled key expansion) unused, so remove that too. Don't remove the selection of CRYPTO_SKCIPHER from CRYPTO_AES_NI_INTEL yet, since it's still needed for the "skcipher_walk" functions. Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://patch.msgid.link/20260927224418.109759-15-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org> 
Migrate aes-xts-avx-x86_64.S into lib/crypto/, wiring it up to the XTS
library functions instead of the crypto_skcipher API.  It still remains
available through crypto_skcipher via crypto/aes.c.

Some adjustments to the assembly code were needed:

- Take 'struct aes_key' instead of 'struct crypto_aes_ctx'.

- Remove the ciphertext stealing support from the assembly code, as the
  library implements it in a generic way instead.  (This does slightly
  reduce performance when the length isn't a multiple of 16 bytes;
  however, that case seems to never be reached in practice in the
  kernel.  So it makes sense to not extensively optimize for it yet.)

- Change 'int len' to 'long nblocks' for compatibility with the
  library's use of size_t lengths.

- Remove the CFI stubs, as the functions are now called directly.

- Adjust the argument order to match the caller.  Not strictly required,
  but it's easiest to handle this now when changing the function
  prototypes anyway and adding the new glue code.

This makes the remaining code in aesni-intel_asm.S (which just handled
key expansion) unused, so remove that too.

Don't remove the selection of CRYPTO_SKCIPHER from CRYPTO_AES_NI_INTEL
yet, since it's still needed for the "skcipher_walk" functions.

Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://patch.msgid.link/20260927224418.109759-15-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
lib/crypto: x86/aes-ctr: Migrate AVX-optimized code into library 2026-09-30T16:42:10+00:00 Eric Biggers ebiggers@kernel.org 2026-09-27T22:43:04+00:00 7e58d75b7cc73faf73e6793940f591257caeae68 Migrate aes-ctr-avx-x86_64.S into lib/crypto/, wiring it up to the CTR and XCTR library functions instead of the crypto_skcipher API. It still remains available through crypto_skcipher via crypto/aes.c. Some slight adjustments to the assembly code were needed: - Take 'struct aes_enckey' instead of 'struct crypto_aes_ctx'. - Upgrade the length argument from 32-bit to 64-bit so that it's compatible with the library's use of size_t (at least assuming no lengths over S64_MAX, which seems quite safe to assume...) - Remove the CFI stubs, as the functions are now called directly. - Adjust the argument order to match the caller. Not strictly required, but it's easiest to handle this now when changing the function prototypes anyway and adding the new glue code. Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://patch.msgid.link/20260927224418.109759-14-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org> 
Migrate aes-ctr-avx-x86_64.S into lib/crypto/, wiring it up to the CTR
and XCTR library functions instead of the crypto_skcipher API.  It still
remains available through crypto_skcipher via crypto/aes.c.

Some slight adjustments to the assembly code were needed:

- Take 'struct aes_enckey' instead of 'struct crypto_aes_ctx'.

- Upgrade the length argument from 32-bit to 64-bit so that it's
  compatible with the library's use of size_t (at least assuming no
  lengths over S64_MAX, which seems quite safe to assume...)

- Remove the CFI stubs, as the functions are now called directly.

- Adjust the argument order to match the caller.  Not strictly required,
  but it's easiest to handle this now when changing the function
  prototypes anyway and adding the new glue code.

Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://patch.msgid.link/20260927224418.109759-14-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
lib/crypto: aesgcm: Remove old AES-GCM library 2026-07-23T16:30:30+00:00 Eric Biggers ebiggers@kernel.org 2026-07-22T02:53:38+00:00 6d22ec26295c1412d765e3d687e46224fc332928 The old AES-GCM library code is no longer used, so remove it. Tested-by: Nikunj A Dadhania <nikunj@amd.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://patch.msgid.link/20260722025338.33354-4-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org> 
The old AES-GCM library code is no longer used, so remove it.

Tested-by: Nikunj A Dadhania <nikunj@amd.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://patch.msgid.link/20260722025338.33354-4-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
lib/crypto: powerpc/md5: Drop powerpc optimized MD5 code 2026-05-09T18:41:01+00:00 Eric Biggers ebiggers@kernel.org 2026-05-06T03:00:05+00:00 cf52058dcdd96420cfc38ee284c5ac077901ea61 MD5 is obsolete, is vulnerable to collision attacks, and is being replaced by SHA-256 in new systems. It doesn't make sense to continue to maintain architecture-optimized implementations of MD5. Effort should be spent on modern algorithms. Indeed, architecture-optimized MD5 code remains only for powerpc. It was already removed from mips and sparc, and it never existed for any other architecture (e.g. x86, arm, or arm64) in the first place. Earlier the decision was made to keep the powerpc MD5 code for a while anyway because of someone using it via AF_ALG via libkcapi-hasher (https://lore.kernel.org/r/f0d771d5-ed70-444c-957a-ad4c16f6c115@csgroup.eu/) However, with AF_ALG itself now being on its way out due to its continuous stream of security vulnerabilities (https://lore.kernel.org/r/20260430011544.31823-1-ebiggers@kernel.org/), it's also time to be a bit more forceful with nudging people towards userspace crypto code. It's always been the better solution anyway, and it's much more efficient if properly optimized code is used. Note that the md5-asm.S file contains no privileged instructions and could be run in userspace just fine. Thus, we now have two factors going against keeping the powerpc MD5 code. Different people might weigh these two factors differently, but I think the two of them together make the removal the clear choice. Let's remove it. Acked-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org> Acked-by: Ard Biesheuvel <ardb@kernel.org> Link: https://patch.msgid.link/20260506030005.9698-1-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org> 
MD5 is obsolete, is vulnerable to collision attacks, and is being
replaced by SHA-256 in new systems.  It doesn't make sense to continue
to maintain architecture-optimized implementations of MD5.  Effort
should be spent on modern algorithms.

Indeed, architecture-optimized MD5 code remains only for powerpc.  It
was already removed from mips and sparc, and it never existed for any
other architecture (e.g. x86, arm, or arm64) in the first place.
Earlier the decision was made to keep the powerpc MD5 code for a while
anyway because of someone using it via AF_ALG via libkcapi-hasher
(https://lore.kernel.org/r/f0d771d5-ed70-444c-957a-ad4c16f6c115@csgroup.eu/)

However, with AF_ALG itself now being on its way out due to its
continuous stream of security vulnerabilities
(https://lore.kernel.org/r/20260430011544.31823-1-ebiggers@kernel.org/),
it's also time to be a bit more forceful with nudging people towards
userspace crypto code.  It's always been the better solution anyway, and
it's much more efficient if properly optimized code is used.

Note that the md5-asm.S file contains no privileged instructions and
could be run in userspace just fine.

Thus, we now have two factors going against keeping the powerpc MD5
code.  Different people might weigh these two factors differently, but I
think the two of them together make the removal the clear choice.

Let's remove it.

Acked-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://patch.msgid.link/20260506030005.9698-1-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
Merge tag 'libcrypto-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux 2026-04-14T00:31:39+00:00 Linus Torvalds torvalds@linux-foundation.org 2026-04-14T00:31:39+00:00 370c3883195566ee3e7d79e0146c3d735a406573 Pull crypto library updates from Eric Biggers: - Migrate more hash algorithms from the traditional crypto subsystem to lib/crypto/ Like the algorithms migrated earlier (e.g. SHA-*), this simplifies the implementations, improves performance, enables further simplifications in calling code, and solves various other issues: - AES CBC-based MACs (AES-CMAC, AES-XCBC-MAC, and AES-CBC-MAC) - Support these algorithms in lib/crypto/ using the AES library and the existing arm64 assembly code - Reimplement the traditional crypto API's "cmac(aes)", "xcbc(aes)", and "cbcmac(aes)" on top of the library - Convert mac80211 to use the AES-CMAC library. Note: several other subsystems can use it too and will be converted later - Drop the broken, nonstandard, and likely unused support for "xcbc(aes)" with key lengths other than 128 bits - Enable optimizations by default - GHASH - Migrate the standalone GHASH code into lib/crypto/ - Integrate the GHASH code more closely with the very similar POLYVAL code, and improve the generic GHASH implementation to resist cache-timing attacks and use much less memory - Reimplement the AES-GCM library and the "gcm" crypto_aead template on top of the GHASH library. Remove "ghash" from the crypto_shash API, as it's no longer needed - Enable optimizations by default - SM3 - Migrate the kernel's existing SM3 code into lib/crypto/, and reimplement the traditional crypto API's "sm3" on top of it - I don't recommend using SM3, but this cleanup is worthwhile to organize the code the same way as other algorithms - Testing improvements: - Add a KUnit test suite for each of the new library APIs - Migrate the existing ChaCha20Poly1305 test to KUnit - Make the KUnit all_tests.config enable all crypto library tests - Move the test kconfig options to the Runtime Testing menu - Other updates to arch-optimized crypto code: - Optimize SHA-256 for Zhaoxin CPUs using the Padlock Hash Engine - Remove some MD5 implementations that are no longer worth keeping - Drop big endian and voluntary preemption support from the arm64 code, as those configurations are no longer supported on arm64 - Make jitterentropy and samples/tsm-mr use the crypto library APIs * tag 'libcrypto-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux: (66 commits) lib/crypto: arm64: Assume a little-endian kernel arm64: fpsimd: Remove obsolete cond_yield macro lib/crypto: arm64/sha3: Remove obsolete chunking logic lib/crypto: arm64/sha512: Remove obsolete chunking logic lib/crypto: arm64/sha256: Remove obsolete chunking logic lib/crypto: arm64/sha1: Remove obsolete chunking logic lib/crypto: arm64/poly1305: Remove obsolete chunking logic lib/crypto: arm64/gf128hash: Remove obsolete chunking logic lib/crypto: arm64/chacha: Remove obsolete chunking logic lib/crypto: arm64/aes: Remove obsolete chunking logic lib/crypto: Include <crypto/utils.h> instead of <crypto/algapi.h> lib/crypto: aesgcm: Don't disable IRQs during AES block encryption lib/crypto: aescfb: Don't disable IRQs during AES block encryption lib/crypto: tests: Migrate ChaCha20Poly1305 self-test to KUnit lib/crypto: sparc: Drop optimized MD5 code lib/crypto: mips: Drop optimized MD5 code lib: Move crypto library tests to Runtime Testing menu crypto: sm3 - Remove 'struct sm3_state' crypto: sm3 - Remove the original "sm3_block_generic()" crypto: sm3 - Remove sm3_base.h ... 
Pull crypto library updates from Eric Biggers:

 - Migrate more hash algorithms from the traditional crypto subsystem to
   lib/crypto/

   Like the algorithms migrated earlier (e.g. SHA-*), this simplifies
   the implementations, improves performance, enables further
   simplifications in calling code, and solves various other issues:

     - AES CBC-based MACs (AES-CMAC, AES-XCBC-MAC, and AES-CBC-MAC)

         - Support these algorithms in lib/crypto/ using the AES library
           and the existing arm64 assembly code

         - Reimplement the traditional crypto API's "cmac(aes)",
           "xcbc(aes)", and "cbcmac(aes)" on top of the library

         - Convert mac80211 to use the AES-CMAC library. Note: several
           other subsystems can use it too and will be converted later

         - Drop the broken, nonstandard, and likely unused support for
           "xcbc(aes)" with key lengths other than 128 bits

         - Enable optimizations by default

     - GHASH

         - Migrate the standalone GHASH code into lib/crypto/

         - Integrate the GHASH code more closely with the very similar
           POLYVAL code, and improve the generic GHASH implementation to
           resist cache-timing attacks and use much less memory

         - Reimplement the AES-GCM library and the "gcm" crypto_aead
           template on top of the GHASH library. Remove "ghash" from the
           crypto_shash API, as it's no longer needed

         - Enable optimizations by default

     - SM3

         - Migrate the kernel's existing SM3 code into lib/crypto/, and
           reimplement the traditional crypto API's "sm3" on top of it

         - I don't recommend using SM3, but this cleanup is worthwhile
           to organize the code the same way as other algorithms

 - Testing improvements:

     - Add a KUnit test suite for each of the new library APIs

     - Migrate the existing ChaCha20Poly1305 test to KUnit

     - Make the KUnit all_tests.config enable all crypto library tests

     - Move the test kconfig options to the Runtime Testing menu

 - Other updates to arch-optimized crypto code:

     - Optimize SHA-256 for Zhaoxin CPUs using the Padlock Hash Engine

     - Remove some MD5 implementations that are no longer worth keeping

     - Drop big endian and voluntary preemption support from the arm64
       code, as those configurations are no longer supported on arm64

 - Make jitterentropy and samples/tsm-mr use the crypto library APIs

* tag 'libcrypto-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux: (66 commits)
  lib/crypto: arm64: Assume a little-endian kernel
  arm64: fpsimd: Remove obsolete cond_yield macro
  lib/crypto: arm64/sha3: Remove obsolete chunking logic
  lib/crypto: arm64/sha512: Remove obsolete chunking logic
  lib/crypto: arm64/sha256: Remove obsolete chunking logic
  lib/crypto: arm64/sha1: Remove obsolete chunking logic
  lib/crypto: arm64/poly1305: Remove obsolete chunking logic
  lib/crypto: arm64/gf128hash: Remove obsolete chunking logic
  lib/crypto: arm64/chacha: Remove obsolete chunking logic
  lib/crypto: arm64/aes: Remove obsolete chunking logic
  lib/crypto: Include <crypto/utils.h> instead of <crypto/algapi.h>
  lib/crypto: aesgcm: Don't disable IRQs during AES block encryption
  lib/crypto: aescfb: Don't disable IRQs during AES block encryption
  lib/crypto: tests: Migrate ChaCha20Poly1305 self-test to KUnit
  lib/crypto: sparc: Drop optimized MD5 code
  lib/crypto: mips: Drop optimized MD5 code
  lib: Move crypto library tests to Runtime Testing menu
  crypto: sm3 - Remove 'struct sm3_state'
  crypto: sm3 - Remove the original "sm3_block_generic()"
  crypto: sm3 - Remove sm3_base.h
  ...
lib/crypto: tests: Migrate ChaCha20Poly1305 self-test to KUnit 2026-03-30T19:35:30+00:00 Eric Biggers ebiggers@kernel.org 2026-03-27T22:42:29+00:00 d2a68aba8505ce88b39c34ecb3b707c776af79d4 Move the ChaCha20Poly1305 test from an ad-hoc self-test to a KUnit test. Keep the same test logic for now, just translated to KUnit. Moving to KUnit has multiple benefits, such as: - Consistency with the rest of the lib/crypto/ tests. - Kernel developers familiar with KUnit, which is used kernel-wide, can quickly understand the test and how to enable and run it. - The test will be automatically run by anyone using lib/crypto/.kunitconfig or KUnit's all_tests.config. - Results are reported using the standard KUnit mechanism. - It eliminates one of the few remaining back-references to crypto/ from lib/crypto/, specifically a reference to CONFIG_CRYPTO_SELFTESTS. Acked-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20260327224229.137532-1-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org> 
Move the ChaCha20Poly1305 test from an ad-hoc self-test to a KUnit test.

Keep the same test logic for now, just translated to KUnit.

Moving to KUnit has multiple benefits, such as:

- Consistency with the rest of the lib/crypto/ tests.

- Kernel developers familiar with KUnit, which is used kernel-wide, can
  quickly understand the test and how to enable and run it.

- The test will be automatically run by anyone using
  lib/crypto/.kunitconfig or KUnit's all_tests.config.

- Results are reported using the standard KUnit mechanism.

- It eliminates one of the few remaining back-references to crypto/ from
  lib/crypto/, specifically a reference to CONFIG_CRYPTO_SELFTESTS.

Acked-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://lore.kernel.org/r/20260327224229.137532-1-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>