Changes in Makefile

fce8b8d5 - crypto: remove obsolete 'comp' compression API

Sun, 16 Mar 2025 01:21:27 +0000

crypto: remove obsolete 'comp' compression APIThe 'comp' compression API has been superseded by the acomp API, whichis a bit more cumbersome to use, but ultimately more flexible when itcomes to hardware implementations.Now that all the users and implementations have been removed, let'sremove the core plumbing of the 'comp' API as well.Signed-off-by: Ard Biesheuvel Signed-off-by: Herbert Xu List of files: /linux-6.15/crypto/Makefile

3241cd0c - crypto,fs: Separate out hkdf_extract() and hkdf_expand()

Mon, 24 Feb 2025 12:38:09 +0000

crypto,fs: Separate out hkdf_extract() and hkdf_expand()Separate out the HKDF functions into a separate module toto make them available to other callers.And add a testsuite to the module with test vectorsfrom RFC 5869 (and additional vectors for SHA384 and SHA512)to ensure the integrity of the algorithm.Signed-off-by: Hannes Reinecke Acked-by: Eric Biggers Acked-by: Herbert Xu Signed-off-by: Keith Busch List of files: /linux-6.15/crypto/Makefile

3936f02b - crypto/krb5: Implement Kerberos crypto core

Tue, 10 Nov 2020 17:00:54 +0000

crypto/krb5: Implement Kerberos crypto coreProvide core structures, an encoding-type registry and basic module andconfig bits for a generic Kerberos crypto library.Signed-off-by: David Howells cc: Herbert Xu cc: "David S. Miller" cc: Chuck Lever cc: Marc Dionne cc: Eric Dumazet cc: Jakub Kicinski cc: Paolo Abeni cc: Simon Horman cc: linux-afs@lists.infradead.orgcc: linux-nfs@vger.kernel.orgcc: linux-crypto@vger.kernel.orgcc: netdev@vger.kernel.org List of files: /linux-6.15/crypto/Makefile

d1775a17 - crypto: Add 'krb5enc' hash and cipher AEAD algorithm

Fri, 17 Jan 2025 11:46:23 +0000

crypto: Add 'krb5enc' hash and cipher AEAD algorithmAdd an AEAD template that does hash-then-cipher (unlike authenc that doescipher-then-hash). This is required for a number of Kerberos 5 encodingtypes.[!] Note that the net/sunrpc/auth_gss/ implementation gets a pair ofciphers, one non-CTS and one CTS, using the former to do all the alignedblocks and the latter to do the last two blocks if they aren't alsoaligned. It may be necessary to do this here too for performance reasons -but there are considerations both ways: (1) firstly, there is an optimised assembly version of cts(cbc(aes)) on x86_64 that should be used instead of having two ciphers; (2) secondly, none of the hardware offload drivers seem to offer CTS support (Intel QAT does not, for instance).However, I don't know if it's possible to query the crypto API to find outwhether there's an optimised CTS algorithm available.Signed-off-by: David Howells cc: Herbert Xu cc: "David S. Miller" cc: Chuck Lever cc: Marc Dionne cc: Eric Dumazet cc: Jakub Kicinski cc: Paolo Abeni cc: Simon Horman cc: linux-afs@lists.infradead.orgcc: linux-nfs@vger.kernel.orgcc: linux-crypto@vger.kernel.orgcc: netdev@vger.kernel.org List of files: /linux-6.15/crypto/Makefile

8522104f - crypto: crct10dif - remove from crypto API

Thu, 06 Feb 2025 17:38:57 +0000

crypto: crct10dif - remove from crypto APIRemove the "crct10dif" shash algorithm from the crypto API. It has noknown user now that the lib is no longer built on top of it. It has noremaining references in kernel code. The only other potential userswould be the usual components that allow specifying arbitrary hashalgorithms by name, namely AF_ALG and dm-integrity. However there areno indications that "crct10dif" is being used with these components.Debian Code Search and web searches don't find anything relevant, andexplicitly grepping the source code of the usual suspects (cryptsetup,libell, iwd) finds no matches either. "crc32" and "crc32c" are used ina few more places, but that doesn't seem to be the case for "crct10dif".crc_t10dif_update() is also tested by crc_kunit now, so the testcoverage provided via the crypto self-tests is no longer needed.Also note that the "crct10dif" shash algorithm was inconsistent with therest of the shash API in that it wrote the digest in CPU endianness,making the resulting byte array differ on little endian vs. big endianplatforms. This means it was effectively just built for use by the libfunctions, and it was not actually correct to treat it as "just anotherhash function" that could be dropped in via the shash API.Reviewed-by: Ard Biesheuvel Reviewed-by: "Martin K. Petersen" Link: https://lore.kernel.org/r/20250206173857.39794-1-ebiggers@kernel.orgSigned-off-by: Eric Biggers List of files: /linux-6.15/crypto/Makefile

0fcec0b7 - crypto: crc64-rocksoft - remove from crypto API

Thu, 30 Jan 2025 03:51:21 +0000

crypto: crc64-rocksoft - remove from crypto APIRemove crc64-rocksoft from the crypto API. It has no known user nowthat the lib is no longer built on top of it. It was also added muchmore recently than the longstanding crc32 and crc32c. Unlike crc32 andcrc32c, crc64-rocksoft is also not mentioned in the dm-integritydocumentation and there are no references to it in anywhere in thecryptsetup git repo, so it is unlikely to have any user there either.Also, this CRC variant is named incorrectly; it has nothing to do withRocksoft and should be called crc64-nvme. That is yet another reason toremove it from the crypto API; we would not want anyone to startdepending on the current incorrect algorithm name of crc64-rocksoft.Note that this change temporarily makes this CRC variant not be coveredby any tests, as previously it was relying on the crypto self-tests.This will be fixed by adding this CRC variant to crc_kunit.Reviewed-by: Ard Biesheuvel Reviewed-by: "Martin K. Petersen" Acked-by: Keith Busch Link: https://lore.kernel.org/r/20250130035130.180676-3-ebiggers@kernel.orgSigned-off-by: Eric Biggers List of files: /linux-6.15/crypto/Makefile

730f67d8 - crypto: keywrap - remove unused keywrap algorithm

Fri, 27 Dec 2024 22:08:02 +0000

crypto: keywrap - remove unused keywrap algorithmThe keywrap (kw) algorithm has no in-tree user. It has never had anin-tree user, and the patch that added it provided no justification forits inclusion. Even use of it via AF_ALG is impossible, as it uses aweird calling convention where part of the ciphertext is returned viathe IV buffer, which is not returned to userspace in AF_ALG.It's also unclear whether any new code in the kernel that does keywrapping would actually use this algorithm. It is controversial in thecryptographic community due to having no clearly stated security goal,no security proof, poor performance, and only a 64-bit auth tag. Laterwork (https://eprint.iacr.org/2006/221) suggested that the goal isdeterministic authenticated encryption. But there are now more modernalgorithms for this, and this is not the same as key wrapping, for whicha regular AEAD such as AES-GCM usually can be (and is) used instead.Therefore, remove this unused code.There were several special cases for this algorithm in the self-tests,due to its weird calling convention. Remove those too.Cc: Stephan Mueller Signed-off-by: Eric Biggers Acked-by: Ard Biesheuvel Acked-by: Geert Uytterhoeven # m68kSigned-off-by: Herbert Xu List of files: /linux-6.15/crypto/Makefile

2890601f - crypto: vmac - remove unused VMAC algorithm

Thu, 26 Dec 2024 19:43:08 +0000

crypto: vmac - remove unused VMAC algorithmRemove the vmac64 template, as it has no known users. It also continuesto have longstanding bugs such as alignment violations (seehttps://lore.kernel.org/r/20241226134847.6690-1-evepolonium@gmail.com/).This code was added in 2009 by commit f1939f7c5645 ("crypto: vmac - Newhash algorithm for intel_txt support"). Based on the mention ofintel_txt support in the commit title, it seems it was added as aprerequisite for the contemporaneous patch"intel_txt: add s3 userspace memory integrity verification"(https://lore.kernel.org/r/4ABF2B50.6070106@intel.com/). In the designproposed by that patch, when an Intel Trusted Execution Technology (TXT)enabled system resumed from suspend, the "tboot" trusted executablelaunched the Linux kernel without verifying userspace memory, and thenthe Linux kernel used VMAC to verify userspace memory.However, that patch was never merged, as reviewers had objected to thedesign. It was later reworked into commit 4bd96a7a8185 ("x86, tboot:Add support for S3 memory integrity protection") which made tboot verifythe memory instead. Thus the VMAC support in Linux was never used.No in-tree user has appeared since then, other than potentially theusual components that allow specifying arbitrary hash algorithms byname, namely AF_ALG and dm-integrity. However there are no indicationsthat VMAC is being used with these components. Debian Code Search andweb searches for "vmac64" (the actual algorithm name) do not return anyresults other than the kernel itself, suggesting that it does not appearin any other code or documentation. Explicitly grepping the source codeof the usual suspects (libell, iwd, cryptsetup) finds no matches either.Before 2018, the vmac code was also completely broken due to using ahardcoded nonce and the wrong endianness for the MAC. It was then fixedby commit ed331adab35b ("crypto: vmac - add nonced version with bigendian digest") and commit 0917b873127c ("crypto: vmac - remove insecureversion with hardcoded nonce"). These were intentionally breakingchanges that changed all the computed MAC values as well as thealgorithm name ("vmac" to "vmac64"). No complaints were ever receivedabout these breaking changes, strongly suggesting the absence of users.The reason I had put some effort into fixing this code in 2018 isbecause it was used by an out-of-tree driver. But if it is still neededin that particular out-of-tree driver, the code can be carried in thatdriver instead. There is no need to carry it upstream.Cc: Atharva Tiwari Cc: Shane Wang Signed-off-by: Eric Biggers Acked-by: Ard Biesheuvel Acked-by: Geert Uytterhoeven # m68kSigned-off-by: Herbert Xu List of files: /linux-6.15/crypto/Makefile

21dda37f - crypto: crct10dif - expose arch-optimized lib function

Mon, 02 Dec 2024 01:20:47 +0000

crypto: crct10dif - expose arch-optimized lib functionNow that crc_t10dif_update() may be directly optimized for eacharchitecture, make the shash driver for crct10dif register acrct10dif-$arch algorithm that uses it, instead of onlycrct10dif-generic which uses crc_t10dif_generic().The result is that architecture-optimized crct10dif will remainavailable through the shash API once the architectures implementcrc_t10dif_arch() instead of the shash API.Reviewed-by: Ard Biesheuvel Reviewed-by: Martin K. Petersen Link: https://lore.kernel.org/r/20241202012056.209768-4-ebiggers@kernel.orgSigned-off-by: Eric Biggers List of files: /linux-6.15/crypto/Makefile

be3c45b0 - lib/crc-t10dif: stop wrapping the crypto API

Mon, 02 Dec 2024 01:20:45 +0000

lib/crc-t10dif: stop wrapping the crypto APIIn preparation for making the CRC-T10DIF library directly optimized foreach architecture, like what has been done for CRC32, get rid of theweird layering where crc_t10dif_update() calls into the crypto API.Instead, move crc_t10dif_generic() into the crc-t10dif library module,and make crc_t10dif_update() just call crc_t10dif_generic().Acceleration will be reintroduced via crc_t10dif_arch() in the followingpatches.Reviewed-by: Ard Biesheuvel Reviewed-by: Martin K. Petersen Link: https://lore.kernel.org/r/20241202012056.209768-2-ebiggers@kernel.orgSigned-off-by: Eric Biggers List of files: /linux-6.15/crypto/Makefile

16739efa - crypto: crc32c - Provide crc32c-arch driver for accelerated library code

Wed, 16 Oct 2024 18:57:25 +0000

crypto: crc32c - Provide crc32c-arch driver for accelerated library codecrc32c-generic is currently backed by the architecture's CRC-32c librarycode, which may offer a variety of implementations depending on thecapabilities of the platform. These are not covered by the cryptosubsystem's fuzz testing capabilities because crc32c-generic is thereference driver that the fuzzing logic uses as a source of truth.Fix this by providing a crc32c-arch implementation which is based on thearch library code if available, and modify crc32c-generic so it isalways based on the generic C implementation. If the arch has no CRC-32clibrary code, this change does nothing.Signed-off-by: Ard Biesheuvel Signed-off-by: Herbert Xu List of files: /linux-6.15/crypto/Makefile

a37e5579 - crypto: crc32 - Provide crc32-arch driver for accelerated library code

Wed, 16 Oct 2024 18:57:24 +0000

crypto: crc32 - Provide crc32-arch driver for accelerated library codecrc32-generic is currently backed by the architecture's CRC-32 librarycode, which may offer a variety of implementations depending on thecapabilities of the platform. These are not covered by the cryptosubsystem's fuzz testing capabilities because crc32-generic is thereference driver that the fuzzing logic uses as a source of truth.Fix this by providing a crc32-arch implementation which is based on thearch library code if available, and modify crc32-generic so it isalways based on the generic C implementation. If the arch has no CRC-32library code, this change does nothing.Signed-off-by: Ard Biesheuvel Signed-off-by: Herbert Xu List of files: /linux-6.15/crypto/Makefile

b0416386 - crypto: ecdsa - Support P1363 signature decoding

Tue, 10 Sep 2024 14:30:28 +0000

crypto: ecdsa - Support P1363 signature decodingAlternatively to the X9.62 encoding of ecdsa signatures, which usesASN.1 and is already supported by the kernel, there's another commonencoding called P1363. It stores r and s as the concatenation of twobig endian, unsigned integers. The name originates from IEEE P1363.Add a P1363 template in support of the forthcoming SPDM library(Security Protocol and Data Model) for PCI device authentication.P1363 is prescribed by SPDM 1.2.1 margin no 44: "For ECDSA signatures, excluding SM2, in SPDM, the signature shall be the concatenation of r and s. The size of r shall be the size of the selected curve. Likewise, the size of s shall be the size of the selected curve. See BaseAsymAlgo in NEGOTIATE_ALGORITHMS for the size of r and s. The byte order for r and s shall be in big endian order. When placing ECDSA signatures into an SPDM signature field, r shall come first followed by s."Link: https://www.dmtf.org/sites/default/files/standards/documents/DSP0274_1.2.1.pdfSigned-off-by: Lukas Wunner Reviewed-by: Jonathan Cameron Reviewed-by: Stefan Berger Signed-off-by: Herbert Xu List of files: /linux-6.15/crypto/Makefile

d6793ff9 - crypto: ecdsa - Move X9.62 signature decoding into template

Tue, 10 Sep 2024 14:30:25 +0000

crypto: ecdsa - Move X9.62 signature decoding into templateUnlike the rsa driver, which separates signature decoding andsignature verification into two steps, the ecdsa driver does both in one.This restricts users to the one signature format currently supported(X9.62) and prevents addition of others such as P1363, which is neededby the forthcoming SPDM library (Security Protocol and Data Model) forPCI device authentication.Per Herbert's suggestion, change ecdsa to use a "raw" signature encodingand then implement X9.62 and P1363 as templates which convert theirrespective encodings to the raw one. One may then specify"x962(ecdsa-nist-XXX)" or "p1363(ecdsa-nist-XXX)" to pick the encoding.The present commit moves X9.62 decoding to a template. A separatecommit is going to introduce another template for P1363 decoding.The ecdsa driver internally represents a signature as two u64 arrays ofsize ECC_MAX_BYTES. This appears to be the most natural choice for theraw format as it can directly be used for verification without having tofurther decode signature data or copy it around.Repurpose all the existing test vectors for "x962(ecdsa-nist-XXX)" andcreate a duplicate of them to test the raw encoding.Link: https://lore.kernel.org/all/ZoHXyGwRzVvYkcTP@gondor.apana.org.au/Signed-off-by: Lukas Wunner Tested-by: Stefan Berger Signed-off-by: Herbert Xu List of files: /linux-6.15/crypto/Makefile

1e562dea - crypto: rsassa-pkcs1 - Migrate to sig_alg backend

Tue, 10 Sep 2024 14:30:16 +0000

crypto: rsassa-pkcs1 - Migrate to sig_alg backendA sig_alg backend has just been introduced with the intent of moving allasymmetric sign/verify algorithms to it one by one.Migrate the sign/verify operations from rsa-pkcs1pad.c to a separatersassa-pkcs1.c which uses the new backend.Consequently there are now two templates which build on the "rsa"akcipher_alg:* The existing "pkcs1pad" template, which is instantiated as an akcipher_instance and retains the encrypt/decrypt operations of RSAES-PKCS1-v1_5 (RFC 8017 sec 7.2).* The new "pkcs1" template, which is instantiated as a sig_instance and contains the sign/verify operations of RSASSA-PKCS1-v1_5 (RFC 8017 sec 8.2).In a separate step, rsa-pkcs1pad.c could optionally be renamed torsaes-pkcs1.c for clarity. Additional "oaep" and "pss" templatescould be added for RSAES-OAEP and RSASSA-PSS.Note that it's currently allowed to allocate a "pkcs1pad(rsa)" transformwithout specifying a hash algorithm. That makes sense if the transformis only used for encrypt/decrypt and continues to be supported. But forsign/verify, such transforms previously did not insert the Full HashPrefix into the padding. The resulting message encoding was incompliantwith EMSA-PKCS1-v1_5 (RFC 8017 sec 9.2) and therefore nonsensical.From here on in, it is no longer allowed to allocate a transform withoutspecifying a hash algorithm if the transform is used for sign/verifyoperations. This simplifies the code because the insertion of the FullHash Prefix is no longer optional, so various "if (digest_info)" clausescan be removed.There has been a previous attempt to forbid transform allocation withoutspecifying a hash algorithm, namely by commit c0d20d22e0ad ("crypto:rsa-pkcs1pad - Require hash to be present"). It had to be rolled backwith commit b3a8c8a5ebb5 ("crypto: rsa-pkcs1pad: Allow hash to beoptional [ver #2]"), presumably because it broke allocation of atransform which was solely used for encrypt/decrypt, not sign/verify.Avoid such breakage by allowing transform allocation for encrypt/decryptwith and without specifying a hash algorithm (and simply ignoring thehash algorithm in the former case).So again, specifying a hash algorithm is now mandatory for sign/verify,but optional and ignored for encrypt/decrypt.The new sig_alg API uses kernel buffers instead of sglists, whichavoids the overhead of copying signature and digest from sglists backinto kernel buffers. rsassa-pkcs1.c is thus simplified quite a bit.sig_alg is always synchronous, whereas the underlying "rsa" akcipher_algmay be asynchronous. So await the result of the akcipher_alg, similarto crypto_akcipher_sync_{en,de}crypt().As part of the migration, rename "rsa_digest_info" to "hash_prefix" toadhere to the spec language in RFC 9580. Otherwise keep the codeunmodified wherever possible to ease reviewing and bisecting. Leaveseveral simplification and hardening opportunities to separate commits.rsassa-pkcs1.c uses modern __free() syntax for allocation of bufferswhich need to be freed by kfree_sensitive(), hence a DEFINE_FREE()clause for kfree_sensitive() is introduced herein as a byproduct.Signed-off-by: Lukas Wunner Signed-off-by: Herbert Xu List of files: /linux-6.15/crypto/Makefile

46b3ff73 - crypto: sm2 - Remove sm2 algorithm

Fri, 31 May 2024 10:20:03 +0000

crypto: sm2 - Remove sm2 algorithmThe SM2 algorithm has a single user in the kernel. However, it'snever been integrated properly with that user: asymmetric_keys.The crux of the issue is that the way it computes its digest withsm3 does not fit into the architecture of asymmetric_keys. As nosolution has been proposed, remove this algorithm.It can be resubmitted when it is integrated properly into theasymmetric_keys subsystem.Signed-off-by: Herbert Xu List of files: /linux-6.15/crypto/Makefile

fda4f712 - bpf: crypto: add skcipher to bpf crypto

Mon, 22 Apr 2024 22:50:22 +0000

bpf: crypto: add skcipher to bpf cryptoImplement skcipher crypto in BPF crypto framework.Signed-off-by: Vadim Fedorenko Acked-by: Herbert Xu Link: https://lore.kernel.org/r/20240422225024.2847039-3-vadfed@meta.comSigned-off-by: Martin KaFai Lau List of files: /linux-6.15/crypto/Makefile

29ce50e0 - crypto: remove CONFIG_CRYPTO_STATS

Wed, 13 Mar 2024 03:48:21 +0000

crypto: remove CONFIG_CRYPTO_STATSRemove support for the "Crypto usage statistics" feature(CONFIG_CRYPTO_STATS). This feature does not appear to have ever beenused, and it is harmful because it significantly reduces performance andis a large maintenance burden.Covering each of these points in detail:1. Feature is not being usedSince these generic crypto statistics are only readable using netlink,it's fairly straightforward to look for programs that use them. I'munable to find any evidence that any such programs exist. For example,Debian Code Search returns no hits except the kernel header and kernelcode itself and translations of the kernel header:https://codesearch.debian.net/search?q=CRYPTOCFGA_STAT&literal=1&perpkg=1The patch series that added this feature in 2018(https://lore.kernel.org/linux-crypto/1537351855-16618-1-git-send-email-clabbe@baylibre.com/)said "The goal is to have an ifconfig for crypto device." This doesn'tappear to have happened.It's not clear that there is real demand for crypto statistics. Justbecause the kernel provides other types of statistics such as I/O andnetworking statistics and some people find those useful does not meanthat crypto statistics are useful too.Further evidence that programs are not using CONFIG_CRYPTO_STATS is thatit was able to be disabled in RHEL and Fedora as a bug fix(https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/2947).Even further evidence comes from the fact that there are and have beenbugs in how the stats work, but they were never reported. For example,before Linux v6.7 hash stats were double-counted in most cases.There has also never been any documentation for this feature, so itmight be hard to use even if someone wanted to.2. CONFIG_CRYPTO_STATS significantly reduces performanceEnabling CONFIG_CRYPTO_STATS significantly reduces the performance ofthe crypto API, even if no program ever retrieves the statistics. Thisprimarily affects systems with a large number of CPUs. For example,https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2039576 reportedthat Lustre client encryption performance improved from 21.7GB/s to48.2GB/s by disabling CONFIG_CRYPTO_STATS.It can be argued that this means that CONFIG_CRYPTO_STATS should beoptimized with per-cpu counters similar to many of the networkingcounters. But no one has done this in 5+ years. This is consistentwith the fact that the feature appears to be unused, so there seems tobe little interest in improving it as opposed to just disabling it.It can be argued that because CONFIG_CRYPTO_STATS is off by default,performance doesn't matter. But Linux distros tend to error on the sideof enabling options. The option is enabled in Ubuntu and Arch Linux,and until recently was enabled in RHEL and Fedora (see above). So, evenjust having the option available is harmful to users.3. CONFIG_CRYPTO_STATS is a large maintenance burdenThere are over 1000 lines of code associated with CONFIG_CRYPTO_STATS,spread among 32 files. It significantly complicates much of theimplementation of the crypto API. After the initial submission, manyfixes and refactorings have consumed effort of multiple people to keepthis feature "working". We should be spending this effort elsewhere.Acked-by: Ard Biesheuvel Acked-by: Corentin Labbe Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu List of files: /linux-6.15/crypto/Makefile

6a8dbd71 - Revert "crypto: remove CONFIG_CRYPTO_STATS"

Wed, 13 Mar 2024 01:49:37 +0000

Revert "crypto: remove CONFIG_CRYPTO_STATS"This reverts commit 2beb81fbf0c01a62515a1bcef326168494ee2bd0.While removing CONFIG_CRYPTO_STATS is a worthy goal, this alsoremoved unrelated infrastructure such as crypto_comp_alg_common.Signed-off-by: Herbert Xu List of files: /linux-6.15/crypto/Makefile

2beb81fb - crypto: remove CONFIG_CRYPTO_STATS

Fri, 23 Feb 2024 09:03:34 +0000

crypto: remove CONFIG_CRYPTO_STATSRemove support for the "Crypto usage statistics" feature(CONFIG_CRYPTO_STATS). This feature does not appear to have ever beenused, and it is harmful because it significantly reduces performance andis a large maintenance burden.Covering each of these points in detail:1. Feature is not being usedSince these generic crypto statistics are only readable using netlink,it's fairly straightforward to look for programs that use them. I'munable to find any evidence that any such programs exist. For example,Debian Code Search returns no hits except the kernel header and kernelcode itself and translations of the kernel header:https://codesearch.debian.net/search?q=CRYPTOCFGA_STAT&literal=1&perpkg=1The patch series that added this feature in 2018(https://lore.kernel.org/linux-crypto/1537351855-16618-1-git-send-email-clabbe@baylibre.com/)said "The goal is to have an ifconfig for crypto device." This doesn'tappear to have happened.It's not clear that there is real demand for crypto statistics. Justbecause the kernel provides other types of statistics such as I/O andnetworking statistics and some people find those useful does not meanthat crypto statistics are useful too.Further evidence that programs are not using CONFIG_CRYPTO_STATS is thatit was able to be disabled in RHEL and Fedora as a bug fix(https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/2947).Even further evidence comes from the fact that there are and have beenbugs in how the stats work, but they were never reported. For example,before Linux v6.7 hash stats were double-counted in most cases.There has also never been any documentation for this feature, so itmight be hard to use even if someone wanted to.2. CONFIG_CRYPTO_STATS significantly reduces performanceEnabling CONFIG_CRYPTO_STATS significantly reduces the performance ofthe crypto API, even if no program ever retrieves the statistics. Thisprimarily affects systems with large number of CPUs. For example,https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2039576 reportedthat Lustre client encryption performance improved from 21.7GB/s to48.2GB/s by disabling CONFIG_CRYPTO_STATS.It can be argued that this means that CONFIG_CRYPTO_STATS should beoptimized with per-cpu counters similar to many of the networkingcounters. But no one has done this in 5+ years. This is consistentwith the fact that the feature appears to be unused, so there seems tobe little interest in improving it as opposed to just disabling it.It can be argued that because CONFIG_CRYPTO_STATS is off by default,performance doesn't matter. But Linux distros tend to error on the sideof enabling options. The option is enabled in Ubuntu and Arch Linux,and until recently was enabled in RHEL and Fedora (see above). So, evenjust having the option available is harmful to users.3. CONFIG_CRYPTO_STATS is a large maintenance burdenThere are over 1000 lines of code associated with CONFIG_CRYPTO_STATS,spread among 32 files. It significantly complicates much of theimplementation of the crypto API. After the initial submission, manyfixes and refactorings have consumed effort of multiple people to keepthis feature "working". We should be spending this effort elsewhere.Cc: Corentin Labbe Signed-off-by: Eric Biggers Acked-by: Ard Biesheuvel Acked-by: Corentin Labbe Signed-off-by: Herbert Xu List of files: /linux-6.15/crypto/Makefile