[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aBGObifCORhrBXz1@gondor.apana.org.au>
Date: Wed, 30 Apr 2025 10:43:58 +0800
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Eric Biggers <ebiggers@...nel.org>
Cc: Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-mips@...r.kernel.org,
linuxppc-dev@...ts.ozlabs.org, linux-riscv@...ts.infradead.org,
sparclinux@...r.kernel.org, linux-s390@...r.kernel.org,
x86@...nel.org, Ard Biesheuvel <ardb@...nel.org>,
"Jason A . Donenfeld " <Jason@...c4.com>,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [v3 PATCH 00/13] Architecture-optimized SHA-256 library API
On Tue, Apr 29, 2025 at 07:38:49PM -0700, Eric Biggers wrote:
>
> Nothing requires that the export formats be consistent, but also the fact that
> padlock-sha uses a weird format in the first place is an artificial problem that
> you introduced just a couple weeks ago. And even if we *must* use the same
> format as padlock-sha, that can be done by using your crypto_sha256_export_lib
> and crypto_sha256_import_lib, without all your other changes.
That was just the reason of why I can't take your first patch as
is and then add my changes as incremental patches.
I do still want to bypass the partial block handling in lib/crypto.
But alright I will do it like this:
Patch 1 is just your existing patch + my export/import functions.
Then I will add the rest of my changes as incremental patches.
Cheers,
--
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Powered by blists - more mailing lists