lib/crypto/sha1.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
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 <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
--
2.43.7
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://lore.kernel.org/r/20251216002150.GA11579@quark > 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? 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
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. > > 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
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
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
© 2016 - 2026 Red Hat, Inc.