[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e69b2b27-af03-41aa-a7ae-c4e9c6fe5e02@oracle.com>
Date: Thu, 18 Dec 2025 10:25:50 -0800
From: ross.philipson@...cle.com
To: Eric Biggers <ebiggers@...nel.org>
Cc: linux-kernel@...r.kernel.org, linux-crypto@...r.kernel.org,
Jason@...c4.com, ardb@...nel.org, dpsmith@...rtussolutions.com,
kanth.ghatraju@...cle.com, andrew.cooper3@...rix.com,
trenchboot-devel@...glegroups.com
Subject: Re: [PATCH] crypto: lib/sha1 - use __DISABLE_EXPORTS for SHA1 library
On 12/17/25 3:57 PM, 'Eric Biggers' via trenchboot-devel wrote:
> On Wed, Dec 17, 2025 at 03:38:26PM -0800, Ross Philipson wrote:
>> Allow the SHA1 library code in lib/crypto/sha1.c to be used in a pre-boot
>> environments. Use the __DISABLE_EXPORTS macro to disable function exports and
>> define the proper values for that environment as was done earlier for SHA256.
>>
>> This issue was brought up during the review of the Secure Launch v15 patches
>> that use SHA1 in a pre-boot environment (link in tags below). This is being
>> sent as a standalone patch to address this.
>>
>> Link: https://urldefense.com/v3/__https://lore.kernel.org/r/20251216002150.GA11579@quark__;!!ACWV5N9M2RV99hQ!NYVuWrBT2adow7b4eijfE5vI_FKAu7wblBsmNDxouC58woEhQhR4m9sOXOpa9xBoUtLLinpXb3T_AUGlTF-nUG5IjA9SszJw7g8$
>> Cc: Eric Biggers <ebiggers@...nel.org>
>> Signed-off-by: Ross Philipson <ross.philipson@...cle.com>
>> ---
>> lib/crypto/sha1.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/lib/crypto/sha1.c b/lib/crypto/sha1.c
>> index 52788278cd17..e5a9e1361058 100644
>> --- a/lib/crypto/sha1.c
>> +++ b/lib/crypto/sha1.c
>> @@ -154,7 +154,7 @@ static void __maybe_unused sha1_blocks_generic(struct sha1_block_state *state,
>> memzero_explicit(workspace, sizeof(workspace));
>> }
>>
>> -#ifdef CONFIG_CRYPTO_LIB_SHA1_ARCH
>> +#if defined(CONFIG_CRYPTO_LIB_SHA1_ARCH) && !defined(__DISABLE_EXPORTS)
>> #include "sha1.h" /* $(SRCARCH)/sha1.h */
>> #else
>> #define sha1_blocks sha1_blocks_generic
>
> Shouldn't this be part of the patchset that needs this?
The way we read your comments on the TrenchBoot SHA1 patch, it sounded
like you were saying to fix the issue directly in the crypto lib first.
We assumed this meant a standalone patch but if we misunderstood, we can
certainly pull this in our patch set.
>
> Also, when __DISABLE_EXPORTS is defined, only the functionality actually
> used by pre-boot environments should be included. HMAC support for
> example probably isn't needed.
Yes we need the first use of the macro to correctly not include the sha1
header. Agreed on not needing the HMAC bits. I can drop them out too as
was also done in sha256.c.
>
> The commit title is also misleading. How about:
> "lib/crypto: sha1: Add support for pre-boot environments".
Ack
>
> - Eric
>
Thanks
Ross
Powered by blists - more mailing lists