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

[ross . philipson]

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