[8/8] crypto: Kconfig - sort the ciphers

Sort the entries in Ciphers by their displayed names.
In particular, keep the optimized CPU implementations next to the
generic implementations.

Signed-off-by: Robert Elliott <elliott@hpe.com>
---
 crypto/Kconfig | 118 ++++++++++++++++++++++++-------------------------
 1 file changed, 59 insertions(+), 59 deletions(-)

On Mon, Aug 15, 2022 at 02:06:08PM -0500, Robert Elliott wrote:
> Sort the entries in Ciphers by their displayed names.
> In particular, keep the optimized CPU implementations next to the
> generic implementations.
> 
> Signed-off-by: Robert Elliott <elliott@hpe.com>
> ---
>  crypto/Kconfig | 118 ++++++++++++++++++++++++-------------------------
>  1 file changed, 59 insertions(+), 59 deletions(-)
> 
> diff --git a/crypto/Kconfig b/crypto/Kconfig
> index f5cfb73e2423..03f4e2d97ef9 100644
> --- a/crypto/Kconfig
> +++ b/crypto/Kconfig
> @@ -1500,6 +1500,65 @@ menu "Ciphers"
>  
>  	  Processes eight blocks in parallel.
>  
> +config CRYPTO_CHACHA20
> +	tristate "ChaCha"
> +	select CRYPTO_LIB_CHACHA_GENERIC
> +	select CRYPTO_SKCIPHER
> +	help
> +	  The ChaCha20, XChaCha20, and XChaCha12 stream cipher algorithms
> +
> +	  ChaCha20 is a 256-bit high-speed stream cipher designed by Daniel J.
> +	  Bernstein and further specified in RFC7539 for use in IETF protocols.
> +	  This is the portable C implementation of ChaCha20.  See
> +	  https://cr.yp.to/chacha/chacha-20080128.pdf for further information.
> +
> +	  XChaCha20 is the application of the XSalsa20 construction to ChaCha20
> +	  rather than to Salsa20.  XChaCha20 extends ChaCha20's nonce length
> +	  from 64 bits (or 96 bits using the RFC7539 convention) to 192 bits,
> +	  while provably retaining ChaCha20's security.  See
> +	  https://cr.yp.to/snuffle/xsalsa-20081128.pdf for further information.
> +
> +	  XChaCha12 is XChaCha20 reduced to 12 rounds, with correspondingly
> +	  reduced security margin but increased performance.  It can be needed
> +	  in some performance-sensitive scenarios.
> +
> +config CRYPTO_CHACHA20_X86_64
> +	tristate "ChaCha (x86_64 with SSSE3/AVX2/AVX-512VL)"
> +	depends on X86 && 64BIT
> +	select CRYPTO_SKCIPHER
> +	select CRYPTO_LIB_CHACHA_GENERIC
> +	select CRYPTO_ARCH_HAVE_LIB_CHACHA
> +	help
> +	  ChaCha stream cipher algorithms
> +
> +	  Architecture: x86_64 using:
> +	  * SSSE3 (Supplemental SSE3)
> +	  * AVX2 (Advanced Vector Extensions 2)
> +	  * AVX-512VL (Advanced Vector Extensions-512VL)
> +
> +config CRYPTO_CHACHA_MIPS
> +	tristate "ChaCha (MIPS32r2)"
> +	depends on CPU_MIPS32_R2
> +	select CRYPTO_SKCIPHER
> +	select CRYPTO_ARCH_HAVE_LIB_CHACHA
> +	help
> +	  ChaCha stream cipher algorithms
> +
> +	  Architecture: MIPS32r2
> +
> +config CRYPTO_CHACHA_S390
> +	tristate "ChaCha20 (s390)"
> +	depends on S390
> +	select CRYPTO_SKCIPHER
> +	select CRYPTO_LIB_CHACHA_GENERIC
> +	select CRYPTO_ARCH_HAVE_LIB_CHACHA
> +	help
> +	  ChaCha20 stream cipher (RFC 7539)
> +
> +	  Architecture: s390
> +
> +	  It is available as of z13.

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

> -----Original Message-----
> From: Eric Biggers <ebiggers@kernel.org>
> Sent: Monday, August 15, 2022 4:36 PM
> To: Elliott, Robert (Servers) <elliott@hpe.com>
> Cc: herbert@gondor.apana.org.au; davem@davemloft.net; linux-
> crypto@vger.kernel.org; linux-kernel@vger.kernel.org; Kani, Toshi
> <toshi.kani@hpe.com>
> 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?