Changes in Makefile

4964a1d9 - crypto: api - move crypto_simd_disabled_for_test to lib

Fri, 18 Oct 2024 23:53:43 +0000

crypto: api - move crypto_simd_disabled_for_test to libMove crypto_simd_disabled_for_test to lib/ so that crypto_simd_usable()can be used by library code.This was discussed previously(https://lore.kernel.org/linux-crypto/20220716062920.210381-4-ebiggers@kernel.org/)but was not done because there was no use case yet. However, this isnow needed for the arm64 CRC32 library code.Tested with: export ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- echo CONFIG_CRC32=y > .config echo CONFIG_MODULES=y >> .config echo CONFIG_CRYPTO=m >> .config echo CONFIG_DEBUG_KERNEL=y >> .config echo CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=n >> .config echo CONFIG_CRYPTO_MANAGER_EXTRA_TESTS=y >> .config make olddefconfig make -j$(nproc)Signed-off-by: Eric Biggers Acked-by: Ard Biesheuvel Signed-off-by: Herbert Xu List of files: /linux-6.15/lib/crypto/Makefile

f1354404 - crypto: lib - implement library version of AES in CFB mode

Mon, 29 Apr 2024 20:27:58 +0000

crypto: lib - implement library version of AES in CFB modeImplement AES in CFB mode using the existing, mostly constant-timegeneric AES library implementation. This will be used by the TPM codeto encrypt communications with TPM hardware, which is often a discretecomponent connected using sniffable wires or traces.While a CFB template does exist, using a skcipher is a major pain fornon-performance critical synchronous crypto where the algorithm is knownat compile time and the data is in contiguous buffers with valid kernelvirtual addresses.Tested-by: James Bottomley Reviewed-by: James Bottomley Reviewed-by: Jarkko Sakkinen Link: https://lore.kernel.org/all/20230216201410.15010-1-James.Bottomley@HansenPartnership.com/Signed-off-by: Ard Biesheuvel Signed-off-by: James Bottomley Tested-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen List of files: /linux-6.15/lib/crypto/Makefile

2a598d0b - crypto: lib - Move mpi into lib/crypto

Fri, 04 Aug 2023 09:24:34 +0000

crypto: lib - Move mpi into lib/cryptoAs lib/mpi is mostly used by crypto code, move it under lib/cryptoso that patches touching it get directed to the right mailing list.Signed-off-by: Herbert Xu Reviewed-by: Mimi Zohar Signed-off-by: Herbert Xu List of files: /linux-6.15/lib/crypto/Makefile

520af5da - crypto: lib/aesgcm - Provide minimal library implementation

Thu, 03 Nov 2022 19:22:59 +0000

crypto: lib/aesgcm - Provide minimal library implementationImplement a minimal library version of AES-GCM based on the existinglibrary implementations of AES and multiplication in GF(2^128). Usingthese primitives, GCM can be implemented in a straight-forward manner.GCM has a couple of sharp edges, i.e., the amount of input dataprocessed with the same initialization vector (IV) should be capped toprotect the counter from 32-bit rollover (or carry), and the size of theauthentication tag should be fixed for a given key. [0]The former concern is addressed trivially, given that the function callAPI uses 32-bit signed types for the input lengths. It is still up tothe caller to avoid IV reuse in general, but this is not something wecan police at the implementation level.As for the latter concern, let's make the authentication tag size partof the key schedule, and only permit it to be configured as part of thekey expansion routine.Note that table based AES implementations are susceptible to knownplaintext timing attacks on the encryption key. The AES library alreadyattempts to mitigate this to some extent, but given that the countermode encryption used by GCM operates exclusively on known plaintext byconstruction (the IV and therefore the initial counter value are knownto an attacker), let's take some extra care to mitigate this, by callingthe AES library with interrupts disabled.[0] https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-38d.pdfLink: https://lore.kernel.org/all/c6fb9b25-a4b6-2e4a-2dd1-63adda055a49@amd.com/Signed-off-by: Ard Biesheuvel Tested-by: Nikunj A Dadhania Signed-off-by: Herbert Xu List of files: /linux-6.15/lib/crypto/Makefile

61c581a4 - crypto: move gf128mul library into lib/crypto

Thu, 03 Nov 2022 19:22:57 +0000

crypto: move gf128mul library into lib/cryptoThe gf128mul library does not depend on the crypto API at all, so it canbe moved into lib/crypto. This will allow us to use it in other librarycode in a subsequent patch without having to depend on CONFIG_CRYPTO.While at it, change the Kconfig symbol name to align with other cryptolibrary implementations. However, the source file name is retained, asit is reflected in the module .ko filename, and changing this mightbreak things for users.Signed-off-by: Ard Biesheuvel Signed-off-by: Herbert Xu List of files: /linux-6.15/lib/crypto/Makefile

6e78ad0b - crypto: lib - move __crypto_xor into utils

Mon, 25 Jul 2022 18:36:35 +0000

crypto: lib - move __crypto_xor into utilsCRYPTO_LIB_CHACHA depends on CRYPTO for __crypto_xor, defined incrypto/algapi.c. This is a layering violation because the dependenciesshould only go in the other direction (crypto/ => lib/crypto/). Alsothe correct dependency would be CRYPTO_ALGAPI, not CRYPTO. Fix this bymoving __crypto_xor into the utils module in lib/crypto/.Note that CRYPTO_LIB_CHACHA_GENERIC selected XOR_BLOCKS, which isunrelated and unnecessary. It was perhaps thought that XOR_BLOCKS wasneeded for __crypto_xor, but that's not the case.Signed-off-by: Eric Biggers Reviewed-by: Jason A. Donenfeld Signed-off-by: Herbert Xu List of files: /linux-6.15/lib/crypto/Makefile

7033b937 - crypto: lib - create utils module and move __crypto_memneq into it

Mon, 25 Jul 2022 18:36:34 +0000

crypto: lib - create utils module and move __crypto_memneq into itAs requested athttps://lore.kernel.org/r/YtEgzHuuMts0YBCz@gondor.apana.org.au, move__crypto_memneq into lib/crypto/ and put it under a new tristate. Thetristate is CRYPTO_LIB_UTILS, and it builds a module libcryptoutils. Asmore crypto library utilities are being added, this creates a singleplace for them to go without cluttering up the main lib directory.The module's main file will be lib/crypto/utils.c. However, leavememneq.c as its own file because of its nonstandard license.Signed-off-by: Eric Biggers Reviewed-by: Jason A. Donenfeld Signed-off-by: Herbert Xu List of files: /linux-6.15/lib/crypto/Makefile

ec8f7f48 - crypto: lib - make the sha1 library optional

Sat, 09 Jul 2022 21:18:49 +0000

crypto: lib - make the sha1 library optionalSince the Linux RNG no longer uses sha1_transform(), the SHA-1 libraryis no longer needed unconditionally. Make it possible to build theLinux kernel without the SHA-1 library by putting it behind a kconfigoption, and selecting this new option from the kconfig options that gatethe remaining users: CRYPTO_SHA1 for crypto/sha1_generic.c, BPF forkernel/bpf/core.c, and IPV6 for net/ipv6/addrconf.c.Unfortunately, since BPF is selected by NET, for now this can only makea difference for kernels built without networking support.Signed-off-by: Eric Biggers Reviewed-by: Jason A. Donenfeld Acked-by: Jakub Kicinski Acked-by: Alexei Starovoitov Signed-off-by: Herbert Xu List of files: /linux-6.15/lib/crypto/Makefile

463f7408 - crypto: lib - move lib/sha1.c into lib/crypto/

Sat, 09 Jul 2022 21:18:48 +0000

crypto: lib - move lib/sha1.c into lib/crypto/SHA-1 is a crypto algorithm (or at least was intended to be -- it's notconsidered secure anymore), so move it out of the top-level librarydirectory and into lib/crypto/.Signed-off-by: Eric Biggers Reviewed-by: Jason A. Donenfeld Signed-off-by: Herbert Xu List of files: /linux-6.15/lib/crypto/Makefile

d2825fa9 - crypto: sm3,sm4 - move into crypto directory

Mon, 14 Mar 2022 03:11:01 +0000

crypto: sm3,sm4 - move into crypto directoryThe lib/crypto libraries live in lib because they are used by variousdrivers of the kernel. In contrast, the various helper functions incrypto are there because they're used exclusively by the crypto API. TheSM3 and SM4 helper functions were erroniously moved into lib/crypto/instead of crypto/, even though there are no in-kernel users outside ofthe crypto API of those functions. This commit moves them into crypto/.Cc: Herbert Xu Cc: Tianjia Zhang Cc: Eric Biggers Signed-off-by: Jason A. Donenfeld Signed-off-by: Herbert Xu List of files: /linux-6.15/lib/crypto/Makefile

eb90686d - crypto: sm3 - create SM3 stand-alone library

Fri, 07 Jan 2022 12:06:55 +0000

crypto: sm3 - create SM3 stand-alone libraryStand-alone implementation of the SM3 algorithm. It is designedto have as little dependencies as possible. In other cases youshould generally use the hash APIs from include/crypto/hash.h.Especially when hashing large amounts of data as those APIs maybe hw-accelerated. In the new SM3 stand-alone library,sm3_transform() has also been optimized, instead of simply usingthe code in sm3_generic.Signed-off-by: Tianjia Zhang Reviewed-by: Gilad Ben-Yossef Signed-off-by: Herbert Xu List of files: /linux-6.15/lib/crypto/Makefile

6048fdcc - lib/crypto: blake2s: include as built-in

Wed, 22 Dec 2021 13:56:58 +0000

lib/crypto: blake2s: include as built-inIn preparation for using blake2s in the RNG, we change the way that itis wired-in to the build system. Instead of using ifdefs to select theright symbol, we use weak symbols. And because ARM doesn't need thegeneric implementation, we make the generic one default only if an archlibrary doesn't need it already, and then have arch libraries that doneed it opt-in. So that the arch libraries can remain tristate ratherthan bool, we then split the shash part from the glue code.Acked-by: Herbert Xu Acked-by: Ard Biesheuvel Acked-by: Greg Kroah-Hartman Cc: Masahiro Yamada Cc: linux-kbuild@vger.kernel.orgCc: linux-crypto@vger.kernel.orgSigned-off-by: Jason A. Donenfeld List of files: /linux-6.15/lib/crypto/Makefile

2b31277a - crypto: sm4 - create SM4 library based on sm4 generic code

Tue, 20 Jul 2021 03:46:39 +0000

crypto: sm4 - create SM4 library based on sm4 generic codeTake the existing small footprint and mostly time invariant C codeand turn it into a SM4 library that can be used for non-performancecritical, casual use of SM4, and as a fallback for, e.g., SIMD codethat needs a secondary path that can be taken in contexts where theSIMD unit is off limits.Secondly, some codes have been optimized, such as unrolling smalltimes loop, removing unnecessary memory shifts, exporting sbox, fk,ck arrays, and basic encryption and decryption functions.Signed-off-by: Tianjia Zhang Signed-off-by: Herbert Xu List of files: /linux-6.15/lib/crypto/Makefile

b16838c6 - kbuild: trace functions in subdirectories of lib/

Tue, 07 Jul 2020 09:21:17 +0000

kbuild: trace functions in subdirectories of lib/ccflags-remove-$(CONFIG_FUNCTION_TRACER) += $(CC_FLAGS_FTRACE)exists here in sub-directories of lib/ to keep the behavior ofcommit 2464a609ded0 ("ftrace: do not trace library functions").Since that commit, not only the objects in lib/ but also the ones inthe sub-directories are excluded from ftrace (although the commitdescription did not explicitly mention this).However, most of library functions in sub-directories are not so hot.Re-add them to ftrace.Going forward, only the objects right under lib/ will be excluded.Cc: Ingo Molnar Signed-off-by: Masahiro Yamada Acked-by: Steven Rostedt (VMware) List of files: /linux-6.15/lib/crypto/Makefile

15d5761a - kbuild: introduce ccflags-remove-y and asflags-remove-y

Tue, 07 Jul 2020 09:21:16 +0000

kbuild: introduce ccflags-remove-y and asflags-remove-yCFLAGS_REMOVE_.o filters out flags when compiling a particularobject, but there is no convenient way to do that for every object ina directory.Add ccflags-remove-y and asflags-remove-y to make it easily.Use ccflags-remove-y to clean up some Makefiles.The add/remove order works as follows: [1] KBUILD_CFLAGS specifies compiler flags used globally [2] ccflags-y adds compiler flags for all objects in the current Makefile [3] ccflags-remove-y removes compiler flags for all objects in the current Makefile (New feature) [4] CFLAGS_ adds compiler flags per file. [5] CFLAGS_REMOVE_ removes compiler flags per file.Having [3] before [4] allows us to remove flags from most (but not all)objects in the current Makefile.For example, kernel/trace/Makefile removes $(CC_FLAGS_FTRACE)from all objects in the directory, then adds it back totrace_selftest_dynamic.o and CFLAGS_trace_kprobe_selftest.oThe same applies to lib/livepatch/Makefile.Please note ccflags-remove-y has no effect to the sub-directories.In contrast, the previous notation got rid of compiler flags also fromall the sub-directories.The following are not affected because they have no sub-directories: arch/arm/boot/compressed/ arch/powerpc/xmon/ arch/sh/ kernel/trace/However, lib/ has several sub-directories.To keep the behavior, I added ccflags-remove-y to all Makefilesin subdirectories of lib/, except the following: lib/vdso/Makefile - Kbuild does not descend into this Makefile lib/raid/test/Makefile - This is not used for the kernel buildI think commit 2464a609ded0 ("ftrace: do not trace library functions")excluded too much. In the next commit, I will remove ccflags-remove-yfrom the sub-directories of lib/.Suggested-by: Sami Tolvanen Signed-off-by: Masahiro Yamada Acked-by: Steven Rostedt (VMware) Acked-by: Michael Ellerman (powerpc)Acked-by: Brendan Higgins (KUnit)Tested-by: Anders Roxell List of files: /linux-6.15/lib/crypto/Makefile

a8bdf2c4 - crypto: curve25519 - Fix selftest build error

Wed, 08 Jan 2020 04:37:35 +0000

crypto: curve25519 - Fix selftest build errorIf CRYPTO_CURVE25519 is y, CRYPTO_LIB_CURVE25519_GENERIC will bey, but CRYPTO_LIB_CURVE25519 may be set to m, this causes builderrors:lib/crypto/curve25519-selftest.o: In function `curve25519':curve25519-selftest.c:(.text.unlikely+0xc): undefined reference to `curve25519_arch'lib/crypto/curve25519-selftest.o: In function `curve25519_selftest':curve25519-selftest.c:(.init.text+0x17e): undefined reference to `curve25519_base_arch'This is because the curve25519 self-test code is being controlledby the GENERIC option rather than the overall CURVE25519 option,as is the case with blake2s. To recap, the GENERIC and ARCH optionsfor CURVE25519 are internal only and selected by users such asthe Crypto API, or the externally visible CURVE25519 option whichin turn is selected by wireguard. The self-test is specific to thethe external CURVE25519 option and should not be enabled by theCrypto API.This patch fixes this by splitting the GENERIC module from theCURVE25519 module with the latter now containing just the self-test.Reported-by: Hulk Robot Fixes: aa127963f1ca ("crypto: lib/curve25519 - re-add selftests")Signed-off-by: Herbert Xu Reviewed-by: Jason A. Donenfeld Signed-off-by: Herbert Xu List of files: /linux-6.15/lib/crypto/Makefile

1c08a104 - crypto: poly1305 - add new 32 and 64-bit generic versions

Mon, 06 Jan 2020 03:40:46 +0000

crypto: poly1305 - add new 32 and 64-bit generic versionsThese two C implementations from Zinc -- a 32x32 one and a 64x64 one,depending on the platform -- come from Andrew Moon's public domainpoly1305-donna portable code, modified for usage in the kernel. Theprecomputation in the 32-bit version and the use of 64x64 multiplies inthe 64-bit version make these perform better than the code it replaces.Moon's code is also very widespread and has received many eyeballs ofscrutiny.There's a bit of interference between the x86 implementation, whichrelies on internal details of the old scalar implementation. In the nextcommit, the x86 implementation will be replaced with a faster one thatdoesn't rely on this, so none of this matters much. But for now, to keepthis passing the tests, we inline the bits of the old implementationthat the x86 implementation relied on. Also, since we now support aslightly larger key space, via the union, some offsets had to be fixedup.Nonce calculation was folded in with the emit function, to takeadvantage of 64x64 arithmetic. However, Adiantum appeared to rely on nononce handling in emit, so this path was conditionalized. We alsointroduced a new struct, poly1305_core_key, to represent the preciseamount of space that particular implementation uses.Testing with kbench9000, depending on the CPU, the update function forthe 32x32 version has been improved by 4%-7%, and for the 64x64 by19%-30%. The 32x32 gains are small, but I think there's great value inhaving a parallel implementation to the 64x64 one so that the two can becompared side-by-side as nice stand-alone units.Signed-off-by: Jason A. Donenfeld Signed-off-by: Herbert Xu List of files: /linux-6.15/lib/crypto/Makefile

aa127963 - crypto: lib/curve25519 - re-add selftests

Mon, 16 Dec 2019 18:53:26 +0000

crypto: lib/curve25519 - re-add selftestsSomehow these were dropped when Zinc was being integrated, which isproblematic, because testing the library interface for Curve25519 isimportant.. This commit simply adds them back and wires them in in thesame way that the blake2s selftests are wired in.Signed-off-by: Jason A. Donenfeld Signed-off-by: Herbert Xu List of files: /linux-6.15/lib/crypto/Makefile

ed20078b - crypto: chacha20poly1305 - import construction and selftest from Zinc

Fri, 08 Nov 2019 12:22:39 +0000

crypto: chacha20poly1305 - import construction and selftest from ZincThis incorporates the chacha20poly1305 from the Zinc library, retainingthe library interface, but replacing the implementation with calls intothe code that already existed in the kernel's crypto API.Note that this library API does not implement RFC7539 fully, given thatit is limited to 64-bit nonces. (The 96-bit nonce version that was partof the selftest only has been removed, along with the 96-bit nonce testvectors that only tested the selftest but not the actual library itself)Signed-off-by: Ard Biesheuvel Signed-off-by: Herbert Xu List of files: /linux-6.15/lib/crypto/Makefile

0ed42a6f - crypto: curve25519 - generic C library implementations

Fri, 08 Nov 2019 12:22:32 +0000

crypto: curve25519 - generic C library implementationsThis contains two formally verified C implementations of the Curve25519scalar multiplication function, one for 32-bit systems, and one for64-bit systems whose compiler supports efficient 128-bit integer types.Not only are these implementations formally verified, but they are alsothe fastest available C implementations. They have been modified to befriendly to kernel space and to be generally less horrendous looking,but still an effort has been made to retain their formally verifiedcharacteristic, and so the C might look slightly unidiomatic.The 64-bit version comes from HACL*: https://github.com/project-everest/hacl-starThe 32-bit version comes from Fiat: https://github.com/mit-plv/fiat-cryptoInformation: https://cr.yp.to/ecdh.htmlSigned-off-by: Jason A. Donenfeld [ardb: - move from lib/zinc to lib/crypto - replace .c #includes with Kconfig based object selection - drop simd handling and simplify support for per-arch versions ]Signed-off-by: Ard Biesheuvel Signed-off-by: Herbert Xu List of files: /linux-6.15/lib/crypto/Makefile