From: Eric Biggers <ebiggers@google.com>
Continue disentangling the crypto library functions from the generic
crypto infrastructure by removing the unnecessary CRYPTO dependency of
CRYPTO_BLAKE2S_ARM, CRYPTO_CHACHA20_NEON, and CRYPTO_POLY1305_ARM. To
do this, make arch/arm/crypto/Kconfig be sourced regardless of CRYPTO,
and explicitly list the CRYPTO dependency in the symbols that do need
it.
Signed-off-by: Eric Biggers <ebiggers@google.com>
---
arch/arm/Kconfig | 2 ++
arch/arm/crypto/Kconfig | 24 +++++++++++++-----------
crypto/Kconfig | 3 ---
3 files changed, 15 insertions(+), 14 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 25ed6f1a7c7a..86fcce738887 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1753,5 +1753,7 @@ config ARCH_HIBERNATION_POSSIBLE
bool
depends on MMU
default y if ARCH_SUSPEND_POSSIBLE
endmenu
+
+source "arch/arm/crypto/Kconfig"
diff --git a/arch/arm/crypto/Kconfig b/arch/arm/crypto/Kconfig
index 3530e7c80793..a03017a6dbc4 100644
--- a/arch/arm/crypto/Kconfig
+++ b/arch/arm/crypto/Kconfig
@@ -2,11 +2,11 @@
menu "Accelerated Cryptographic Algorithms for CPU (arm)"
config CRYPTO_CURVE25519_NEON
tristate
- depends on KERNEL_MODE_NEON
+ depends on CRYPTO && KERNEL_MODE_NEON
select CRYPTO_KPP
select CRYPTO_LIB_CURVE25519_GENERIC
select CRYPTO_ARCH_HAVE_LIB_CURVE25519
default CRYPTO_LIB_CURVE25519_INTERNAL
help
@@ -15,11 +15,11 @@ config CRYPTO_CURVE25519_NEON
Architecture: arm with
- NEON (Advanced SIMD) extensions
config CRYPTO_GHASH_ARM_CE
tristate "Hash functions: GHASH (PMULL/NEON/ARMv8 Crypto Extensions)"
- depends on KERNEL_MODE_NEON
+ depends on CRYPTO && KERNEL_MODE_NEON
select CRYPTO_AEAD
select CRYPTO_HASH
select CRYPTO_CRYPTD
select CRYPTO_LIB_AES
select CRYPTO_LIB_GF128MUL
@@ -36,11 +36,11 @@ config CRYPTO_GHASH_ARM_CE
that is part of the ARMv8 Crypto Extensions, or a slower variant that
uses the vmull.p8 instruction that is part of the basic NEON ISA.
config CRYPTO_NHPOLY1305_NEON
tristate "Hash functions: NHPoly1305 (NEON)"
- depends on KERNEL_MODE_NEON
+ depends on CRYPTO && KERNEL_MODE_NEON
select CRYPTO_NHPOLY1305
help
NHPoly1305 hash function (Adiantum)
Architecture: arm using:
@@ -64,11 +64,11 @@ config CRYPTO_BLAKE2S_ARM
There is no NEON implementation of BLAKE2s, since NEON doesn't
really help with it.
config CRYPTO_BLAKE2B_NEON
tristate "Hash functions: BLAKE2b (NEON)"
- depends on KERNEL_MODE_NEON
+ depends on CRYPTO && KERNEL_MODE_NEON
select CRYPTO_BLAKE2B
help
BLAKE2b cryptographic hash function (RFC 7693)
Architecture: arm using
@@ -80,20 +80,21 @@ config CRYPTO_BLAKE2B_NEON
much faster than the SHA-2 family and slightly faster than
SHA-1.
config CRYPTO_SHA1_ARM
tristate "Hash functions: SHA-1"
+ depends on CRYPTO
select CRYPTO_SHA1
select CRYPTO_HASH
help
SHA-1 secure hash algorithm (FIPS 180)
Architecture: arm
config CRYPTO_SHA1_ARM_NEON
tristate "Hash functions: SHA-1 (NEON)"
- depends on KERNEL_MODE_NEON
+ depends on CRYPTO && KERNEL_MODE_NEON
select CRYPTO_SHA1_ARM
select CRYPTO_SHA1
select CRYPTO_HASH
help
SHA-1 secure hash algorithm (FIPS 180)
@@ -101,51 +102,52 @@ config CRYPTO_SHA1_ARM_NEON
Architecture: arm using
- NEON (Advanced SIMD) extensions
config CRYPTO_SHA1_ARM_CE
tristate "Hash functions: SHA-1 (ARMv8 Crypto Extensions)"
- depends on KERNEL_MODE_NEON
+ depends on CRYPTO && KERNEL_MODE_NEON
select CRYPTO_SHA1_ARM
select CRYPTO_HASH
help
SHA-1 secure hash algorithm (FIPS 180)
Architecture: arm using ARMv8 Crypto Extensions
config CRYPTO_SHA2_ARM_CE
tristate "Hash functions: SHA-224 and SHA-256 (ARMv8 Crypto Extensions)"
- depends on KERNEL_MODE_NEON
+ depends on CRYPTO && KERNEL_MODE_NEON
select CRYPTO_SHA256_ARM
select CRYPTO_HASH
help
SHA-224 and SHA-256 secure hash algorithms (FIPS 180)
Architecture: arm using
- ARMv8 Crypto Extensions
config CRYPTO_SHA256_ARM
tristate "Hash functions: SHA-224 and SHA-256 (NEON)"
+ depends on CRYPTO && !CPU_V7M
select CRYPTO_HASH
- depends on !CPU_V7M
help
SHA-224 and SHA-256 secure hash algorithms (FIPS 180)
Architecture: arm using
- NEON (Advanced SIMD) extensions
config CRYPTO_SHA512_ARM
tristate "Hash functions: SHA-384 and SHA-512 (NEON)"
+ depends on CRYPTO && !CPU_V7M
select CRYPTO_HASH
- depends on !CPU_V7M
help
SHA-384 and SHA-512 secure hash algorithms (FIPS 180)
Architecture: arm using
- NEON (Advanced SIMD) extensions
config CRYPTO_AES_ARM
tristate "Ciphers: AES"
+ depends on CRYPTO
select CRYPTO_ALGAPI
select CRYPTO_AES
help
Block ciphers: AES cipher algorithms (FIPS-197)
@@ -160,11 +162,11 @@ config CRYPTO_AES_ARM
disables IRQs and preloads the tables; it is hoped this makes
such attacks very difficult.
config CRYPTO_AES_ARM_BS
tristate "Ciphers: AES, modes: ECB/CBC/CTR/XTS (bit-sliced NEON)"
- depends on KERNEL_MODE_NEON
+ depends on CRYPTO && KERNEL_MODE_NEON
select CRYPTO_AES_ARM
select CRYPTO_SKCIPHER
select CRYPTO_LIB_AES
help
Length-preserving ciphers: AES cipher algorithms (FIPS-197)
@@ -188,11 +190,11 @@ config CRYPTO_AES_ARM_BS
ciphertext stealing when the message isn't a multiple of 16 bytes, and
CTR when invoked in a context in which NEON instructions are unusable.
config CRYPTO_AES_ARM_CE
tristate "Ciphers: AES, modes: ECB/CBC/CTS/CTR/XTS (ARMv8 Crypto Extensions)"
- depends on KERNEL_MODE_NEON
+ depends on CRYPTO && KERNEL_MODE_NEON
select CRYPTO_SKCIPHER
select CRYPTO_LIB_AES
help
Length-preserving ciphers: AES cipher algorithms (FIPS-197)
with block cipher modes:
diff --git a/crypto/Kconfig b/crypto/Kconfig
index 9322e42e562d..cad71f32e1e3 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -1424,13 +1424,10 @@ endmenu
config CRYPTO_HASH_INFO
bool
if !KMSAN # avoid false positives from assembly
-if ARM
-source "arch/arm/crypto/Kconfig"
-endif
if ARM64
source "arch/arm64/crypto/Kconfig"
endif
if LOONGARCH
source "arch/loongarch/crypto/Kconfig"
--
2.49.0Eric Biggers <ebiggers@kernel.org> wrote: > > config CRYPTO_CURVE25519_NEON > tristate > - depends on KERNEL_MODE_NEON > + depends on CRYPTO && KERNEL_MODE_NEON Rather than adding CRYPTO to each symbol, how about grouping all the CRYPTO symbols together under one if statement? Cheers, -- Email: Herbert Xu <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Fri, Apr 18, 2025 at 11:12:33AM +0800, Herbert Xu wrote: > Eric Biggers <ebiggers@kernel.org> wrote: > > > > config CRYPTO_CURVE25519_NEON > > tristate > > - depends on KERNEL_MODE_NEON > > + depends on CRYPTO && KERNEL_MODE_NEON > > Rather than adding CRYPTO to each symbol, how about grouping all > the CRYPTO symbols together under one if statement? I don't think that would be better. The 'if' would be up to 400 lines long, and it would be easy for people to miss the context when editing the file. - Eric
On Thu, Apr 17, 2025 at 08:32:36PM -0700, Eric Biggers wrote: > > I don't think that would be better. The 'if' would be up to 400 lines long, and > it would be easy for people to miss the context when editing the file. We should separate the symbols for Crypto API options and the library options. If you're worried about people missing the if statement, how about splitting the file into two? One for Crypto API symbols and one for the library symbols. In fact we could move the library files into a different directory, e.g., arch/x86/crypto/lib or arch/x86/lib/crypto. Cheers, -- Email: Herbert Xu <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Fri, Apr 18, 2025 at 11:38:46AM +0800, Herbert Xu wrote: > On Thu, Apr 17, 2025 at 08:32:36PM -0700, Eric Biggers wrote: > > > > I don't think that would be better. The 'if' would be up to 400 lines long, and > > it would be easy for people to miss the context when editing the file. > > We should separate the symbols for Crypto API options and the library > options. If you're worried about people missing the if statement, > how about splitting the file into two? One for Crypto API symbols > and one for the library symbols. > > In fact we could move the library files into a different directory, > e.g., arch/x86/crypto/lib or arch/x86/lib/crypto. arch/$ARCH/lib/crypto/ is the "right" way to do it, mirroring lib/crypto/. I was just hoping to avoid a 4-deep directory. But we can do it. - Eric
On Thu, Apr 17, 2025 at 09:09:31PM -0700, Eric Biggers wrote: > > arch/$ARCH/lib/crypto/ is the "right" way to do it, mirroring lib/crypto/. I > was just hoping to avoid a 4-deep directory. But we can do it. You can do that in a follow-up, assuming nothing else pops for this series. Cheers, -- Email: Herbert Xu <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Fri, Apr 18, 2025 at 04:25:40PM +0800, Herbert Xu wrote: > On Thu, Apr 17, 2025 at 09:09:31PM -0700, Eric Biggers wrote: > > > > arch/$ARCH/lib/crypto/ is the "right" way to do it, mirroring lib/crypto/. I > > was just hoping to avoid a 4-deep directory. But we can do it. > > You can do that in a follow-up, assuming nothing else pops for this > series. Doing it as a follow-up when this series hasn't been merged yet would be kind of silly, since it would undo a lot of this series. I'll just send out a v2 of this series. - Eric
On Fri, Apr 18, 2025 at 08:01:49AM -0700, Eric Biggers wrote: > > Doing it as a follow-up when this series hasn't been merged yet would be kind of > silly, since it would undo a lot of this series. I'll just send out a v2 of > this series. OK that's fine too of course. -- Email: Herbert Xu <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Eric Biggers <ebiggers@kernel.org> wrote: > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 25ed6f1a7c7a..86fcce738887 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -1753,5 +1753,7 @@ config ARCH_HIBERNATION_POSSIBLE > bool > depends on MMU > default y if ARCH_SUSPEND_POSSIBLE > > endmenu > + > +source "arch/arm/crypto/Kconfig" ... > diff --git a/crypto/Kconfig b/crypto/Kconfig > index 9322e42e562d..cad71f32e1e3 100644 > --- a/crypto/Kconfig > +++ b/crypto/Kconfig > @@ -1424,13 +1424,10 @@ endmenu > > config CRYPTO_HASH_INFO > bool > > if !KMSAN # avoid false positives from assembly > -if ARM > -source "arch/arm/crypto/Kconfig" > -endif So this removes the KMSAN check. Is it still needed or not? Cheers, -- Email: Herbert Xu <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Fri, Apr 18, 2025 at 11:08:16AM +0800, Herbert Xu wrote: > Eric Biggers <ebiggers@kernel.org> wrote: > > > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > > index 25ed6f1a7c7a..86fcce738887 100644 > > --- a/arch/arm/Kconfig > > +++ b/arch/arm/Kconfig > > @@ -1753,5 +1753,7 @@ config ARCH_HIBERNATION_POSSIBLE > > bool > > depends on MMU > > default y if ARCH_SUSPEND_POSSIBLE > > > > endmenu > > + > > +source "arch/arm/crypto/Kconfig" > > ... > > > diff --git a/crypto/Kconfig b/crypto/Kconfig > > index 9322e42e562d..cad71f32e1e3 100644 > > --- a/crypto/Kconfig > > +++ b/crypto/Kconfig > > @@ -1424,13 +1424,10 @@ endmenu > > > > config CRYPTO_HASH_INFO > > bool > > > > if !KMSAN # avoid false positives from assembly > > -if ARM > > -source "arch/arm/crypto/Kconfig" > > -endif > > So this removes the KMSAN check. Is it still needed or not? > Only x86 and s390 support KMSAN. - Eric
On Thu, Apr 17, 2025 at 08:28:45PM -0700, Eric Biggers wrote: > > Only x86 and s390 support KMSAN. OK that's subtle but I'm glad it's not an issue. Thanks, -- Email: Herbert Xu <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
© 2016 - 2026 Red Hat, Inc.