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

On Tue, Jul 30, 2019 at 06:07:54PM +0200, Hans de Goede wrote:

Hi,

On 30-07-19 18:03, Eric Biggers wrote:

quoted

On Tue, Jul 30, 2019 at 03:15:35PM +0200, Stephan Mueller wrote:

quoted

Am Dienstag, 30. Juli 2019, 14:38:35 CEST schrieb Hans de Goede:

Hi Hans,

quoted

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 <redacted>
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