All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: Hans de Goede <hdegoede@redhat.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	"H . Peter Anvin" <hpa@zytor.com>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	Vasily Gorbik <gor@linux.ibm.com>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	Eric Biggers <ebiggers@kernel.org>,
	Andy Lutomirski <luto@kernel.org>,
	"open list:HARDWARE RANDOM NUMBER GENERATOR CORE" 
	<linux-crypto@vger.kernel.org>,
	"the arch/x86 maintainers" <x86@kernel.org>,
	linux-s390 <linux-s390@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 0/7] crypto: sha256 - Merge 2 separate C implementations into 1, put into separate library
Date: Mon, 19 Aug 2019 18:08:34 +0300	[thread overview]
Message-ID: <CAKv+Gu_bdcEQVnUcBpucgxk8zJ3EgsS=mBUpqfECOq_k1YYN9w@mail.gmail.com> (raw)
In-Reply-To: <20190817142435.8532-1-hdegoede@redhat.com>

On Sat, 17 Aug 2019 at 17:24, Hans de Goede <hdegoede@redhat.com> wrote:
>
> Hi All,
>
> Here is v2 of my patch series refactoring the current 2 separate SHA256
> C implementations into 1 and put it into a separate library.
>
> There are 3 reasons for this:
>
> 1) Remove the code duplication of having 2 separate implementations
>
> 2) Offer a separate library SHA256 implementation which can be used
> without having to call crypto_alloc_shash first. This is especially
> useful for use during early boot when crypto_alloc_shash does not
> work yet.
>
> 3) Having the purgatory code using the same code as the crypto subsys means
> that the purgratory code will be tested by the crypto subsys selftests.
>
> This has been tested on x86, including checking that kecec still works.
>
> This has NOT been tested on s390, if someone with access to s390 can
> test that things still build with this series applied and that
> kexec still works, that would be great.
>
> Changes in v2:
> - Use put_unaligned_be32 to store the hash to allow callers to use an
>   unaligned buffer for storing the hash
> - Add a comment to include/crypto/sha256.h explaining that these functions
>   now may be used outside of the purgatory too (and that using the crypto
>   API instead is preferred)
> - Add sha224 support to the lib/crypto/sha256 library code
> - Make crypto/sha256_generic.c not only use sha256_transform from
>   lib/crypto/sha256.c but also switch it to using sha256_init, sha256_update
>   and sha256_final from there so that the crypto subsys selftests fully test
>   the lib/crypto/sha256.c implementation
>

This looks fine to me, although I agree with Eric's feedback regarding
further cleanups. Also, now that we have a C library, I'd like to drop
the dependency of the mips and x86 sha256 algo implementations up
sha256_generic.c, and use the library directly instead (so that
sha256-generic is no longer needed on x86 or mips)

  parent reply	other threads:[~2019-08-19 15:08 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-17 14:24 [PATCH v2 0/7] crypto: sha256 - Merge 2 separate C implementations into 1, put into separate library Hans de Goede
2019-08-17 14:24 ` [PATCH v2 1/7] crypto: sha256 - Fix some coding style issues Hans de Goede
2019-08-17 14:24 ` [PATCH v2 2/7] crypto: sha256_generic " Hans de Goede
2019-08-17 14:24 ` [PATCH v2 3/7] crypto: sha256 - Move lib/sha256.c to lib/crypto Hans de Goede
2019-08-17 14:24 ` [PATCH v2 4/7] crypto: sha256 - Use get/put_unaligned_be32 to get input, memzero_explicit Hans de Goede
2019-08-17 14:24 ` [PATCH v2 5/7] crypto: sha256 - Make lib/crypto/sha256.c suitable for generic use Hans de Goede
2019-08-17 14:24 ` [PATCH v2 6/7] crypto: sha256 - Add sha224 support to sha256 library code Hans de Goede
2019-08-17 14:24 ` [PATCH v2 7/7] crypto: sha256_generic - Switch to the generic lib/crypto/sha256.c lib code Hans de Goede
2019-08-19 15:08 ` Ard Biesheuvel [this message]
2019-08-19 15:08   ` [PATCH v2 0/7] crypto: sha256 - Merge 2 separate C implementations into 1, put into separate library Ard Biesheuvel
2019-08-19 19:38   ` Hans de Goede
2019-08-19 19:38     ` Hans de Goede
2019-08-19 20:30     ` Ard Biesheuvel
2019-08-19 20:30       ` Ard Biesheuvel
2019-08-22  5: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='CAKv+Gu_bdcEQVnUcBpucgxk8zJ3EgsS=mBUpqfECOq_k1YYN9w@mail.gmail.com' \
    --to=ard.biesheuvel@linaro.org \
    --cc=borntraeger@de.ibm.com \
    --cc=bp@alien8.de \
    --cc=ebiggers@kernel.org \
    --cc=gor@linux.ibm.com \
    --cc=hdegoede@redhat.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=hpa@zytor.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.