Hi,
On 30-07-19 22:07, Eric Biggers wrote:
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.?
I'm fine with that, I'm still waiting for feedback from the crypto maintainers
that they are open to doing that ...
Herbert? Dave?
Regards,
Hans
