linux-kernel - Re: [PATCH] crypto: lib/sha1 - use __DISABLE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <68ae14eb-1d09-4d09-b771-c3af9539d7df@oracle.com>
Date: Thu, 18 Dec 2025 10:58:42 -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/18/25 10:35 AM, Eric Biggers wrote:
> On Thu, Dec 18, 2025 at 10:25:50AM -0800, ross.philipson@...cle.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@...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.
> 
> 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