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

[Eric Biggers <ebiggers@kernel.org>]

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.

- Eric