2019-06-12 18:19:53 +02:00
|
|
|
# SPDX-License-Identifier: GPL-2.0
|
|
|
|
|
|
2025-06-30 09:03:11 -07:00
|
|
|
aflags-thumb2-$(CONFIG_THUMB2_KERNEL) := -U__thumb2__ -D__thumb2__=1
|
|
|
|
|
|
|
|
|
|
quiet_cmd_perlasm = PERLASM $@
|
|
|
|
|
cmd_perlasm = $(PERL) $(<) > $(@)
|
|
|
|
|
|
2025-06-30 09:03:12 -07:00
|
|
|
quiet_cmd_perlasm_with_args = PERLASM $@
|
|
|
|
|
cmd_perlasm_with_args = $(PERL) $(<) void $(@)
|
|
|
|
|
|
2025-07-09 13:01:10 -07:00
|
|
|
obj-$(CONFIG_KUNIT) += tests/
|
|
|
|
|
|
2025-06-30 10:22:23 -07:00
|
|
|
obj-$(CONFIG_CRYPTO_HASH_INFO) += hash_info.o
|
|
|
|
|
|
2022-07-25 11:36:34 -07:00
|
|
|
obj-$(CONFIG_CRYPTO_LIB_UTILS) += libcryptoutils.o
|
2022-07-25 11:36:35 -07:00
|
|
|
libcryptoutils-y := memneq.o utils.o
|
2022-07-25 11:36:34 -07:00
|
|
|
|
2019-11-08 13:22:08 +01:00
|
|
|
# chacha is used by the /dev/random driver which is always builtin
|
|
|
|
|
obj-y += chacha.o
|
|
|
|
|
obj-$(CONFIG_CRYPTO_LIB_CHACHA_GENERIC) += libchacha.o
|
|
|
|
|
|
2019-11-08 13:22:07 +01:00
|
|
|
obj-$(CONFIG_CRYPTO_LIB_AES) += libaes.o
|
|
|
|
|
libaes-y := aes.o
|
2019-07-02 21:41:22 +02:00
|
|
|
|
2024-04-29 16:27:58 -04:00
|
|
|
obj-$(CONFIG_CRYPTO_LIB_AESCFB) += libaescfb.o
|
|
|
|
|
libaescfb-y := aescfb.o
|
|
|
|
|
|
crypto: lib/aesgcm - Provide minimal library implementation
Implement a minimal library version of AES-GCM based on the existing
library implementations of AES and multiplication in GF(2^128). Using
these primitives, GCM can be implemented in a straight-forward manner.
GCM has a couple of sharp edges, i.e., the amount of input data
processed with the same initialization vector (IV) should be capped to
protect the counter from 32-bit rollover (or carry), and the size of the
authentication tag should be fixed for a given key. [0]
The former concern is addressed trivially, given that the function call
API uses 32-bit signed types for the input lengths. It is still up to
the caller to avoid IV reuse in general, but this is not something we
can police at the implementation level.
As for the latter concern, let's make the authentication tag size part
of the key schedule, and only permit it to be configured as part of the
key expansion routine.
Note that table based AES implementations are susceptible to known
plaintext timing attacks on the encryption key. The AES library already
attempts to mitigate this to some extent, but given that the counter
mode encryption used by GCM operates exclusively on known plaintext by
construction (the IV and therefore the initial counter value are known
to an attacker), let's take some extra care to mitigate this, by calling
the AES library with interrupts disabled.
[0] https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-38d.pdf
Link: https://lore.kernel.org/all/c6fb9b25-a4b6-2e4a-2dd1-63adda055a49@amd.com/
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Nikunj A Dadhania <nikunj@amd.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2022-11-03 20:22:59 +01:00
|
|
|
obj-$(CONFIG_CRYPTO_LIB_AESGCM) += libaesgcm.o
|
|
|
|
|
libaesgcm-y := aesgcm.o
|
|
|
|
|
|
2019-11-08 13:22:07 +01:00
|
|
|
obj-$(CONFIG_CRYPTO_LIB_ARC4) += libarc4.o
|
|
|
|
|
libarc4-y := arc4.o
|
2019-08-15 12:01:09 +03:00
|
|
|
|
2022-11-03 20:22:57 +01:00
|
|
|
obj-$(CONFIG_CRYPTO_LIB_GF128MUL) += gf128mul.o
|
|
|
|
|
|
2021-12-22 14:56:58 +01:00
|
|
|
# blake2s is used by the /dev/random driver which is always builtin
|
|
|
|
|
obj-y += libblake2s.o
|
|
|
|
|
libblake2s-y := blake2s.o
|
|
|
|
|
libblake2s-$(CONFIG_CRYPTO_LIB_BLAKE2S_GENERIC) += blake2s-generic.o
|
2025-05-05 13:33:41 -07:00
|
|
|
libblake2s-$(CONFIG_CRYPTO_SELFTESTS) += blake2s-selftest.o
|
2019-11-08 13:22:28 +01:00
|
|
|
|
2019-11-08 13:22:39 +01:00
|
|
|
obj-$(CONFIG_CRYPTO_LIB_CHACHA20POLY1305) += libchacha20poly1305.o
|
|
|
|
|
libchacha20poly1305-y += chacha20poly1305.o
|
2025-05-05 13:33:41 -07:00
|
|
|
libchacha20poly1305-$(CONFIG_CRYPTO_SELFTESTS) += chacha20poly1305-selftest.o
|
2019-11-08 13:22:39 +01:00
|
|
|
|
2020-01-08 12:37:35 +08:00
|
|
|
obj-$(CONFIG_CRYPTO_LIB_CURVE25519_GENERIC) += libcurve25519-generic.o
|
|
|
|
|
libcurve25519-generic-y := curve25519-fiat32.o
|
|
|
|
|
libcurve25519-generic-$(CONFIG_ARCH_SUPPORTS_INT128) := curve25519-hacl64.o
|
|
|
|
|
libcurve25519-generic-y += curve25519-generic.o
|
lib/crypto/curve25519-hacl64: Disable KASAN with clang-17 and older
After commit 6f110a5e4f99 ("Disable SLUB_TINY for build testing"), which
causes CONFIG_KASAN to be enabled in allmodconfig again, arm64
allmodconfig builds with clang-17 and older show an instance of
-Wframe-larger-than (which breaks the build with CONFIG_WERROR=y):
lib/crypto/curve25519-hacl64.c:757:6: error: stack frame size (2336) exceeds limit (2048) in 'curve25519_generic' [-Werror,-Wframe-larger-than]
757 | void curve25519_generic(u8 mypublic[CURVE25519_KEY_SIZE],
| ^
When KASAN is disabled, the stack usage is roughly quartered:
lib/crypto/curve25519-hacl64.c:757:6: error: stack frame size (608) exceeds limit (128) in 'curve25519_generic' [-Werror,-Wframe-larger-than]
757 | void curve25519_generic(u8 mypublic[CURVE25519_KEY_SIZE],
| ^
Using '-Rpass-analysis=stack-frame-layout' shows the following variables
and many, many 8-byte spills when KASAN is enabled:
Offset: [SP-144], Type: Variable, Align: 8, Size: 40
Offset: [SP-464], Type: Variable, Align: 8, Size: 320
Offset: [SP-784], Type: Variable, Align: 8, Size: 320
Offset: [SP-864], Type: Variable, Align: 32, Size: 80
Offset: [SP-896], Type: Variable, Align: 32, Size: 32
Offset: [SP-1016], Type: Variable, Align: 8, Size: 120
When KASAN is disabled, there are still spills but not at many and the
variables list is smaller:
Offset: [SP-192], Type: Variable, Align: 32, Size: 80
Offset: [SP-224], Type: Variable, Align: 32, Size: 32
Offset: [SP-344], Type: Variable, Align: 8, Size: 120
Disable KASAN for this file when using clang-17 or older to avoid
blowing out the stack, clearing up the warning.
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Acked-by: "Jason A. Donenfeld" <Jason@zx2c4.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://lore.kernel.org/r/20250609-curve25519-hacl64-disable-kasan-clang-v1-1-08ea0ac5ccff@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
2025-06-09 15:45:20 -07:00
|
|
|
# clang versions prior to 18 may blow out the stack with KASAN
|
|
|
|
|
ifeq ($(call clang-min-version, 180000),)
|
|
|
|
|
KASAN_SANITIZE_curve25519-hacl64.o := n
|
|
|
|
|
endif
|
2020-01-08 12:37:35 +08:00
|
|
|
|
|
|
|
|
obj-$(CONFIG_CRYPTO_LIB_CURVE25519) += libcurve25519.o
|
2019-11-08 13:22:32 +01:00
|
|
|
libcurve25519-y += curve25519.o
|
2025-05-05 13:33:41 -07:00
|
|
|
libcurve25519-$(CONFIG_CRYPTO_SELFTESTS) += curve25519-selftest.o
|
2019-11-08 13:22:32 +01:00
|
|
|
|
2019-11-08 13:22:07 +01:00
|
|
|
obj-$(CONFIG_CRYPTO_LIB_DES) += libdes.o
|
|
|
|
|
libdes-y := des.o
|
2019-08-17 16:24:33 +02:00
|
|
|
|
2025-05-06 10:05:08 +08:00
|
|
|
obj-$(CONFIG_CRYPTO_LIB_POLY1305) += libpoly1305.o
|
crypto: poly1305 - add new 32 and 64-bit generic versions
These two C implementations from Zinc -- a 32x32 one and a 64x64 one,
depending on the platform -- come from Andrew Moon's public domain
poly1305-donna portable code, modified for usage in the kernel. The
precomputation in the 32-bit version and the use of 64x64 multiplies in
the 64-bit version make these perform better than the code it replaces.
Moon's code is also very widespread and has received many eyeballs of
scrutiny.
There's a bit of interference between the x86 implementation, which
relies on internal details of the old scalar implementation. In the next
commit, the x86 implementation will be replaced with a faster one that
doesn't rely on this, so none of this matters much. But for now, to keep
this passing the tests, we inline the bits of the old implementation
that the x86 implementation relied on. Also, since we now support a
slightly larger key space, via the union, some offsets had to be fixed
up.
Nonce calculation was folded in with the emit function, to take
advantage of 64x64 arithmetic. However, Adiantum appeared to rely on no
nonce handling in emit, so this path was conditionalized. We also
introduced a new struct, poly1305_core_key, to represent the precise
amount of space that particular implementation uses.
Testing with kbench9000, depending on the CPU, the update function for
the 32x32 version has been improved by 4%-7%, and for the 64x64 by
19%-30%. The 32x32 gains are small, but I think there's great value in
having a parallel implementation to the 64x64 one so that the two can be
compared side-by-side as nice stand-alone units.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-01-05 22:40:46 -05:00
|
|
|
libpoly1305-y += poly1305.o
|
2019-11-08 13:22:19 +01:00
|
|
|
|
2025-05-06 10:05:08 +08:00
|
|
|
obj-$(CONFIG_CRYPTO_LIB_POLY1305_GENERIC) += libpoly1305-generic.o
|
|
|
|
|
libpoly1305-generic-y := poly1305-donna32.o
|
|
|
|
|
libpoly1305-generic-$(CONFIG_ARCH_SUPPORTS_INT128) := poly1305-donna64.o
|
|
|
|
|
libpoly1305-generic-y += poly1305-generic.o
|
|
|
|
|
|
2025-07-12 16:22:54 -07:00
|
|
|
################################################################################
|
|
|
|
|
|
|
|
|
|
obj-$(CONFIG_CRYPTO_LIB_SHA1) += libsha1.o
|
|
|
|
|
libsha1-y := sha1.o
|
|
|
|
|
ifeq ($(CONFIG_CRYPTO_LIB_SHA1_ARCH),y)
|
|
|
|
|
CFLAGS_sha1.o += -I$(src)/$(SRCARCH)
|
2025-07-12 16:22:58 -07:00
|
|
|
ifeq ($(CONFIG_ARM),y)
|
|
|
|
|
libsha1-y += arm/sha1-armv4-large.o
|
|
|
|
|
libsha1-$(CONFIG_KERNEL_MODE_NEON) += arm/sha1-armv7-neon.o \
|
|
|
|
|
arm/sha1-ce-core.o
|
|
|
|
|
endif
|
2025-07-12 16:22:59 -07:00
|
|
|
libsha1-$(CONFIG_ARM64) += arm64/sha1-ce-core.o
|
2025-07-12 16:23:01 -07:00
|
|
|
ifeq ($(CONFIG_PPC),y)
|
|
|
|
|
libsha1-y += powerpc/sha1-powerpc-asm.o
|
|
|
|
|
libsha1-$(CONFIG_SPE) += powerpc/sha1-spe-asm.o
|
|
|
|
|
endif
|
2025-07-12 16:23:03 -07:00
|
|
|
libsha1-$(CONFIG_SPARC) += sparc/sha1_asm.o
|
2025-07-12 16:23:04 -07:00
|
|
|
libsha1-$(CONFIG_X86) += x86/sha1-ssse3-and-avx.o \
|
|
|
|
|
x86/sha1-avx2-asm.o \
|
|
|
|
|
x86/sha1-ni-asm.o
|
2025-07-12 16:22:54 -07:00
|
|
|
endif # CONFIG_CRYPTO_LIB_SHA1_ARCH
|
2022-07-09 14:18:48 -07:00
|
|
|
|
2025-06-30 09:06:43 -07:00
|
|
|
################################################################################
|
2019-11-08 13:22:28 +01:00
|
|
|
|
2025-06-30 09:06:43 -07:00
|
|
|
obj-$(CONFIG_CRYPTO_LIB_SHA256) += libsha256.o
|
|
|
|
|
libsha256-y := sha256.o
|
|
|
|
|
ifeq ($(CONFIG_CRYPTO_LIB_SHA256_ARCH),y)
|
|
|
|
|
CFLAGS_sha256.o += -I$(src)/$(SRCARCH)
|
|
|
|
|
|
|
|
|
|
ifeq ($(CONFIG_ARM),y)
|
|
|
|
|
libsha256-y += arm/sha256-ce.o arm/sha256-core.o
|
|
|
|
|
$(obj)/arm/sha256-core.S: $(src)/arm/sha256-armv4.pl
|
|
|
|
|
$(call cmd,perlasm)
|
|
|
|
|
clean-files += arm/sha256-core.S
|
|
|
|
|
AFLAGS_arm/sha256-core.o += $(aflags-thumb2-y)
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
ifeq ($(CONFIG_ARM64),y)
|
|
|
|
|
libsha256-y += arm64/sha256-core.o
|
|
|
|
|
$(obj)/arm64/sha256-core.S: $(src)/arm64/sha2-armv8.pl
|
|
|
|
|
$(call cmd,perlasm_with_args)
|
|
|
|
|
clean-files += arm64/sha256-core.S
|
|
|
|
|
libsha256-$(CONFIG_KERNEL_MODE_NEON) += arm64/sha256-ce.o
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
libsha256-$(CONFIG_PPC) += powerpc/sha256-spe-asm.o
|
|
|
|
|
libsha256-$(CONFIG_RISCV) += riscv/sha256-riscv64-zvknha_or_zvknhb-zvkb.o
|
|
|
|
|
libsha256-$(CONFIG_SPARC) += sparc/sha256_asm.o
|
|
|
|
|
libsha256-$(CONFIG_X86) += x86/sha256-ssse3-asm.o \
|
|
|
|
|
x86/sha256-avx-asm.o \
|
|
|
|
|
x86/sha256-avx2-asm.o \
|
|
|
|
|
x86/sha256-ni-asm.o
|
|
|
|
|
endif # CONFIG_CRYPTO_LIB_SHA256_ARCH
|
|
|
|
|
|
|
|
|
|
################################################################################
|
2025-04-28 10:00:26 -07:00
|
|
|
|
2025-06-30 09:03:06 -07:00
|
|
|
obj-$(CONFIG_CRYPTO_LIB_SHA512) += libsha512.o
|
|
|
|
|
libsha512-y := sha512.o
|
|
|
|
|
ifeq ($(CONFIG_CRYPTO_LIB_SHA512_ARCH),y)
|
|
|
|
|
CFLAGS_sha512.o += -I$(src)/$(SRCARCH)
|
2025-06-30 09:03:11 -07:00
|
|
|
|
|
|
|
|
ifeq ($(CONFIG_ARM),y)
|
|
|
|
|
libsha512-y += arm/sha512-core.o
|
|
|
|
|
$(obj)/arm/sha512-core.S: $(src)/arm/sha512-armv4.pl
|
|
|
|
|
$(call cmd,perlasm)
|
|
|
|
|
clean-files += arm/sha512-core.S
|
|
|
|
|
AFLAGS_arm/sha512-core.o += $(aflags-thumb2-y)
|
|
|
|
|
endif
|
|
|
|
|
|
2025-06-30 09:03:12 -07:00
|
|
|
ifeq ($(CONFIG_ARM64),y)
|
|
|
|
|
libsha512-y += arm64/sha512-core.o
|
2025-06-19 12:19:01 -07:00
|
|
|
$(obj)/arm64/sha512-core.S: $(src)/arm64/sha2-armv8.pl
|
2025-06-30 09:03:12 -07:00
|
|
|
$(call cmd,perlasm_with_args)
|
|
|
|
|
clean-files += arm64/sha512-core.S
|
|
|
|
|
libsha512-$(CONFIG_KERNEL_MODE_NEON) += arm64/sha512-ce-core.o
|
|
|
|
|
endif
|
2025-06-30 09:03:15 -07:00
|
|
|
|
|
|
|
|
libsha512-$(CONFIG_RISCV) += riscv/sha512-riscv64-zvknhb-zvkb.o
|
2025-06-30 09:03:17 -07:00
|
|
|
libsha512-$(CONFIG_SPARC) += sparc/sha512_asm.o
|
2025-06-30 09:03:18 -07:00
|
|
|
libsha512-$(CONFIG_X86) += x86/sha512-ssse3-asm.o \
|
|
|
|
|
x86/sha512-avx-asm.o \
|
|
|
|
|
x86/sha512-avx2-asm.o
|
2025-06-30 09:03:06 -07:00
|
|
|
endif # CONFIG_CRYPTO_LIB_SHA512_ARCH
|
|
|
|
|
|
2025-06-30 09:06:43 -07:00
|
|
|
################################################################################
|
|
|
|
|
|
2023-08-04 17:24:34 +08:00
|
|
|
obj-$(CONFIG_MPILIB) += mpi/
|
2024-10-18 16:53:43 -07:00
|
|
|
|
crypto: testmgr - reinstate kconfig control over full self-tests
Commit 698de822780f ("crypto: testmgr - make it easier to enable the
full set of tests") removed support for building kernels that run only
the "fast" set of crypto self-tests by default. This assumed that
nearly everyone actually wanted the full set of tests, *if* they had
already chosen to enable the tests at all.
Unfortunately, it turns out that both Debian and Fedora intentionally
have the crypto self-tests enabled in their production kernels. And for
production kernels we do need to keep the testing time down, which
implies just running the "fast" tests, not the full set of tests.
For Fedora, a reason for enabling the tests in production is that they
are being (mis)used to meet the FIPS 140-3 pre-operational testing
requirement.
However, the other reason for enabling the tests in production, which
applies to both distros, is that they provide some value in protecting
users from buggy drivers. Unfortunately, the crypto/ subsystem has many
buggy and untested drivers for off-CPU hardware accelerators on rare
platforms. These broken drivers get shipped to users, and there have
been multiple examples of the tests preventing these buggy drivers from
being used. So effectively, the tests are being relied on in production
kernels. I think this is kind of crazy (untested drivers should just
not be enabled at all), but that seems to be how things work currently.
Thus, reintroduce a kconfig option that controls the level of testing.
Call it CRYPTO_SELFTESTS_FULL instead of the original name
CRYPTO_MANAGER_EXTRA_TESTS, which was slightly misleading.
Moreover, given the "production kernel" use case, make CRYPTO_SELFTESTS
depend on EXPERT instead of DEBUG_KERNEL.
I also haven't reinstated all the #ifdefs in crypto/testmgr.c. Instead,
just rely on the compiler to optimize out unused code.
Fixes: 40b9969796bf ("crypto: testmgr - replace CRYPTO_MANAGER_DISABLE_TESTS with CRYPTO_SELFTESTS")
Fixes: 698de822780f ("crypto: testmgr - make it easier to enable the full set of tests")
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-06-12 10:47:09 -07:00
|
|
|
obj-$(CONFIG_CRYPTO_SELFTESTS_FULL) += simd.o
|
2025-04-12 18:57:29 +08:00
|
|
|
|
|
|
|
|
obj-$(CONFIG_CRYPTO_LIB_SM3) += libsm3.o
|
|
|
|
|
libsm3-y := sm3.o
|
2025-06-19 12:19:00 -07:00
|
|
|
|
|
|
|
|
obj-$(CONFIG_ARM) += arm/
|
2025-06-19 12:19:01 -07:00
|
|
|
obj-$(CONFIG_ARM64) += arm64/
|
2025-06-19 12:19:02 -07:00
|
|
|
obj-$(CONFIG_MIPS) += mips/
|
2025-06-19 12:19:03 -07:00
|
|
|
obj-$(CONFIG_PPC) += powerpc/
|
2025-06-19 12:19:04 -07:00
|
|
|
obj-$(CONFIG_RISCV) += riscv/
|
2025-06-19 12:19:05 -07:00
|
|
|
obj-$(CONFIG_S390) += s390/
|
2025-06-19 12:19:07 -07:00
|
|
|
obj-$(CONFIG_X86) += x86/
|