Re: [PATCH v3 6/8] crypto/sha3: Use lib/crypto/sha3

[Eric Biggers <ebiggers@kernel.org>]

On Fri, Sep 26, 2025 at 03:19:49PM +0100, David Howells wrote:
> Switch crypto/sha3_generic.c to use lib/crypto/sha3.  Note that this makes
> use of the internal general API rather implementing a separate set of
> init/update/finup handlers for each algorithm.
> 
> Signed-off-by: David Howells <dhowells@redhat.com>
> cc: Eric Biggers <ebiggers@kernel.org>
> cc: Jason A. Donenfeld <Jason@zx2c4.com>
> cc: Ard Biesheuvel <ardb@kernel.org>
> cc: Herbert Xu <herbert@gondor.apana.org.au>
> cc: Stephan Mueller <smueller@chronox.de>
> cc: linux-crypto@vger.kernel.org
> ---
>  Documentation/crypto/sha3.rst    |   8 +-
>  arch/arm64/crypto/sha3-ce-glue.c |  25 ++--
>  crypto/sha3_generic.c            | 201 +++----------------------------
>  include/crypto/sha3.h            |   6 +-
>  lib/crypto/sha3.c                |  35 +++---
>  5 files changed, 52 insertions(+), 223 deletions(-)

What's worked well for the other algorithms is to do things in this
order:

    1. Move the arch-specific implementations into lib/crypto/,
       making them available via the library API and temporarily
       removing them from the crypto_shash API.  One patch per arch.

    2. Replace crypto/${alg}_generic.c with crypto/${alg}.c that is
       built directly on the library API.  The algorithms are called
       "*-lib" instead of "*-generic", and they don't use the
       crypto_shash generic partial block handling.

Again, if you don't want to do all that, I'd be glad to do it.  I'd be a
bit hesitant to take this patch instead, as it sort of starts out going
in a different direction.  So it would create a temporary situation, and
we'd need to make sure that temporary situation works.  (FWIW, this
patch breaks the build of sha3-ce-glue.c, so that's not a great start.)

- Eric