[PATCH] crypto: lib/sha1 - use __DISABLE_EXPORTS for SHA1 library

[Ross Philipson]

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://lore.kernel.org/r/20251216002150.GA11579@quark
Cc: Eric Biggers <ebig...@kernel.org>
Signed-off-by: Ross Philipson <ross.ph...@oracle.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
--
2.43.7

[Eric Biggers]

Shouldn't this be part of the patchset that needs this?

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.

The commit title is also misleading. How about:
"lib/crypto: sha1: Add support for pre-boot environments".

- Eric

[ross.ph...@oracle.com]

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 <ebig...@kernel.org>
>> Signed-off-by: Ross Philipson <ross.ph...@oracle.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

[Eric Biggers]

I can take it through libcrypto-next *if* the code that needs this is
coming soon, i.e. within the next cycle or two.

There have been many cases in the past where maintainers (including me)
have taken something planned to be used elsewhere in the kernel, but
then the code that used it never arrived. That's just wasted effort,
both in making the change and then reverting the unused change later.

The Secure Launch patches have been going on for over 6 years. Given
that, I think I'd prefer that you just add this to that series with my
ack, so they go in together.

- Eric

[ross.ph...@oracle.com]

I understand what you are saying. We will take it through our set. Thank
you for the clarification.

Ross

>
> - Eric