Changes in Makefile

1684e829 - arm/crc-t10dif: expose CRC-T10DIF function through lib

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

arm/crc-t10dif: expose CRC-T10DIF function through libMove the arm CRC-T10DIF assembly code into the lib directory and wire itup to the library interface. This allows it to be used without goingthrough the crypto API. It remains usable via the crypto API too viathe shash algorithms that use the library interface. Thus all thearch-specific "shash" code becomes unnecessary and is removed.Note: to see the diff from arch/arm/crypto/crct10dif-ce-glue.c toarch/arm/lib/crc-t10dif-glue.c, view this commit with 'git show -M10'.Reviewed-by: Ard Biesheuvel Reviewed-by: Martin K. Petersen Link: https://lore.kernel.org/r/20241202012056.209768-6-ebiggers@kernel.orgSigned-off-by: Eric Biggers List of files: /linux-6.15/arch/arm/crypto/Makefile

1e1b6dbc - arm/crc32: expose CRC32 functions through lib

Mon, 02 Dec 2024 01:08:30 +0000

arm/crc32: expose CRC32 functions through libMove the arm CRC32 assembly code into the lib directory and wire it upto the library interface. This allows it to be used without goingthrough the crypto API. It remains usable via the crypto API too viathe shash algorithms that use the library interface. Thus all thearch-specific "shash" code becomes unnecessary and is removed.Note: to see the diff from arch/arm/crypto/crc32-ce-glue.c toarch/arm/lib/crc32-glue.c, view this commit with 'git show -M10'.Reviewed-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20241202010844.144356-6-ebiggers@kernel.orgSigned-off-by: Eric Biggers List of files: /linux-6.15/arch/arm/crypto/Makefile

2f62847c - ARM: 9287/1: Reduce thumb2 definition to crypto files that require it

Wed, 18 Jan 2023 19:29:02 +0000

ARM: 9287/1: Reduce __thumb2__ definition to crypto files that require itCommit 1d2e9b67b001 ("ARM: 9265/1: pass -march= only to compiler") addeda __thumb2__ define to ASFLAGS to avoid build errors in the crypto code,which relies on __thumb2__ for preprocessing. Commit 59e2cf8d21e0 ("ARM:9275/1: Drop '-mthumb' from AFLAGS_ISA") followed up on this by removing-mthumb from AFLAGS so that __thumb2__ would not be defined when thedefault target was ARMv7 or newer.Unfortunately, the second commit's fix assumes that the toolchaindefaults to -mno-thumb / -marm, which is not the case for Debian'sarm-linux-gnueabihf target, which defaults to -mthumb: $ echo | arm-linux-gnueabihf-gcc -dM -E - | grep __thumb #define __thumb2__ 1 #define __thumb__ 1This target is used by several CI systems, which will still seeredefined macro warnings, despite '-mthumb' not being present in theflags: : warning: "__thumb2__" redefined : note: this is the location of the previous definitionRemove the global AFLAGS __thumb2__ define and move it to the cryptofolder where it is required by the imported OpenSSL algorithms; the restof the kernel should use the internal CONFIG_THUMB2_KERNEL symbol toknow whether or not Thumb2 is being used or not. Be sure that __thumb2__is undefined first so that there are no macro redefinition warnings.Link: https://github.com/ClangBuiltLinux/linux/issues/1772Reported-by: "kernelci.org bot" Suggested-by: Ard Biesheuvel Signed-off-by: Nathan Chancellor Reviewed-by: Nick Desaulniers Tested-by: Nick Desaulniers Fixes: 59e2cf8d21e0 ("ARM: 9275/1: Drop '-mthumb' from AFLAGS_ISA")Fixes: 1d2e9b67b001 ("ARM: 9265/1: pass -march= only to compiler")Signed-off-by: Russell King (Oracle) List of files: /linux-6.15/arch/arm/crypto/Makefile

2d16803c - crypto: blake2s - remove shash module

Sat, 28 May 2022 19:44:07 +0000

crypto: blake2s - remove shash moduleBLAKE2s has no currently known use as an shash. Just remove all of thisunnecessary plumbing. Removing this shash was something we talked aboutback when we were making BLAKE2s a built-in, but I simply never gotaround to doing it. So this completes that project.Importantly, this fixs a bug in which the lib code depends oncrypto_simd_disabled_for_test, causing linker errors.Also add more alignment tests to the selftests and compare SIMD andnon-SIMD compression functions, to make up for what we lose fromtestmgr.c.Reported-by: gaochao Cc: Eric Biggers Cc: Ard Biesheuvel Cc: stable@vger.kernel.orgFixes: 6048fdcc5f26 ("lib/crypto: blake2s: include as built-in")Signed-off-by: Jason A. Donenfeld Signed-off-by: Herbert Xu List of files: /linux-6.15/arch/arm/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/arch/arm/crypto/Makefile

8116138c - crypto: arm - use a pattern rule for generating *.S files

Sun, 25 Apr 2021 17:57:32 +0000

crypto: arm - use a pattern rule for generating *.S filesUnify similar build rules.Signed-off-by: Masahiro Yamada Signed-off-by: Herbert Xu List of files: /linux-6.15/arch/arm/crypto/Makefile

7c0303ff - crypto: arm - generate *.S by Perl at build time instead of shipping them

Sun, 25 Apr 2021 17:57:31 +0000

crypto: arm - generate *.S by Perl at build time instead of shipping themGenerate *.S by Perl like arch/{mips,x86}/crypto/Makefile.Signed-off-by: Masahiro Yamada Signed-off-by: Herbert Xu List of files: /linux-6.15/arch/arm/crypto/Makefile

1862eb00 - crypto: arm/blake2b - add NEON-accelerated BLAKE2b

Wed, 23 Dec 2020 08:10:03 +0000

crypto: arm/blake2b - add NEON-accelerated BLAKE2bAdd a NEON-accelerated implementation of BLAKE2b.On Cortex-A7 (which these days is the most common ARM processor thatdoesn't have the ARMv8 Crypto Extensions), this is over twice as fast asSHA-256, and slightly faster than SHA-1. It is also almost three timesas fast as the generic implementation of BLAKE2b: Algorithm Cycles per byte (on 4096-byte messages) =================== ======================================= blake2b-256-neon 14.0 sha1-neon 16.3 blake2s-256-arm 18.8 sha1-asm 20.8 blake2s-256-generic 26.0 sha256-neon 28.9 sha256-asm 32.0 blake2b-256-generic 38.9This implementation isn't directly based on any other implementation,but it borrows some ideas from previous NEON code I've written as wellas from chacha-neon-core.S. At least on Cortex-A7, it is faster thanthe other NEON implementations of BLAKE2b I'm aware of (theimplementation in the BLAKE2 official repository using intrinsics, andAndrew Moon's implementation which can be found in SUPERCOP). It doesonly one block at a time, so it performs well on short messages too.NEON-accelerated BLAKE2b is useful because there is interest in usingBLAKE2b-256 for dm-verity on low-end Android devices (specifically,devices that lack the ARMv8 Crypto Extensions) to replace SHA-1. Onthese devices, the performance cost of upgrading to SHA-256 may beunacceptable, whereas BLAKE2b-256 would actually improve performance.Although BLAKE2b is intended for 64-bit platforms (unlike BLAKE2s whichis intended for 32-bit platforms), on 32-bit ARM processors with NEON,BLAKE2b is actually faster than BLAKE2s. This is because NEON supports64-bit operations, and because BLAKE2s's block size is too small forNEON to be helpful for it. The best I've been able to do with BLAKE2son Cortex-A7 is 18.8 cpb with an optimized scalar implementation.(I didn't try BLAKE2sp and BLAKE3, which in theory would be faster, butthey're more complex as they require running multiple hashes at once.Note that BLAKE2b already uses all the NEON bandwidth on the Cortex-A7,so I expect that any speedup from BLAKE2sp or BLAKE3 would come onlyfrom the smaller number of rounds, not from the extra parallelism.)For now this BLAKE2b implementation is only wired up to the shash API,since there is no library API for BLAKE2b yet. However, I've tried tokeep things consistent with BLAKE2s, e.g. by definingblake2b_compress_arch() which is analogous to blake2s_compress_arch()and could be exported for use by the library API later if needed.Acked-by: Ard Biesheuvel Signed-off-by: Eric Biggers Tested-by: Ard Biesheuvel Signed-off-by: Herbert Xu List of files: /linux-6.15/arch/arm/crypto/Makefile

5172d322 - crypto: arm/blake2s - add ARM scalar optimized BLAKE2s

Wed, 23 Dec 2020 08:09:59 +0000

crypto: arm/blake2s - add ARM scalar optimized BLAKE2sAdd an ARM scalar optimized implementation of BLAKE2s.NEON isn't very useful for BLAKE2s because the BLAKE2s block size is toosmall for NEON to help. Each NEON instruction would depend on theprevious one, resulting in poor performance.With scalar instructions, on the other hand, we can take advantage ofARM's "free" rotations (like I did in chacha-scalar-core.S) to get animplementation get runs much faster than the C implementation.Performance results on Cortex-A7 in cycles per byte using the shash API: 4096-byte messages: blake2s-256-arm: 18.8 blake2s-256-generic: 26.0 500-byte messages: blake2s-256-arm: 20.3 blake2s-256-generic: 27.9 100-byte messages: blake2s-256-arm: 29.7 blake2s-256-generic: 39.2 32-byte messages: blake2s-256-arm: 50.6 blake2s-256-generic: 66.2Except on very short messages, this is still slower than the NEONimplementation of BLAKE2b which I've written; that is 14.0, 16.4, 25.8,and 76.1 cpb on 4096, 500, 100, and 32-byte messages, respectively.However, optimized BLAKE2s is useful for cases where BLAKE2s is usedinstead of BLAKE2b, such as WireGuard.This new implementation is added in the form of a new moduleblake2s-arm.ko, which is analogous to blake2s-x86_64.ko in that itprovides blake2s_compress_arch() for use by the library API as well asoptionally register the algorithms with the shash API.Acked-by: Ard Biesheuvel Signed-off-by: Eric Biggers Tested-by: Ard Biesheuvel Signed-off-by: Herbert Xu List of files: /linux-6.15/arch/arm/crypto/Makefile

d8f1308a - crypto: arm/curve25519 - wire up NEON implementation

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

crypto: arm/curve25519 - wire up NEON implementationThis ports the SUPERCOP implementation for usage in kernel space. Inaddition to the usual header, macro, and style changes required forkernel space, it makes a few small changes to the code: - The stack alignment is relaxed to 16 bytes. - Superfluous mov statements have been removed. - ldr for constants has been replaced with movw. - ldreq has been replaced with moveq. - The str epilogue has been made more idiomatic. - SIMD registers are not pushed and popped at the beginning and end. - The prologue and epilogue have been made idiomatic. - A hole has been removed from the stack, saving 32 bytes. - We write-back the base register whenever possible for vld1.8. - Some multiplications have been reordered for better A7 performance.There are more opportunities for cleanup, since this code is from qhasm,which doesn't always do the most opportune thing. But even prior toextensive hand optimizations, this code delivers significant performanceimprovements (given in get_cycles() per call): ----------- ------------- | generic C | this commit | ------------ ----------- ------------- | Cortex-A7 | 49136 | 22395 | ------------ ----------- ------------- | Cortex-A17 | 17326 | 4983 | ------------ ----------- -------------Signed-off-by: Jason A. Donenfeld [ardb: - move to arch/arm/crypto - wire into lib/crypto framework - implement crypto API KPP hooks ]Signed-off-by: Ard Biesheuvel Signed-off-by: Herbert Xu List of files: /linux-6.15/arch/arm/crypto/Makefile

a6b803b3 - crypto: arm/poly1305 - incorporate OpenSSL/CRYPTOGAMS NEON implementation

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

crypto: arm/poly1305 - incorporate OpenSSL/CRYPTOGAMS NEON implementationThis is a straight import of the OpenSSL/CRYPTOGAMS Poly1305 implementationfor NEON authored by Andy Polyakov, and contributed by him to the OpenSSLproject. The file 'poly1305-armv4.pl' is taken straight from this upstreamGitHub repository [0] at commit ec55a08dc0244ce570c4fc7cade330c60798952f,and already contains all the changes required to build it as part of aLinux kernel module.[0] https://github.com/dot-asm/cryptogamsCo-developed-by: Andy Polyakov Signed-off-by: Andy Polyakov Signed-off-by: Ard Biesheuvel Signed-off-by: Herbert Xu List of files: /linux-6.15/arch/arm/crypto/Makefile

b36d8c09 - crypto: arm/chacha - remove dependency on generic ChaCha driver

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

crypto: arm/chacha - remove dependency on generic ChaCha driverInstead of falling back to the generic ChaCha skcipher driver fornon-SIMD cases, use a fast scalar implementation for ARM authoredby Eric Biggers. This removes the module dependency on chacha-genericaltogether, which also simplifies things when we expose the ChaChalibrary interface from this module.Signed-off-by: Ard Biesheuvel Signed-off-by: Herbert Xu List of files: /linux-6.15/arch/arm/crypto/Makefile

b4d0c0aa - crypto: arm - use Kconfig based compiler checks for crypto opcodes

Fri, 11 Oct 2019 09:08:00 +0000

crypto: arm - use Kconfig based compiler checks for crypto opcodesInstead of allowing the Crypto Extensions algorithms to be selected whenusing a toolchain that does not support them, and complain about it atbuild time, use the information we have about the compiler to preventthem from being selected in the first place. Users that are stuck witha GCC version <4.8 are unlikely to care about these routines anyway, andit cleans up the Makefile considerably.While at it, add explicit 'armv8-a' CPU specifiers to the code that usesthe 'crypto-neon-fp-armv8' FPU specifier so we don't regress Clang, whichwill complain about this in version 10 and later.Signed-off-by: Ard Biesheuvel Signed-off-by: Herbert Xu List of files: /linux-6.15/arch/arm/crypto/Makefile

8e9b61b2 - kbuild: move .SECONDARY special target to Kbuild.include

Sat, 01 Dec 2018 00:27:15 +0000

kbuild: move .SECONDARY special target to Kbuild.includeIn commit 54a702f70589 ("kbuild: mark $(targets) as .SECONDARY andremove .PRECIOUS markers"), I missed one important feature of the.SECONDARY target: .SECONDARY with no prerequisites causes all targets to be treated as secondary.... which agrees with the policy of Kbuild.Let's move it to scripts/Kbuild.include, with no prerequisites.Note:If an intermediate file is generated by $(call if_changed,...), youstill need to add it to "targets" so its .*.cmd file is included.The arm/arm64 crypto files are generated by $(call cmd,shipped),so they do not need to be added to "targets", but need to be addedto "clean-files" so "make clean" can properly clean them away.Signed-off-by: Masahiro Yamada List of files: /linux-6.15/arch/arm/crypto/Makefile

16aae359 - crypto: arm/nhpoly1305 - add NEON-accelerated NHPoly1305

Sat, 17 Nov 2018 01:26:30 +0000

crypto: arm/nhpoly1305 - add NEON-accelerated NHPoly1305Add an ARM NEON implementation of NHPoly1305, an ε-almost-∆-universalhash function used in the Adiantum encryption mode. For now, only theNH portion is actually NEON-accelerated; the Poly1305 part is lessperformance-critical so is just implemented in C.Signed-off-by: Eric Biggers Reviewed-by: Ard Biesheuvel Signed-off-by: Herbert Xu List of files: /linux-6.15/arch/arm/crypto/Makefile

3cc21519 - crypto: arm/chacha20 - refactor to allow varying number of rounds

Sat, 17 Nov 2018 01:26:25 +0000

crypto: arm/chacha20 - refactor to allow varying number of roundsIn preparation for adding XChaCha12 support, rename/refactor the NEONimplementation of ChaCha20 to support different numbers of rounds.Reviewed-by: Ard Biesheuvel Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu List of files: /linux-6.15/arch/arm/crypto/Makefile

578bdaab - crypto: speck - remove Speck

Tue, 07 Aug 2018 06:22:25 +0000

crypto: speck - remove SpeckThese are unused, undesired, and have never actually been used byanybody. The original authors of this code have changed their mind aboutits inclusion. While originally proposed for disk encryption on low-enddevices, the idea was discarded [1] in favor of something else beforethat could really get going. Therefore, this patch removes Speck.[1] https://marc.info/?l=linux-crypto-vger&m=153359499015659Signed-off-by: Jason A. Donenfeld Acked-by: Eric Biggers Cc: stable@vger.kernel.orgAcked-by: Ard Biesheuvel Signed-off-by: Herbert Xu List of files: /linux-6.15/arch/arm/crypto/Makefile

54a702f7 - kbuild: mark $(targets) as .SECONDARY and remove .PRECIOUS markers

Fri, 23 Mar 2018 13:04:39 +0000

kbuild: mark $(targets) as .SECONDARY and remove .PRECIOUS markersGNU Make automatically deletes intermediate files that are updatedin a chain of pattern rules.Example 1) %.dtb.o <- %.dtb.S <- %.dtb <- %.dtsExample 2) %.o <- %.c <- %.c_shippedA couple of makefiles mark such targets as .PRECIOUS to prevent Makefrom deleting them, but the correct way is to use .SECONDARY. .SECONDARY Prerequisites of this special target are treated as intermediate files but are never automatically deleted. .PRECIOUS When make is interrupted during execution, it may delete the target file it is updating if the file was modified since make started. If you mark the file as precious, make will never delete the file if interrupted.Both can avoid deletion of intermediate files, but the difference isthe behavior when Make is interrupted; .SECONDARY deletes the target,but .PRECIOUS does not.The use of .PRECIOUS is relatively rare since we do not want to keeppartially constructed (possibly corrupted) targets.Another difference is that .PRECIOUS works with pattern rules whereas.SECONDARY does not. .PRECIOUS: $(obj)/%.lex.cworks, but .SECONDARY: $(obj)/%.lex.chas no effect. However, for the reason above, I do not want to use.PRECIOUS which could cause obscure build breakage.The targets specified as .SECONDARY must be explicit. $(targets)contains all targets that need to include .*.cmd files. So, theintermediates you want to keep are mostly in there. Therefore, mark$(targets) as .SECONDARY. It means primary targets are also markedas .SECONDARY, but I do not see any drawback for this.I replaced some .SECONDARY / .PRECIOUS markers with 'targets'. Thiswill make Kbuild search for non-existing .*.cmd files, but this isnot a noticeable performance issue.Signed-off-by: Masahiro Yamada Acked-by: Frank Rowand Acked-by: Ingo Molnar List of files: /linux-6.15/arch/arm/crypto/Makefile

6aaf49b4 - crypto: arm,arm64 - Fix random regeneration of S_shipped

Tue, 13 Mar 2018 20:17:23 +0000

crypto: arm,arm64 - Fix random regeneration of S_shippedThe decision to rebuild .S_shipped is made based on the relativetimestamps of .S_shipped and .pl files but git makes this essentiallyrandom. This means that the perl script might run anyway (usually atmost once per checkout), defeating the whole purpose of _shipped.Fix by skipping the rule unless explicit make variables are provided:REGENERATE_ARM_CRYPTO or REGENERATE_ARM64_CRYPTO.This can produce nasty occasional build failures downstream, for examplefor toolchains with broken perl. The solution is minimally intrusive tomake it easier to push into stable.Another report on a similar issue here: https://lkml.org/lkml/2018/3/8/1379Signed-off-by: Leonard Crestez Cc: Reviewed-by: Masahiro Yamada Acked-by: Ard Biesheuvel Signed-off-by: Herbert Xu List of files: /linux-6.15/arch/arm/crypto/Makefile

ede96221 - crypto: arm/speck - add NEON-accelerated implementation of Speck-XTS

Wed, 14 Feb 2018 18:42:21 +0000

crypto: arm/speck - add NEON-accelerated implementation of Speck-XTSAdd an ARM NEON-accelerated implementation of Speck-XTS. It operates on128-byte chunks at a time, i.e. 8 blocks for Speck128 or 16 blocks forSpeck64. Each 128-byte chunk goes through XTS preprocessing, then isencrypted/decrypted (doing one cipher round for all the blocks, then thenext round, etc.), then goes through XTS postprocessing.The performance depends on the processor but can be about 3 times fasterthan the generic code. For example, on an ARMv7 processor we observethe following performance with Speck128/256-XTS: xts-speck128-neon: Encryption 107.9 MB/s, Decryption 108.1 MB/s xts(speck128-generic): Encryption 32.1 MB/s, Decryption 36.6 MB/sIn comparison to AES-256-XTS without the Cryptography Extensions: xts-aes-neonbs: Encryption 41.2 MB/s, Decryption 36.7 MB/s xts(aes-asm): Encryption 31.7 MB/s, Decryption 30.8 MB/s xts(aes-generic): Encryption 21.2 MB/s, Decryption 20.9 MB/sSpeck64/128-XTS is even faster: xts-speck64-neon: Encryption 138.6 MB/s, Decryption 139.1 MB/sNote that as with the generic code, only the Speck128 and Speck64variants are supported. Also, for now only the XTS mode of operation issupported, to target the disk and file encryption use cases. The NEONcode also only handles the portion of the data that is evenly divisibleinto 128-byte chunks, with any remainder handled by a C fallback. Ofcourse, other modes of operation could be added later if needed, and/orthe NEON code could be updated to handle other buffer sizes.The XTS specification is only defined for AES which has a 128-bit blocksize, so for the GF(2^64) math needed for Speck64-XTS we use thereducing polynomial 'x^64 + x^4 + x^3 + x + 1' given by the original XEXpaper. Of course, when possible users should use Speck128-XTS, but eventhat may be too slow on some processors; Speck64-XTS can be faster.Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu List of files: /linux-6.15/arch/arm/crypto/Makefile