From: Hans de Goede <hdegoede@redhat.com>
To: Stephan Mueller <smueller@chronox.de>,
Herbert Xu <herbert@gondor.apana.org.au>,
"David S . Miller" <davem@davemloft.net>,
Andy Lutomirski <luto@kernel.org>,
linux-crypto@vger.kernel.org,
Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: Re: [RFC 3/3] crypto/sha256: Build the SHA256 core separately from the crypto module
Date: Tue, 30 Jul 2019 18:07:54 +0200 [thread overview]
Message-ID: <cb888bfa-dd46-de7a-3b90-b54fa79fa3d4@redhat.com> (raw)
In-Reply-To: <20190730160335.GA27287@gmail.com>
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.
Regards,
Hans
next prev parent reply other threads:[~2019-07-30 16:07 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-30 12:38 [RFC 0/3] Making a secure hash function avaiable during early boot? Hans de Goede
2019-07-30 12:38 ` [RFC 1/3] crypto/sha256: Factor out the parts of base API that don't use shash_desc Hans de Goede
2019-07-30 12:38 ` [RFC 2/3] crypto/sha256: Export a sha256_{init,update,final}_direct() API Hans de Goede
2019-07-30 12:38 ` [RFC 3/3] crypto/sha256: Build the SHA256 core separately from the crypto module Hans de Goede
2019-07-30 13:15 ` Stephan Mueller
2019-07-30 13:20 ` Hans de Goede
2019-07-30 16:03 ` Eric Biggers
2019-07-30 16:07 ` Hans de Goede [this message]
2019-07-30 20:07 ` Eric Biggers
2019-07-31 8:19 ` Hans de Goede
2019-07-31 10:57 ` Herbert Xu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cb888bfa-dd46-de7a-3b90-b54fa79fa3d4@redhat.com \
--to=hdegoede@redhat.com \
--cc=ard.biesheuvel@linaro.org \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=linux-crypto@vger.kernel.org \
--cc=luto@kernel.org \
--cc=smueller@chronox.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).