> -----Original Message-----
> From: Eric Biggers <ebiggers@xxxxxxxxxx>
> Sent: Monday, August 15, 2022 4:36 PM
> To: Elliott, Robert (Servers) <elliott@xxxxxxx>
> Cc: herbert@xxxxxxxxxxxxxxxxxxx; davem@xxxxxxxxxxxxx; linux-
> crypto@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; Kani, Toshi
> <toshi.kani@xxxxxxx>
> Subject: Re: [PATCH 8/8] crypto: Kconfig - sort the ciphers
>
> Do we want to keep the architecture-specific options in crypto/Kconfig?
> arm and arm64 split them out into a separate file arch/$arch/crypto/Kconfig.
> Perhaps the other architectures should adopt that?
>
> - Eric
Pulling the ARM entries back into the main Kconfig file might help
preserve similar patterns across the architectures.
On the other hand, it'd be nice if the symbols for other architectures
disappeared entirely. Right now, searching with "/" in
make ARCH=arm64 menuconfig
finds all the x86, s390, mips, sparc, and powerpc crypto entries,
even though they're clearly not applicable. Meanwhile,
make ARCH=x86 menuconfig
is not cluttered by any of the arch/arm64/crypto Kconfig entries.
For arm64, the top-level menu entry for them is quite prominent,
appearing before the Crypto API entry:
General setup --->
Platform selection --->
Kernel Features --->
Boot options --->
Power management options --->
CPU Power Management --->
[*] ACPI (Advanced Configuration and Power Interface) Support --->
[*] Virtualization --->
[*] ARM64 Accelerated Cryptographic Algorithms --->
General architecture-dependent options --->
[*] Enable loadable module support --->
-*- Enable the block layer --->
Executable file formats --->
Memory Management options --->
[*] Networking support --->
Device Drivers --->
File systems --->
Security options --->
-*- Cryptographic API --->
Library routines --->
Kernel hacking --->
With the "source" command, the CPU-optimized driver menu could
be placed into the Cryptographic API menu, similar to "Hardware
crypto devices."
There are currently 21 arm64 entries and 33 x86 entries, so
they will tend to wrap onto multiple screens. It's not as bad
if they're sorted. The x86 entries would be:
AEGIS-128 (x86_64 with AES-NI/SSE2)
AES (Advanced Encryption Standard) (x86 with AES-NI)
BLAKE2s (x86_64 with SSSE3/AVX-512)
Blowfish (x86_64)
Camellia (x86_64)
Camellia (x86_64 with AES-NI/AVX)
Camellia (x86_64 with AES-NI/AVX2)
CAST5 (CAST-128) (x86_64 with AVX)
CAST6 (CAST-256) (x86_64 with AVX)
ChaCha (x86_64 with SSSE3/AVX2/AVX-512VL)
CRC32c (x86 with SSE4.2/PCLMULQDQ)
CRC32 (x86 with PCLMULQDQ)
CRCT10DIF (x86_64 with PCLMULQDQ)
Curve25519 (x86_64 with ADX)
GHASH (x86_64 with CLMUL-NI)
NHPoly1305 (x86_64 with AVX2)
NHPoly1305 (x86_64 with SSE2)
Poly1305 (x86_64 with SSE2/AVX2)
Serpent (x86 with SSE2)
Serpent (x86_64 with SSE2)
Serpent (x86_64 with AVX)
Serpent (x86_64 with AVX2)
SHA1 (x86_64 with SSSE3/AVX/AVX2/SHA-NI)
SHA224 and SHA256 (x86_64 with SSSE3/AVX/AVX2/SHA-NI)
SHA384 and SHA512 (x86_64 with SSSE3/AVX/AVX2)
SM3 (ShangMi 3) (x86_64 with AVX)
SM4 (ShangMi 4) (x86_64 with AES-NI/AVX)
SM4 (ShangMi 4) (x86_64 with AES-NI/AVX2)
Triple DES EDE (x86_64)
Twofish (x86)
Twofish (x86_64)
Twofish (x86_64, 3-way parallel)
Twofish (x86_64 with AVX)
I can add some patches at the end of the series to move all
the x86, s390, mips, sparc, and powerpc crypto entries
to new Kconfig files (or would that be better at the beginning
of the series?).
Note that one ARM/ARM64 module is described in crypto/Kconfig
and has its source files in crypto/:
config CRYPTO_AEGIS128_SIMD
bool "AEGIS-128 (arm SIMD acceleration)"
depends on CRYPTO_AEGIS128 && ((ARM || ARM64) && KERNEL_MODE_NEON)
default y
help
AEGIS-128 AEAD algorithm
Architecture: arm using the Neon SIMD architecture extension
Perhaps that is because it supports both ARM and ARM64, which
the others don't seem to do. Should we leave the source files
in place but duplicate the entry in both arch/arm/crypto/Kconfig
and arch/arm64/crypto/Kconfig?
