Re: [RFC 3/3] crypto/sha256: Build the SHA256 core separately from the crypto module

[Eric Biggers <ebiggers@kernel.org>]

On Tue, Jul 30, 2019 at 06:07:54PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 30-07-19 18:03, Eric Biggers wrote:
> > On Tue, Jul 30, 2019 at 03:15:35PM +0200, Stephan Mueller wrote:
> > > Am Dienstag, 30. Juli 2019, 14:38:35 CEST schrieb Hans de Goede:
> > > 
> > > Hi Hans,
> > > 
> > > > From: Andy Lutomirski <luto@kernel.org>
> > > > 
> > > > This just moves code around -- no code changes in this patch.  This
> > > > wil let BPF-based tracing link against the SHA256 core code without
> > > > depending on the crypto core.
> > > > 
> > > > Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> > > > Cc: Herbert Xu <herbert@gondor.apana.org.au>
> > > > Signed-off-by: Andy Lutomirski <luto@kernel.org>
> > > > ---
> > > >   crypto/Kconfig                               |   8 +
> > > >   crypto/Makefile                              |   1 +
> > > >   crypto/{sha256_generic.c => sha256_direct.c} | 103 +--------
> > > 
> > > There is a similar standalone code present for SHA-1 or ChaCha20. However,
> > > this code lives in lib/.
> > > 
> > > Thus, shouldn't the SHA-256 core code be moved to lib/ as well?
> > > 
> > > Ciao
> > > Stephan
> > > 
> > > 
> > 
> > What's wrong with lib/sha256.c?  It's already there.
> 
> That is currently not build under lib/ it is only build as part of
> the helper executable which deals with transitioning from one kernel to
> the next on kexec, specifically it is used by arch/x86/purgatory/purgatory.c
> and also be the s390 purgatory code.
> 
> Since the purgatory use is in a separate binary / name space AFAICT, we
> could add sha256.o to lib/Makefile and then I could use that, but then the
> normal kernel image would have 2 SHA256 implementations.
> 

Well, seems like the solution needs to involve unifying the implementations.

Note that Ard Biesheuvel recently added the arc4 and aes algorithms to
lib/crypto/, with options CONFIG_CRYPTO_LIB_ARC4 and CONFIG_CRYPTO_LIB_AES.  How
about following the same convention, rather than doing everything slightly
differently w.r.t. code organization, function naming, Kconfig option, etc.?

- Eric