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

[ross.philipson@oracle.com]

On 12/18/25 10:35 AM, Eric Biggers wrote:
> On Thu, Dec 18, 2025 at 10:25:50AM -0800, ross.philipson@oracle.com wrote:
>> 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@kernel.org>
>>>> Signed-off-by: Ross Philipson <ross.philipson@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.
> 
> 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.

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

Ross

> 
> - Eric