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@xxxxxxxxxx>
> > > >
> > > > 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@xxxxxxxxxx>
> > > > Cc: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
> > > > Signed-off-by: Andy Lutomirski <luto@xxxxxxxxxx>
> > > > ---
> > > > 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
