Changes in Kconfig

cf52058dcdd96420cfc38ee284c5ac077901ea61 - lib/crypto: powerpc/md5: Drop powerpc optimized MD5 code

Wed, 06 May 2026 05:00:05 +0200

lib/crypto: powerpc/md5: Drop powerpc optimized MD5 codeMD5 is obsolete, is vulnerable to collision attacks, and is beingreplaced by SHA-256 in new systems. It doesn't make sense to continueto maintain architecture-optimized implementations of MD5. Effortshould be spent on modern algorithms.Indeed, architecture-optimized MD5 code remains only for powerpc. Itwas already removed from mips and sparc, and it never existed for anyother architecture (e.g. x86, arm, or arm64) in the first place.Earlier the decision was made to keep the powerpc MD5 code for a whileanyway 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 itscontinuous 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 towardsuserspace crypto code. It's always been the better solution anyway, andit's much more efficient if properly optimized code is used.Note that the md5-asm.S file contains no privileged instructions andcould be run in userspace just fine.Thus, we now have two factors going against keeping the powerpc MD5code. Different people might weigh these two factors differently, but Ithink the two of them together make the removal the clear choice.Let's remove it.Acked-by: Christophe Leroy (CS GROUP) Acked-by: Ard Biesheuvel Link: https://patch.msgid.link/20260506030005.9698-1-ebiggers@kernel.orgSigned-off-by: Eric Biggers List of files: /linux/lib/crypto/Kconfig

23e5c306a207360bfda4f8e96a229dd5fde81cbd - lib/crypto: sparc: Drop optimized MD5 code

Thu, 26 Mar 2026 21:33:41 +0100

lib/crypto: sparc: Drop optimized MD5 codeMD5 is obsolete. Continuing to maintain architecture-optimizedimplementations of MD5 is unnecessary and risky. It diverts resourcesfrom the modern algorithms that are actually important.While there was demand for continuing to maintain the PowerPC optimizedMD5 code to accommodate userspace programs that are misusing AF_ALG(https://lore.kernel.org/linux-crypto/c4191597-341d-4fd7-bc3d-13daf7666c41@csgroup.eu/),no such demand has been seen for the SPARC optimized MD5 code.Thus, let's drop it and focus effort on the more modern SHA algorithms,which already have optimized code for SPARC.Acked-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20260326203341.60393-1-ebiggers@kernel.orgSigned-off-by: Eric Biggers List of files: /linux/lib/crypto/Kconfig

91cd9a03372be647fff09acab525c15e9c9b66f0 - lib/crypto: mips: Drop optimized MD5 code

Thu, 26 Mar 2026 21:48:24 +0100

lib/crypto: mips: Drop optimized MD5 codeMD5 is obsolete. Continuing to maintain architecture-optimizedimplementations of MD5 is unnecessary and risky. It diverts resourcesfrom the modern algorithms that are actually important.While there was demand for continuing to maintain the PowerPC optimizedMD5 code to accommodate userspace programs that are misusing AF_ALG(https://lore.kernel.org/linux-crypto/c4191597-341d-4fd7-bc3d-13daf7666c41@csgroup.eu/),no such demand has been seen for the MIPS Cavium Octeon optimized MD5code. Note that this code runs on only one particular line of SoCs.Thus, let's drop it and focus effort on the more modern SHA algorithms,which already have optimized code for the same SoCs.Acked-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20260326204824.62010-1-ebiggers@kernel.orgSigned-off-by: Eric Biggers List of files: /linux/lib/crypto/Kconfig

7ac21b4032e5b9b8a6a312b6f1d54f4ba24d1c16 - lib: Move crypto library tests to Runtime Testing menu

Sun, 22 Mar 2026 04:24:38 +0100

lib: Move crypto library tests to Runtime Testing menuCurrently the kconfig options for the crypto library KUnit tests appearin the menu: -> Library routines -> Crypto library routinesHowever, this is the only content of "Crypto library routines". I.e.,it is empty when CONFIG_KUNIT=n. This is because the crypto libraryroutines themselves don't have (or need to have) prompts.Since this usually ends up as an unnecessary empty menu, let's removethis menu and instead source the lib/crypto/tests/Kconfig file fromlib/Kconfig.debug inside the "Runtime Testing" menu: -> Kernel hacking -> Kernel Testing and Coverage -> Runtime TestingThis puts the prompts alongside the ones for most of the other lib/KUnit tests. This seems to be a much better match to how the kconfigmenus are organized.Acked-by: Randy Dunlap Tested-by: Randy Dunlap Link: https://lore.kernel.org/r/20260322032438.286296-1-ebiggers@kernel.orgSigned-off-by: Eric Biggers List of files: /linux/lib/crypto/Kconfig

17ba6108d3e084652807826cc49c851c00976f1a - lib/crypto: x86/sm3: Migrate optimized code into library

Sat, 21 Mar 2026 05:09:32 +0100

lib/crypto: x86/sm3: Migrate optimized code into libraryInstead of exposing the x86-optimized SM3 code via an x86-specificcrypto_shash algorithm, instead just implement the sm3_blocks() libraryfunction. This is much simpler, it makes the SM3 library functions bex86-optimized, and it fixes the longstanding issue where thex86-optimized SM3 code was disabled by default. SM3 still remainsavailable through crypto_shash, but individual architectures no longerneed to handle it.Tweak the prototype of sm3_transform_avx() to match what the libraryexpects, including changing the block count to size_t. Note that theassembly code actually already treated this argument as size_t.Acked-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20260321040935.410034-10-ebiggers@kernel.orgSigned-off-by: Eric Biggers List of files: /linux/lib/crypto/Kconfig

5f6bbba5e9bb7f271557513d0ed77bb7b5a92698 - lib/crypto: riscv/sm3: Migrate optimized code into library

Sat, 21 Mar 2026 05:09:31 +0100

lib/crypto: riscv/sm3: Migrate optimized code into libraryInstead of exposing the riscv-optimized SM3 code via a riscv-specificcrypto_shash algorithm, instead just implement the sm3_blocks() libraryfunction. This is much simpler, it makes the SM3 library functions beriscv-optimized, and it fixes the longstanding issue where theriscv-optimized SM3 code was disabled by default. SM3 still remainsavailable through crypto_shash, but individual architectures no longerneed to handle it.Tweak the prototype of sm3_transform_zvksh_zvkb() to match what thelibrary expects, including changing the block count to size_t.Note that the assembly code already treated it as size_t.Note: to see the diff from arch/riscv/crypto/sm3-riscv64-glue.c tolib/crypto/riscv/sm3.h, view this commit with 'git show -M10'.Acked-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20260321040935.410034-9-ebiggers@kernel.orgSigned-off-by: Eric Biggers List of files: /linux/lib/crypto/Kconfig

9f69f52b462cdaed83b782d0408ce9286f054f92 - lib/crypto: arm64/sm3: Migrate optimized code into library

Sat, 21 Mar 2026 05:09:30 +0100

lib/crypto: arm64/sm3: Migrate optimized code into libraryInstead of exposing the arm64-optimized SM3 code via arm64-specificcrypto_shash algorithms, instead just implement the sm3_blocks() libraryfunction. This is much simpler, it makes the SM3 library functions bearm64-optimized, and it fixes the longstanding issue where thearm64-optimized SM3 code was disabled by default. SM3 still remainsavailable through crypto_shash, but individual architectures no longerneed to handle it.Tweak the SM3 assembly function prototypes to match what the libraryexpects, including changing the block count from 'int' to 'size_t'.sm3_ce_transform() had to be updated to access 'x2' instead of 'w2',while sm3_neon_transform() already used 'x2'.Remove the CFI stubs which are no longer needed because the SM3 assemblyfunctions are no longer ever indirectly called.Remove the dependency on KERNEL_MODE_NEON. It was unnecessary, becauseKERNEL_MODE_NEON is always enabled on arm64.Acked-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20260321040935.410034-8-ebiggers@kernel.orgSigned-off-by: Eric Biggers List of files: /linux/lib/crypto/Kconfig

324bb3bb75ac21adbbc7e6ea5cdb0a735fb78a56 - lib/crypto: sm3: Add SM3 library API

Sat, 21 Mar 2026 05:09:27 +0100

lib/crypto: sm3: Add SM3 library APIAdd a straightforward library API for SM3, mirroring the ones for theother hash algorithms. It uses the existing generic implementation ofSM3's compression function in lib/crypto/sm3.c. Hooks are added forarchitecture-optimized implementations, which later commits will wire upto the existing optimized SM3 code for arm64, riscv, and x86.Note that the rationale for this is *not* that SM3 should be used, orthat any kernel subsystem currently seems like a candidate for switchingfrom the sm3 crypto_shash to SM3 library. (SM3, in fact, shouldn't beused. Likewise you shouldn't use MD5, SHA-1, RC4, etc...)Rather, it's just that this will simplify how the kernel's existing SM3code is integrated and make it much easier to maintain and test. SM3 isone of the only hash algorithms with arch-optimized code that is stillintegrated in the old way. By converting it to the new lib/crypto/ codeorganization, we'll only have to keep track of one way of doing things.The library will also get a KUnit test suite (as usual for lib/crypto/),so it will become more easily and comprehensively tested as well.Skip adding functions for HMAC-SM3 for now, though. There's not as muchpoint in adding those right now.Note: similar to the other hash algorithms, the library API uses'struct sm3_ctx', not 'struct sm3_state'. The existing 'structsm3_state' and the sm3_block_generic() function which uses it aretemporarily kept around until their users are updated by later commits.Acked-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20260321040935.410034-5-ebiggers@kernel.orgSigned-off-by: Eric Biggers List of files: /linux/lib/crypto/Kconfig

ea0c746ffa1e6e701d39a564f6286a3f5740826b - lib/crypto: aesgcm: Use GHASH library API

Thu, 19 Mar 2026 07:17:20 +0100

lib/crypto: aesgcm: Use GHASH library APIMake the AES-GCM library use the GHASH library instead of directlycalling gf128mul_lle(). This allows the architecture-optimized GHASHimplementations to be used, or the improved generic implementation if noarchitecture-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.cwhich previously was relying on the transitive inclusion.Acked-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20260319061723.1140720-20-ebiggers@kernel.orgSigned-off-by: Eric Biggers List of files: /linux/lib/crypto/Kconfig

efd1d2c8f3c073c43d5616d0c2d698cbe8a3ecde - lib/crypto: s390/ghash: Migrate optimized code into library

Thu, 19 Mar 2026 07:17:14 +0100

lib/crypto: s390/ghash: Migrate optimized code into libraryRemove the "ghash-s390" crypto_shash algorithm, and replace it with animplementation of ghash_blocks_arch() for the GHASH library.This makes the GHASH library be optimized with CPACF. It also greatlyreduces the amount of s390-specific glue code that is needed, and itfixes the issue where this GHASH optimization was disabled by default.Acked-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20260319061723.1140720-14-ebiggers@kernel.orgSigned-off-by: Eric Biggers List of files: /linux/lib/crypto/Kconfig

af413d71f09d4dde28277319926c1c3a6ec8b8d4 - lib/crypto: riscv/ghash: Migrate optimized code into library

Thu, 19 Mar 2026 07:17:13 +0100

lib/crypto: riscv/ghash: Migrate optimized code into libraryRemove the "ghash-riscv64-zvkg" crypto_shash algorithm. Move thecorresponding assembly code into lib/crypto/, modify it to take thelength in blocks instead of bytes, and wire it up to the GHASH library.This makes the GHASH library be optimized with the RISC-V VectorCryptography Extension. It also greatly reduces the amount ofriscv-specific glue code that is needed, and it fixes the issue wherethis optimized GHASH code was disabled by default.Note that this RISC-V code has multiple opportunities for improvement,such as adding more parallelism, providing an optimized multiplicationfunction, and directly supporting POLYVAL. But for now, this commitsimply tweaks ghash_zvkg() slightly to make it compatible with thelibrary, then wires it up to ghash_blocks_arch().ghash_preparekey_arch() is also implemented to store the copy of the rawkey needed by the vghsh.vv instruction.Acked-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20260319061723.1140720-13-ebiggers@kernel.orgSigned-off-by: Eric Biggers List of files: /linux/lib/crypto/Kconfig

73f315c15d6ec1ef33202e7253af90dd44ff4a3b - lib/crypto: powerpc/ghash: Migrate optimized code into library

Thu, 19 Mar 2026 07:17:12 +0100

lib/crypto: powerpc/ghash: Migrate optimized code into libraryRemove the "p8_ghash" crypto_shash algorithm. Move the correspondingassembly code into lib/crypto/, and wire it up to the GHASH library.This makes the GHASH library be optimized for POWER8. It also greatlyreduces the amount of powerpc-specific glue code that is needed, and itfixes the issue where this optimized GHASH code was disabled by default.Note that previously the C code defined the POWER8 GHASH key format as"u128 htable[16]", despite the assembly code only using four entries.Fix the C code to use the correct key format. To fulfill the libraryAPI contract, also make the key preparation work in all contexts.Note that the POWER8 assembly code takes the accumulator in GHASHformat, but it actually byte-reflects it to get it into POLYVAL format.The library already works with POLYVAL natively. For now, just wire upthis existing code by converting it to/from GHASH format in C code.This should be cleaned up to eliminate the unnecessary conversion later.Acked-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20260319061723.1140720-12-ebiggers@kernel.orgSigned-off-by: Eric Biggers List of files: /linux/lib/crypto/Kconfig

71e59795c9f65a30416ed719b4b4da585df3903a - lib/crypto: arm/ghash: Migrate optimized code into library

Thu, 19 Mar 2026 07:17:08 +0100

lib/crypto: arm/ghash: Migrate optimized code into libraryRemove the "ghash-neon" crypto_shash algorithm. Move the correspondingassembly code into lib/crypto/, and wire it up to the GHASH library.This makes the GHASH library be optimized on arm (though only with NEON,not PMULL; for now the goal is just parity with crypto_shash). Itgreatly reduces the amount of arm-specific glue code that is needed, andit fixes the issue where this optimization was disabled by default.To integrate the assembly code correctly with the library, make thefollowing tweaks:- Change the type of 'blocks' from int to size_t.- Change the types of 'dg' and 'h' to polyval_elem. Note that this simply reflects the format that the code was already using, at least on little endian CPUs. For big endian CPUs, add byte-swaps.- Remove the 'head' argument, which is no longer needed.Acked-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20260319061723.1140720-8-ebiggers@kernel.orgSigned-off-by: Eric Biggers List of files: /linux/lib/crypto/Kconfig

61f66c5216a961784b12307be60a25204525605c - lib/crypto: gf128hash: Rename polyval module to gf128hash

Thu, 19 Mar 2026 07:17:02 +0100

lib/crypto: gf128hash: Rename polyval module to gf128hashCurrently, the standalone GHASH code is coupled with crypto_shash. Thishas resulted in unnecessary complexity and overhead, as well as the codebeing unavailable to library code such as the AES-GCM library. Like wasdone with POLYVAL, it needs to find a new home in lib/crypto/.GHASH and POLYVAL are closely related and can each be implemented interms of each other. Optimized code for one can be reused with theother. But also since GHASH tends to be difficult to implement directlydue to its unnatural bit order, most modern GHASH implementations(including the existing arm, arm64, powerpc, and x86 optimized GHASHcode, and the new generic GHASH code I'll be adding) actuallyreinterpret the GHASH computation as an equivalent POLYVAL computation,pre and post-processing the inputs and outputs to map to/from POLYVAL.Given this close relationship, it makes sense to group the GHASH andPOLYVAL code together in the same module. This gives us a wide range ofoptions for implementing them, reusing code between the two and properlyutilizing whatever instructions each architecture provides.Thus, GHASH support will be added to the library module that iscurrently called "polyval". Rename it to an appropriate name:"gf128hash". Rename files, options, functions, etc. where appropriateto reflect the upcoming sharing with GHASH. (Note: polyval_kunit is notrenamed, as ghash_kunit will be added alongside it instead.)Acked-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20260319061723.1140720-2-ebiggers@kernel.orgSigned-off-by: Eric Biggers List of files: /linux/lib/crypto/Kconfig

c2db2288b8c3e2878cc37962375419cca8dfe3b6 - lib/crypto: arm64: Drop checks for CONFIG_KERNEL_MODE_NEON

Sat, 14 Mar 2026 18:50:49 +0100

lib/crypto: arm64: Drop checks for CONFIG_KERNEL_MODE_NEONCONFIG_KERNEL_MODE_NEON is always enabled on arm64, and it always hasbeen since its introduction in 2013. Given that and the fact that theusefulness of kernel-mode NEON has only been increasing over time,checking for this option in arm64-specific code is unnecessary. Removethese checks from lib/crypto/ to simplify the code and prevent anyfuture bugs where e.g. code gets disabled due to a typo in this logic.Acked-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20260314175049.26931-1-ebiggers@kernel.orgSigned-off-by: Eric Biggers List of files: /linux/lib/crypto/Kconfig

309a7e514da7d53e05b5d053594f6aabb0d382b5 - lib/crypto: aes: Add support for CBC-based MACs

Wed, 18 Feb 2026 22:34:47 +0100

lib/crypto: aes: Add support for CBC-based MACsAdd support for CBC-based MACs to the AES library, specificallyAES-CMAC, AES-XCBC-MAC, and AES-CBC-MAC.Of these three algorithms, AES-CMAC is the most modern and the mostcommonly used. Use cases for the AES-CMAC library include the kernel'sSMB client and server, and the bluetooth and mac80211 drivers.Support for AES-XCBC-MAC and AES-CBC-MAC is included so that there willbe no performance regression in the "xcbc(aes)" and "ccm(aes)" supportin the traditional crypto API once the arm64-optimized code is migratedinto the library. AES-XCBC-MAC is given its own key preparationfunction but is otherwise identical to AES-CMAC and just reuses theAES-CMAC structs and functions.The implementation automatically uses the optimized AES key expansionand single block en/decryption functions. It also allows architecturesto provide an optimized implementation of aes_cbcmac_blocks(), whichallows the existing arm64-optimized code for these modes to be used.Just put the code for these modes directly in the libaes module ratherthan in a separate module. This is simpler, it makes it easier to sharecode between AES modes, and it increases the amount of inlining that ispossible. (Indeed, for these reasons, most of thearchitecture-optimized AES code already provides multiple modes permodule. x86 for example has only a single aesni-intel module. So to alarge extent, this design choice just reflects the status quo.)However, since there are a lot of AES modes, there's still some value inomitting modes that are not needed at all in a given kernel. Therefore,make these modes an optional feature of libaes, controlled byCONFIG_CRYPTO_LIB_AES_CBC_MACS. This seems like a good middle ground.Reviewed-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20260218213501.136844-2-ebiggers@kernel.orgSigned-off-by: Eric Biggers List of files: /linux/lib/crypto/Kconfig

24eb22d8161380eba65edc5b499299639cbe8bf9 - lib/crypto: x86/aes: Add AES-NI optimization

Mon, 12 Jan 2026 20:20:15 +0100

lib/crypto: x86/aes: Add AES-NI optimizationOptimize the AES library with x86 AES-NI instructions.The relevant existing assembly functions, aesni_set_key(), aesni_enc(),and aesni_dec(), are a bit difficult to extract into the library:- They're coupled to the code for the AES modes.- They operate on struct crypto_aes_ctx. The AES library now uses different structs.- They assume the key is 16-byte aligned. The AES library only *prefers* 16-byte alignment; it doesn't require it.Moreover, they're not all that great in the first place:- They use unrolled loops, which isn't a great choice on x86.- They use the 'aeskeygenassist' instruction, which is unnecessary, is slow on Intel CPUs, and forces the loop to be unrolled.- They have special code for AES-192 key expansion, despite that being kind of useless. AES-128 and AES-256 are the ones used in practice.These are small functions anyway.Therefore, I opted to just write replacements of these functions for thelibrary. They address all the above issues.Acked-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20260112192035.10427-18-ebiggers@kernel.orgSigned-off-by: Eric Biggers List of files: /linux/lib/crypto/Kconfig

293c7cd5c6c00f3b6fa0072fc4b017a3a13ad1e7 - lib/crypto: sparc/aes: Migrate optimized code into library

Mon, 12 Jan 2026 20:20:14 +0100

lib/crypto: sparc/aes: Migrate optimized code into libraryMove the SPARC64 AES assembly code into lib/crypto/, wire the keyexpansion and single-block en/decryption functions up to the AES libraryAPI, and remove the "aes-sparc64" crypto_cipher algorithm.The result is that both the AES library and crypto_cipher APIs use theSPARC64 AES opcodes, whereas previously only crypto_cipher did (and itwasn't enabled by default, which this commit fixes as well).Note that some of the functions in the SPARC64 AES assembly code arestill used by the AES mode implementations inarch/sparc/crypto/aes_glue.c. For now, just export these functions.These exports will go away once the AES mode implementations aremigrated to the library as well. (Trying to split up the assembly fileseemed like much more trouble than it would be worth.)Acked-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20260112192035.10427-17-ebiggers@kernel.orgSigned-off-by: Eric Biggers List of files: /linux/lib/crypto/Kconfig

0cab15611e839142f4fd3c8a366acd1f7334b30b - lib/crypto: s390/aes: Migrate optimized code into library

Mon, 12 Jan 2026 20:20:13 +0100

lib/crypto: s390/aes: Migrate optimized code into libraryImplement aes_preparekey_arch(), aes_encrypt_arch(), andaes_decrypt_arch() using the CPACF AES instructions.Then, remove the superseded "aes-s390" crypto_cipher.The result is that both the AES library and crypto_cipher APIs use theCPACF AES instructions, whereas previously only crypto_cipher did (andit wasn't enabled by default, which this commit fixes as well).Note that this preserves the optimization where the AES key is stored inraw form rather than expanded form. CPACF just takes the raw key.Acked-by: Ard Biesheuvel Tested-by: Holger Dengler Reviewed-by: Holger Dengler Link: https://lore.kernel.org/r/20260112192035.10427-16-ebiggers@kernel.orgSigned-off-by: Eric Biggers List of files: /linux/lib/crypto/Kconfig

a4e573db06a4e8c519ec4c42f8e1249a0853367a - lib/crypto: riscv/aes: Migrate optimized code into library

Mon, 12 Jan 2026 20:20:12 +0100

lib/crypto: riscv/aes: Migrate optimized code into libraryMove the aes_encrypt_zvkned() and aes_decrypt_zvkned() assemblyfunctions into lib/crypto/, wire them up to the AES library API, andremove the "aes-riscv64-zvkned" crypto_cipher algorithm.To make this possible, change the prototypes of these functions totake (rndkeys, key_len) instead of a pointer to crypto_aes_ctx, andchange the RISC-V AES-XTS code to implement tweak encryption using theAES library instead of directly calling aes_encrypt_zvkned().The result is that both the AES library and crypto_cipher APIs useRISC-V's AES instructions, whereas previously only crypto_cipher did(and it wasn't enabled by default, which this commit fixes as well).Acked-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20260112192035.10427-15-ebiggers@kernel.orgSigned-off-by: Eric Biggers List of files: /linux/lib/crypto/Kconfig