| Message ID | 20240214221847.2066632-7-ross.philipson@oracle.com (mailing list archive) |
|---|---|
| State | Not Applicable |
| Delegated to: | Herbert Xu |
| Headers | show |
| Series | x86: Trenchboot secure dynamic launch Linux kernel support | expand |
On Wed, 14 Feb 2024 at 23:31, Ross Philipson <ross.philipson@oracle.com> wrote: > > From: "Daniel P. Smith" <dpsmith@apertussolutions.com> > > The SHA algorithms are necessary to measure configuration information into > the TPM as early as possible before using the values. This implementation > uses the established approach of #including the SHA libraries directly in > the code since the compressed kernel is not uncompressed at this point. > > The SHA code here has its origins in the code from the main kernel: > > commit c4d5b9ffa31f ("crypto: sha1 - implement base layer for SHA-1") > > A modified version of this code was introduced to the lib/crypto/sha1.c > to bring it in line with the sha256 code and allow it to be pulled into the > setup kernel in the same manner as sha256 is. > > Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com> > Signed-off-by: Ross Philipson <ross.philipson@oracle.com> We have had some discussions about this, and you really need to capture the justification in the commit log for introducing new code that implements an obsolete and broken hashing algorithm. SHA-1 is broken and should no longer be used for anything. Introducing new support for a highly complex boot security feature, and then relying on SHA-1 in the implementation makes this whole effort seem almost futile, *unless* you provide some rock solid reasons here why this is still safe. If the upshot would be that some people are stuck with SHA-1 so they won't be able to use this feature, then I'm not convinced we should obsess over that. > --- > arch/x86/boot/compressed/Makefile | 2 + > arch/x86/boot/compressed/early_sha1.c | 12 ++++ > arch/x86/boot/compressed/early_sha256.c | 6 ++ > include/crypto/sha1.h | 1 + > lib/crypto/sha1.c | 81 +++++++++++++++++++++++++ This needs to be a separate patch in any case. > 5 files changed, 102 insertions(+) > create mode 100644 arch/x86/boot/compressed/early_sha1.c > create mode 100644 arch/x86/boot/compressed/early_sha256.c > > diff --git a/arch/x86/boot/compressed/Makefile b/arch/x86/boot/compressed/Makefile > index f19c038409aa..a1b018eb9801 100644 > --- a/arch/x86/boot/compressed/Makefile > +++ b/arch/x86/boot/compressed/Makefile > @@ -118,6 +118,8 @@ vmlinux-objs-$(CONFIG_EFI) += $(obj)/efi.o > vmlinux-objs-$(CONFIG_EFI_MIXED) += $(obj)/efi_mixed.o > vmlinux-objs-$(CONFIG_EFI_STUB) += $(objtree)/drivers/firmware/efi/libstub/lib.a > > +vmlinux-objs-$(CONFIG_SECURE_LAUNCH) += $(obj)/early_sha1.o $(obj)/early_sha256.o > + > $(obj)/vmlinux: $(vmlinux-objs-y) FORCE > $(call if_changed,ld) > > diff --git a/arch/x86/boot/compressed/early_sha1.c b/arch/x86/boot/compressed/early_sha1.c > new file mode 100644 > index 000000000000..0c7cf6f8157a > --- /dev/null > +++ b/arch/x86/boot/compressed/early_sha1.c > @@ -0,0 +1,12 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright (c) 2022 Apertus Solutions, LLC. > + */ > + > +#include <linux/init.h> > +#include <linux/linkage.h> > +#include <linux/string.h> > +#include <asm/boot.h> > +#include <asm/unaligned.h> > + > +#include "../../../../lib/crypto/sha1.c" > diff --git a/arch/x86/boot/compressed/early_sha256.c b/arch/x86/boot/compressed/early_sha256.c > new file mode 100644 > index 000000000000..54930166ffee > --- /dev/null > +++ b/arch/x86/boot/compressed/early_sha256.c > @@ -0,0 +1,6 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright (c) 2022 Apertus Solutions, LLC > + */ > + > +#include "../../../../lib/crypto/sha256.c" > diff --git a/include/crypto/sha1.h b/include/crypto/sha1.h > index 044ecea60ac8..d715dd5332e1 100644 > --- a/include/crypto/sha1.h > +++ b/include/crypto/sha1.h > @@ -42,5 +42,6 @@ extern int crypto_sha1_finup(struct shash_desc *desc, const u8 *data, > #define SHA1_WORKSPACE_WORDS 16 > void sha1_init(__u32 *buf); > void sha1_transform(__u32 *digest, const char *data, __u32 *W); > +void sha1(const u8 *data, unsigned int len, u8 *out); > > #endif /* _CRYPTO_SHA1_H */ > diff --git a/lib/crypto/sha1.c b/lib/crypto/sha1.c > index 1aebe7be9401..10152125b338 100644 > --- a/lib/crypto/sha1.c > +++ b/lib/crypto/sha1.c > @@ -137,4 +137,85 @@ void sha1_init(__u32 *buf) > } > EXPORT_SYMBOL(sha1_init); > > +static void __sha1_transform(u32 *digest, const char *data) > +{ > + u32 ws[SHA1_WORKSPACE_WORDS]; > + > + sha1_transform(digest, data, ws); > + > + memzero_explicit(ws, sizeof(ws)); > +} > + > +static void sha1_update(struct sha1_state *sctx, const u8 *data, unsigned int len) > +{ > + unsigned int partial = sctx->count % SHA1_BLOCK_SIZE; > + > + sctx->count += len; > + > + if (likely((partial + len) >= SHA1_BLOCK_SIZE)) { > + int blocks; > + > + if (partial) { > + int p = SHA1_BLOCK_SIZE - partial; > + > + memcpy(sctx->buffer + partial, data, p); > + data += p; > + len -= p; > + > + __sha1_transform(sctx->state, sctx->buffer); > + } > + > + blocks = len / SHA1_BLOCK_SIZE; > + len %= SHA1_BLOCK_SIZE; > + > + if (blocks) { > + while (blocks--) { > + __sha1_transform(sctx->state, data); > + data += SHA1_BLOCK_SIZE; > + } > + } > + partial = 0; > + } > + > + if (len) > + memcpy(sctx->buffer + partial, data, len); > +} > + > +static void sha1_final(struct sha1_state *sctx, u8 *out) > +{ > + const int bit_offset = SHA1_BLOCK_SIZE - sizeof(__be64); > + unsigned int partial = sctx->count % SHA1_BLOCK_SIZE; > + __be64 *bits = (__be64 *)(sctx->buffer + bit_offset); > + __be32 *digest = (__be32 *)out; > + int i; > + > + sctx->buffer[partial++] = 0x80; > + if (partial > bit_offset) { > + memset(sctx->buffer + partial, 0x0, SHA1_BLOCK_SIZE - partial); > + partial = 0; > + > + __sha1_transform(sctx->state, sctx->buffer); > + } > + > + memset(sctx->buffer + partial, 0x0, bit_offset - partial); > + *bits = cpu_to_be64(sctx->count << 3); > + __sha1_transform(sctx->state, sctx->buffer); > + > + for (i = 0; i < SHA1_DIGEST_SIZE / sizeof(__be32); i++) > + put_unaligned_be32(sctx->state[i], digest++); > + > + *sctx = (struct sha1_state){}; > +} > + > +void sha1(const u8 *data, unsigned int len, u8 *out) > +{ > + struct sha1_state sctx = {0}; > + > + sha1_init(sctx.state); > + sctx.count = 0; > + sha1_update(&sctx, data, len); > + sha1_final(&sctx, out); > +} > +EXPORT_SYMBOL(sha1); > + > MODULE_LICENSE("GPL"); > -- > 2.39.3 >
On 15/02/2024 8:17 am, Ard Biesheuvel wrote: > On Wed, 14 Feb 2024 at 23:31, Ross Philipson <ross.philipson@oracle.com> wrote: >> From: "Daniel P. Smith" <dpsmith@apertussolutions.com> >> >> The SHA algorithms are necessary to measure configuration information into >> the TPM as early as possible before using the values. This implementation >> uses the established approach of #including the SHA libraries directly in >> the code since the compressed kernel is not uncompressed at this point. >> >> The SHA code here has its origins in the code from the main kernel: >> >> commit c4d5b9ffa31f ("crypto: sha1 - implement base layer for SHA-1") >> >> A modified version of this code was introduced to the lib/crypto/sha1.c >> to bring it in line with the sha256 code and allow it to be pulled into the >> setup kernel in the same manner as sha256 is. >> >> Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com> >> Signed-off-by: Ross Philipson <ross.philipson@oracle.com> > We have had some discussions about this, and you really need to > capture the justification in the commit log for introducing new code > that implements an obsolete and broken hashing algorithm. > > SHA-1 is broken and should no longer be used for anything. Introducing > new support for a highly complex boot security feature, and then > relying on SHA-1 in the implementation makes this whole effort seem > almost futile, *unless* you provide some rock solid reasons here why > this is still safe. > > If the upshot would be that some people are stuck with SHA-1 so they > won't be able to use this feature, then I'm not convinced we should > obsess over that. To be absolutely crystal clear here. The choice of hash algorithm(s) are determined by the OEM and the platform, not by Linux. Failing to (at least) cap a PCR in a bank which the OEM/platform left active is a security vulnerability. It permits the unsealing of secrets if an attacker can replay a good set of measurements into an unused bank. The only way to get rid of the requirement for SHA-1 here is to lobby the IHVs/OEMs, or perhaps the TCG, to produce/spec a platform where the SHA-1 banks can be disabled. There are no known such platforms in the market today, to the best of our knowledge. ~Andrew
On Thu, 22 Feb 2024 at 04:05, Andrew Cooper <andrew.cooper3@citrix.com> wrote: > > On 15/02/2024 8:17 am, Ard Biesheuvel wrote: > > On Wed, 14 Feb 2024 at 23:31, Ross Philipson <ross.philipson@oracle.com> wrote: > >> From: "Daniel P. Smith" <dpsmith@apertussolutions.com> > >> > >> The SHA algorithms are necessary to measure configuration information into > >> the TPM as early as possible before using the values. This implementation > >> uses the established approach of #including the SHA libraries directly in > >> the code since the compressed kernel is not uncompressed at this point. > >> > >> The SHA code here has its origins in the code from the main kernel: > >> > >> commit c4d5b9ffa31f ("crypto: sha1 - implement base layer for SHA-1") > >> > >> A modified version of this code was introduced to the lib/crypto/sha1.c > >> to bring it in line with the sha256 code and allow it to be pulled into the > >> setup kernel in the same manner as sha256 is. > >> > >> Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com> > >> Signed-off-by: Ross Philipson <ross.philipson@oracle.com> > > We have had some discussions about this, and you really need to > > capture the justification in the commit log for introducing new code > > that implements an obsolete and broken hashing algorithm. > > > > SHA-1 is broken and should no longer be used for anything. Introducing > > new support for a highly complex boot security feature, and then > > relying on SHA-1 in the implementation makes this whole effort seem > > almost futile, *unless* you provide some rock solid reasons here why > > this is still safe. > > > > If the upshot would be that some people are stuck with SHA-1 so they > > won't be able to use this feature, then I'm not convinced we should > > obsess over that. > > To be absolutely crystal clear here. > > The choice of hash algorithm(s) are determined by the OEM and the > platform, not by Linux. > > Failing to (at least) cap a PCR in a bank which the OEM/platform left > active is a security vulnerability. It permits the unsealing of secrets > if an attacker can replay a good set of measurements into an unused bank. > > The only way to get rid of the requirement for SHA-1 here is to lobby > the IHVs/OEMs, or perhaps the TCG, to produce/spec a platform where the > SHA-1 banks can be disabled. There are no known such platforms in the > market today, to the best of our knowledge. > OK, so mainline Linux does not support secure launch at all today. At this point, we need to decide whether or not tomorrow's mainline Linux will support secure launch with SHA1 or without, right? And the point you are making here is that we need SHA-1 not only to a) support systems that are on TPM 1.2 and support nothing else, but also to b) ensure that crypto agile TPM 2.0 with both SHA-1 and SHA-256 enabled can be supported in a safe manner, which would involve measuring some terminating event into the SHA-1 PCRs to ensure they are not left in a dangling state that might allow an adversary to trick the TPM into unsealing a secret that it shouldn't. So can we support b) without a), and if so, does measuring an arbitrary dummy event into a PCR that is only meant to keep sealed forever really require a SHA-1 implementation, or could we just use an arbitrary (not even random) sequence of 160 bits and use that instead?
On 22/02/2024 9:34 am, Ard Biesheuvel wrote: > On Thu, 22 Feb 2024 at 04:05, Andrew Cooper <andrew.cooper3@citrix.com> wrote: >> On 15/02/2024 8:17 am, Ard Biesheuvel wrote: >>> On Wed, 14 Feb 2024 at 23:31, Ross Philipson <ross.philipson@oracle.com> wrote: >>>> From: "Daniel P. Smith" <dpsmith@apertussolutions.com> >>>> >>>> The SHA algorithms are necessary to measure configuration information into >>>> the TPM as early as possible before using the values. This implementation >>>> uses the established approach of #including the SHA libraries directly in >>>> the code since the compressed kernel is not uncompressed at this point. >>>> >>>> The SHA code here has its origins in the code from the main kernel: >>>> >>>> commit c4d5b9ffa31f ("crypto: sha1 - implement base layer for SHA-1") >>>> >>>> A modified version of this code was introduced to the lib/crypto/sha1.c >>>> to bring it in line with the sha256 code and allow it to be pulled into the >>>> setup kernel in the same manner as sha256 is. >>>> >>>> Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com> >>>> Signed-off-by: Ross Philipson <ross.philipson@oracle.com> >>> We have had some discussions about this, and you really need to >>> capture the justification in the commit log for introducing new code >>> that implements an obsolete and broken hashing algorithm. >>> >>> SHA-1 is broken and should no longer be used for anything. Introducing >>> new support for a highly complex boot security feature, and then >>> relying on SHA-1 in the implementation makes this whole effort seem >>> almost futile, *unless* you provide some rock solid reasons here why >>> this is still safe. >>> >>> If the upshot would be that some people are stuck with SHA-1 so they >>> won't be able to use this feature, then I'm not convinced we should >>> obsess over that. >> To be absolutely crystal clear here. >> >> The choice of hash algorithm(s) are determined by the OEM and the >> platform, not by Linux. >> >> Failing to (at least) cap a PCR in a bank which the OEM/platform left >> active is a security vulnerability. It permits the unsealing of secrets >> if an attacker can replay a good set of measurements into an unused bank. >> >> The only way to get rid of the requirement for SHA-1 here is to lobby >> the IHVs/OEMs, or perhaps the TCG, to produce/spec a platform where the >> SHA-1 banks can be disabled. There are no known such platforms in the >> market today, to the best of our knowledge. >> > OK, so mainline Linux does not support secure launch at all today. At > this point, we need to decide whether or not tomorrow's mainline Linux > will support secure launch with SHA1 or without, right? I'd argue that's a slightly unfair characterisation. We want tomorrow's mainline to support Secure Launch. What that entails under the hood is largely outside of the control of the end user. > And the point you are making here is that we need SHA-1 not only to a) > support systems that are on TPM 1.2 and support nothing else, but also > to b) ensure that crypto agile TPM 2.0 with both SHA-1 and SHA-256 > enabled can be supported in a safe manner, which would involve > measuring some terminating event into the SHA-1 PCRs to ensure they > are not left in a dangling state that might allow an adversary to > trick the TPM into unsealing a secret that it shouldn't. Yes. Also c) because if the end user wants to use SHA-1, they should be able to. > So can we support b) without a), and if so, does measuring an > arbitrary dummy event into a PCR that is only meant to keep sealed > forever really require a SHA-1 implementation, or could we just use an > arbitrary (not even random) sequence of 160 bits and use that instead? a) and b) are in principle independent, but we cannot support b) without SHA-1. To cap a PCR, the event log still needs to be kept accurate, and that's at least one SHA-1 calculation. If you were to simply extend a dummy value, the system hopefully fails safe, but the user gets "something went wrong, you're on your own", rather than "we intentionally blocked the use of SHA-1, everything is good". And frankly, you need SHA-1 just to read the event log, if any component (including TXT itself) wrote a SHA-1 entry into it. To be blunt. SHA-1 support is not viably optional today as far as Secure Launch is concerned. If there's a suitable Kconfig symbol to use for people who want a completely SHA-1-less kernel, then we can make Secure Launch depend on that until such time as the hardware ecosystem has caught up. ~Andrew
On Thu, 22 Feb 2024 at 13:30, Andrew Cooper <andrew.cooper3@citrix.com> wrote: > > On 22/02/2024 9:34 am, Ard Biesheuvel wrote: > > On Thu, 22 Feb 2024 at 04:05, Andrew Cooper <andrew.cooper3@citrix.com> wrote: > >> On 15/02/2024 8:17 am, Ard Biesheuvel wrote: > >>> On Wed, 14 Feb 2024 at 23:31, Ross Philipson <ross.philipson@oracle.com> wrote: > >>>> From: "Daniel P. Smith" <dpsmith@apertussolutions.com> > >>>> > >>>> The SHA algorithms are necessary to measure configuration information into > >>>> the TPM as early as possible before using the values. This implementation > >>>> uses the established approach of #including the SHA libraries directly in > >>>> the code since the compressed kernel is not uncompressed at this point. > >>>> > >>>> The SHA code here has its origins in the code from the main kernel: > >>>> > >>>> commit c4d5b9ffa31f ("crypto: sha1 - implement base layer for SHA-1") > >>>> > >>>> A modified version of this code was introduced to the lib/crypto/sha1.c > >>>> to bring it in line with the sha256 code and allow it to be pulled into the > >>>> setup kernel in the same manner as sha256 is. > >>>> > >>>> Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com> > >>>> Signed-off-by: Ross Philipson <ross.philipson@oracle.com> > >>> We have had some discussions about this, and you really need to > >>> capture the justification in the commit log for introducing new code > >>> that implements an obsolete and broken hashing algorithm. > >>> > >>> SHA-1 is broken and should no longer be used for anything. Introducing > >>> new support for a highly complex boot security feature, and then > >>> relying on SHA-1 in the implementation makes this whole effort seem > >>> almost futile, *unless* you provide some rock solid reasons here why > >>> this is still safe. > >>> > >>> If the upshot would be that some people are stuck with SHA-1 so they > >>> won't be able to use this feature, then I'm not convinced we should > >>> obsess over that. > >> To be absolutely crystal clear here. > >> > >> The choice of hash algorithm(s) are determined by the OEM and the > >> platform, not by Linux. > >> > >> Failing to (at least) cap a PCR in a bank which the OEM/platform left > >> active is a security vulnerability. It permits the unsealing of secrets > >> if an attacker can replay a good set of measurements into an unused bank. > >> > >> The only way to get rid of the requirement for SHA-1 here is to lobby > >> the IHVs/OEMs, or perhaps the TCG, to produce/spec a platform where the > >> SHA-1 banks can be disabled. There are no known such platforms in the > >> market today, to the best of our knowledge. > >> > > OK, so mainline Linux does not support secure launch at all today. At > > this point, we need to decide whether or not tomorrow's mainline Linux > > will support secure launch with SHA1 or without, right? > > I'd argue that's a slightly unfair characterisation. > Fair enough. I'm genuinely trying to have a precise understanding of this, not trying to be dismissive. > We want tomorrow's mainline to support Secure Launch. What that entails > under the hood is largely outside of the control of the end user. > So the debate is really whether it makes sense at all to support Secure Launch on systems that are stuck on an obsolete and broken hash algorithm. This is not hyperbole: SHA-1 is broken today and once these changes hit production 1-2 years down the line, the situation will only have deteriorated. And another 2-3 years later, we will be the ones chasing obscure bugs on systems that were already obsolete when this support was added. So what is the value proposition here? An end user today, who is mindful enough of security to actively invest the effort to migrate their system from ordinary measured boot to secure launch, is really going to do so on a system that only implements SHA-1 support? > > And the point you are making here is that we need SHA-1 not only to a) > > support systems that are on TPM 1.2 and support nothing else, but also > > to b) ensure that crypto agile TPM 2.0 with both SHA-1 and SHA-256 > > enabled can be supported in a safe manner, which would involve > > measuring some terminating event into the SHA-1 PCRs to ensure they > > are not left in a dangling state that might allow an adversary to > > trick the TPM into unsealing a secret that it shouldn't. > > Yes. Also c) because if the end user wants to use SHA-1, they should be > able to. > The end user can do whatever they want, of course. Whether it belongs in the upstream is an entirely different matter, though, especially because we will effectively be forced to support this forever. > > So can we support b) without a), and if so, does measuring an > > arbitrary dummy event into a PCR that is only meant to keep sealed > > forever really require a SHA-1 implementation, or could we just use an > > arbitrary (not even random) sequence of 160 bits and use that instead? > > a) and b) are in principle independent, but we cannot support b) without > SHA-1. > > To cap a PCR, the event log still needs to be kept accurate, and that's > at least one SHA-1 calculation. If you were to simply extend a dummy > value, the system hopefully fails safe, but the user gets "something > went wrong, you're on your own", rather than "we intentionally blocked > the use of SHA-1, everything is good". > > And frankly, you need SHA-1 just to read the event log, if any component > (including TXT itself) wrote a SHA-1 entry into it. > > > To be blunt. SHA-1 support is not viably optional today as far as > Secure Launch is concerned. If there's a suitable Kconfig symbol to use > for people who want a completely SHA-1-less kernel, then we can make > Secure Launch depend on that until such time as the hardware ecosystem > has caught up. > Yes, this crossed my mind as well. There is a Kconfig symbol CRYPTO_USER_API_ENABLE_OBSOLETE I added a while ago for a similar purpose. I am still disappointed that we have to go down this path, but I understand the concerns now that you have explained them to me (again) in more detail. These considerations need to be recorded in the documentation or commit logs as well, so that we can easily refer back to them without having to dig through the mail archives.
On 23/02/2024 9:27 am, Ard Biesheuvel wrote: > On Thu, 22 Feb 2024 at 13:30, Andrew Cooper <andrew.cooper3@citrix.com> wrote: >> On 22/02/2024 9:34 am, Ard Biesheuvel wrote: >>> On Thu, 22 Feb 2024 at 04:05, Andrew Cooper <andrew.cooper3@citrix.com> wrote: >>>> On 15/02/2024 8:17 am, Ard Biesheuvel wrote: >>>>> On Wed, 14 Feb 2024 at 23:31, Ross Philipson <ross.philipson@oracle.com> wrote: >>>>>> From: "Daniel P. Smith" <dpsmith@apertussolutions.com> >>>>>> >>>>>> The SHA algorithms are necessary to measure configuration information into >>>>>> the TPM as early as possible before using the values. This implementation >>>>>> uses the established approach of #including the SHA libraries directly in >>>>>> the code since the compressed kernel is not uncompressed at this point. >>>>>> >>>>>> The SHA code here has its origins in the code from the main kernel: >>>>>> >>>>>> commit c4d5b9ffa31f ("crypto: sha1 - implement base layer for SHA-1") >>>>>> >>>>>> A modified version of this code was introduced to the lib/crypto/sha1.c >>>>>> to bring it in line with the sha256 code and allow it to be pulled into the >>>>>> setup kernel in the same manner as sha256 is. >>>>>> >>>>>> Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com> >>>>>> Signed-off-by: Ross Philipson <ross.philipson@oracle.com> >>>>> We have had some discussions about this, and you really need to >>>>> capture the justification in the commit log for introducing new code >>>>> that implements an obsolete and broken hashing algorithm. >>>>> >>>>> SHA-1 is broken and should no longer be used for anything. Introducing >>>>> new support for a highly complex boot security feature, and then >>>>> relying on SHA-1 in the implementation makes this whole effort seem >>>>> almost futile, *unless* you provide some rock solid reasons here why >>>>> this is still safe. >>>>> >>>>> If the upshot would be that some people are stuck with SHA-1 so they >>>>> won't be able to use this feature, then I'm not convinced we should >>>>> obsess over that. >>>> To be absolutely crystal clear here. >>>> >>>> The choice of hash algorithm(s) are determined by the OEM and the >>>> platform, not by Linux. >>>> >>>> Failing to (at least) cap a PCR in a bank which the OEM/platform left >>>> active is a security vulnerability. It permits the unsealing of secrets >>>> if an attacker can replay a good set of measurements into an unused bank. >>>> >>>> The only way to get rid of the requirement for SHA-1 here is to lobby >>>> the IHVs/OEMs, or perhaps the TCG, to produce/spec a platform where the >>>> SHA-1 banks can be disabled. There are no known such platforms in the >>>> market today, to the best of our knowledge. >>>> >>> OK, so mainline Linux does not support secure launch at all today. At >>> this point, we need to decide whether or not tomorrow's mainline Linux >>> will support secure launch with SHA1 or without, right? >> I'd argue that's a slightly unfair characterisation. >> > Fair enough. I'm genuinely trying to have a precise understanding of > this, not trying to be dismissive. Sure, and neither am I. (And frankly, I vastly prefer this reasoned discussion to prior ones.) Secure Launch technology really is used today as out-of-tree code, and it has taken ~15y to get to this point of doing it nicely in an ecosystem that is wider than just Linux. (Not a criticism, just an observation) We're looking not to get blocked with a brand new objection which approximates to "it's now not perfect, therefore you can't have something that's still a lot better than nothing". A major reason why the hardware ecosystem is out of date is because almost no-one uses it, because it's horribly complicated to configure, because it's a set of large out-of-tree patche series against your bootloader, hypervisor and kernel. The goal of the Trenchboot project is to make it easy to use (i.e. upstream support in the relevant projects), so that more people can use it, in order to drive the hardware ecosystem forward. Very seriously - Linux taking this series, even off by default and with a "SHA-1 considered hazardous for your health" warning somewhere, will still have a material positive impact in getting the hardware ecosystem to improve. It is, by far and away, the best thing that we (Trenchboot) can do in order to move towards a SHA-1-less future. Trenchboot do have a specific intent to get to that future, and beyond, but it's a multi-year task. >> We want tomorrow's mainline to support Secure Launch. What that entails >> under the hood is largely outside of the control of the end user. >> > So the debate is really whether it makes sense at all to support > Secure Launch on systems that are stuck on an obsolete and broken hash > algorithm. This is not hyperbole: SHA-1 is broken today and once these > changes hit production 1-2 years down the line, the situation will > only have deteriorated. And another 2-3 years later, we will be the > ones chasing obscure bugs on systems that were already obsolete when > this support was added. There are indeed collisions, and this will indeed get worse over time. But right now it still takes nation-state (or certain corporation) resources to calculate a collision, and that would have to be specific to the exact firmware/settings/hypervisor/kernel/initrd configuration of the target device. Google et al invested the effort in SHAttered in order to drive change in the industry, but that doesn't mean it's viable as a general attack yet. There are far more cost effective options, even a $4 wrench... > So what is the value proposition here? An end user today, who is > mindful enough of security to actively invest the effort to migrate > their system from ordinary measured boot to secure launch, is really > going to do so on a system that only implements SHA-1 support? Oh both Intel and AMD, the base technology is around in all platforms the support virt. On Intel, it's SKU-limited to vPRO, but platforms with fTPM2.0 have been generally SHA1+SHA256 capable for years now. A security conscious end user would just want to cap the SHA1 banks and run with SHA256. Furthermore, when the attestation is based on a SHA1+SHA256 measurement, the attestor can spot and reject SHA1 collisions, so this configuration really should be safe to the concerns raised here. On AMD, it's not SKU-limited. However, their fTPM2.0 isn't SKINIT compatible, and we were basically told "show us people using SKINIT first". I'm not sure if we've got as far as trying to an LPC TPM 2.0 on AMD yet. Even bus interception attacks can be defended against with TPM encrypted sessions, but we put this in the "not for v1" bucket. It's not a secret - the intent of getting this technology more-generally usable (and therefore used) is to be able to go back to Intel and say "hey notice how AMD give this technology to everyone", and to say AMD "hey notice how Intel have this working with TPM2". Both have been persuaded along this direction by Microsoft by virtue of including the Pluton IP blob in the main CPU package. >>> And the point you are making here is that we need SHA-1 not only to a) >>> support systems that are on TPM 1.2 and support nothing else, but also >>> to b) ensure that crypto agile TPM 2.0 with both SHA-1 and SHA-256 >>> enabled can be supported in a safe manner, which would involve >>> measuring some terminating event into the SHA-1 PCRs to ensure they >>> are not left in a dangling state that might allow an adversary to >>> trick the TPM into unsealing a secret that it shouldn't. >> Yes. Also c) because if the end user wants to use SHA-1, they should be >> able to. >> > The end user can do whatever they want, of course. Whether it belongs > in the upstream is an entirely different matter, though, especially > because we will effectively be forced to support this forever. > > >>> So can we support b) without a), and if so, does measuring an >>> arbitrary dummy event into a PCR that is only meant to keep sealed >>> forever really require a SHA-1 implementation, or could we just use an >>> arbitrary (not even random) sequence of 160 bits and use that instead? >> a) and b) are in principle independent, but we cannot support b) without >> SHA-1. >> >> To cap a PCR, the event log still needs to be kept accurate, and that's >> at least one SHA-1 calculation. If you were to simply extend a dummy >> value, the system hopefully fails safe, but the user gets "something >> went wrong, you're on your own", rather than "we intentionally blocked >> the use of SHA-1, everything is good". >> >> And frankly, you need SHA-1 just to read the event log, if any component >> (including TXT itself) wrote a SHA-1 entry into it. >> >> >> To be blunt. SHA-1 support is not viably optional today as far as >> Secure Launch is concerned. If there's a suitable Kconfig symbol to use >> for people who want a completely SHA-1-less kernel, then we can make >> Secure Launch depend on that until such time as the hardware ecosystem >> has caught up. >> > Yes, this crossed my mind as well. There is a Kconfig symbol > CRYPTO_USER_API_ENABLE_OBSOLETE I added a while ago for a similar > purpose. > > I am still disappointed that we have to go down this path, but I > understand the concerns now that you have explained them to me (again) > in more detail. > > These considerations need to be recorded in the documentation or > commit logs as well, so that we can easily refer back to them without > having to dig through the mail archives. Yes, and I agree. We're not looking to try and force this in with underhand tactics. But a blind "nack to any SHA-1" is similarly damaging in the opposite direction. ~Andrew
On Fri, Feb 23, 2024 at 04:42:11PM +0000, Andrew Cooper wrote: > > Yes, and I agree. We're not looking to try and force this in with > underhand tactics. > > But a blind "nack to any SHA-1" is similarly damaging in the opposite > direction. > Well, reviewers have said they'd prefer that SHA-1 not be included and given some thoughtful reasons for that. But also they've given suggestions on how to make the SHA-1 support more palatable, such as splitting it into a separate patch and giving it a proper justification. All suggestions have been ignored. - Eric
On 23/02/2024 5:54 pm, Eric Biggers wrote: > On Fri, Feb 23, 2024 at 04:42:11PM +0000, Andrew Cooper wrote: >> Yes, and I agree. We're not looking to try and force this in with >> underhand tactics. >> >> But a blind "nack to any SHA-1" is similarly damaging in the opposite >> direction. >> > Well, reviewers have said they'd prefer that SHA-1 not be included and given > some thoughtful reasons for that. But also they've given suggestions on how to > make the SHA-1 support more palatable, such as splitting it into a separate > patch and giving it a proper justification. > > All suggestions have been ignored. The public record demonstrates otherwise. But are you saying that you'd be happy if the commit message read something more like: ---8<--- For better or worse, Secure Launch needs SHA-1 and SHA-256. The choice of hashes used lie with the platform firmware, not with software, and is often outside of the users control. Even if we'd prefer to use SHA-256-only, if firmware elected to start us with the SHA-1 and SHA-256 backs active, we still need SHA-1 to parse the TPM event log thus far, and deliberately cap the SHA-1 PCRs in order to safely use SHA-256 for everything else. --- ? ~Andrew
On Fri, Feb 23, 2024 at 06:20:27PM +0000, Andrew Cooper wrote: > On 23/02/2024 5:54 pm, Eric Biggers wrote: > > On Fri, Feb 23, 2024 at 04:42:11PM +0000, Andrew Cooper wrote: > >> Yes, and I agree. We're not looking to try and force this in with > >> underhand tactics. > >> > >> But a blind "nack to any SHA-1" is similarly damaging in the opposite > >> direction. > >> > > Well, reviewers have said they'd prefer that SHA-1 not be included and given > > some thoughtful reasons for that. But also they've given suggestions on how to > > make the SHA-1 support more palatable, such as splitting it into a separate > > patch and giving it a proper justification. > > > > All suggestions have been ignored. > > The public record demonstrates otherwise. > > But are you saying that you'd be happy if the commit message read > something more like: > > ---8<--- > For better or worse, Secure Launch needs SHA-1 and SHA-256. > > The choice of hashes used lie with the platform firmware, not with > software, and is often outside of the users control. > > Even if we'd prefer to use SHA-256-only, if firmware elected to start us > with the SHA-1 and SHA-256 backs active, we still need SHA-1 to parse > the TPM event log thus far, and deliberately cap the SHA-1 PCRs in order > to safely use SHA-256 for everything else. > --- Please take some time to read through the comments that reviewers have left on previous versions of the patchset. - Eric
On Fri, Feb 23, 2024, at 10:30 AM, Eric Biggers wrote: > On Fri, Feb 23, 2024 at 06:20:27PM +0000, Andrew Cooper wrote: >> On 23/02/2024 5:54 pm, Eric Biggers wrote: >> > On Fri, Feb 23, 2024 at 04:42:11PM +0000, Andrew Cooper wrote: >> >> Yes, and I agree. We're not looking to try and force this in with >> >> underhand tactics. >> >> >> >> But a blind "nack to any SHA-1" is similarly damaging in the opposite >> >> direction. >> >> >> > Well, reviewers have said they'd prefer that SHA-1 not be included and given >> > some thoughtful reasons for that. But also they've given suggestions on how to >> > make the SHA-1 support more palatable, such as splitting it into a separate >> > patch and giving it a proper justification. >> > >> > All suggestions have been ignored. >> >> The public record demonstrates otherwise. >> >> But are you saying that you'd be happy if the commit message read >> something more like: >> >> ---8<--- >> For better or worse, Secure Launch needs SHA-1 and SHA-256. >> >> The choice of hashes used lie with the platform firmware, not with >> software, and is often outside of the users control. >> >> Even if we'd prefer to use SHA-256-only, if firmware elected to start us >> with the SHA-1 and SHA-256 backs active, we still need SHA-1 to parse >> the TPM event log thus far, and deliberately cap the SHA-1 PCRs in order >> to safely use SHA-256 for everything else. >> --- > > Please take some time to read through the comments that reviewers have left on > previous versions of the patchset. So I went and read through the old comments, and I'm lost. In brief summary: If the hardware+firmware only supports SHA-1, then some reviewers would prefer Linux not to support DRTM. I personally think this is a bit silly, but it's not entirely unreasonable. Maybe it should be a config option? If the hardware+firmware does support SHA-256, then it sounds (to me, reading this -- I haven't dug into the right spec pages) that, for optimal security, something still needs to effectively turn SHA-1 *off* at runtime by capping the event log properly. And that requires computing a SHA-1 hash. And, to be clear, (a) this is only on systems that already support SHA-256 and that we should support and (b) *not* doing so leaves us potentially more vulnerable to SHA-1 attacks than doing so. And no SHA-256-supporting tooling will actually be compromised by a SHA-1 compromise if we cap the event log. So is there a way forward? Just saying "read through the comments" seems like a dead end. Thanks, Andy
On Wed, Apr 03, 2024 at 09:32:02AM -0700, Andy Lutomirski wrote: > On Fri, Feb 23, 2024, at 10:30 AM, Eric Biggers wrote: > > On Fri, Feb 23, 2024 at 06:20:27PM +0000, Andrew Cooper wrote: > >> On 23/02/2024 5:54 pm, Eric Biggers wrote: > >> > On Fri, Feb 23, 2024 at 04:42:11PM +0000, Andrew Cooper wrote: > >> >> Yes, and I agree. We're not looking to try and force this in with > >> >> underhand tactics. > >> >> > >> >> But a blind "nack to any SHA-1" is similarly damaging in the opposite > >> >> direction. > >> >> > >> > Well, reviewers have said they'd prefer that SHA-1 not be included and given > >> > some thoughtful reasons for that. But also they've given suggestions on how to > >> > make the SHA-1 support more palatable, such as splitting it into a separate > >> > patch and giving it a proper justification. > >> > > >> > All suggestions have been ignored. > >> > >> The public record demonstrates otherwise. > >> > >> But are you saying that you'd be happy if the commit message read > >> something more like: > >> > >> ---8<--- > >> For better or worse, Secure Launch needs SHA-1 and SHA-256. > >> > >> The choice of hashes used lie with the platform firmware, not with > >> software, and is often outside of the users control. > >> > >> Even if we'd prefer to use SHA-256-only, if firmware elected to start us > >> with the SHA-1 and SHA-256 backs active, we still need SHA-1 to parse > >> the TPM event log thus far, and deliberately cap the SHA-1 PCRs in order > >> to safely use SHA-256 for everything else. > >> --- > > > > Please take some time to read through the comments that reviewers have left on > > previous versions of the patchset. > > So I went and read through the old comments, and I'm lost. In brief summary: > > If the hardware+firmware only supports SHA-1, then some reviewers would prefer > Linux not to support DRTM. I personally think this is a bit silly, but it's > not entirely unreasonable. Maybe it should be a config option? > > If the hardware+firmware does support SHA-256, then it sounds (to me, reading > this -- I haven't dug into the right spec pages) that, for optimal security, > something still needs to effectively turn SHA-1 *off* at runtime by capping > the event log properly. And that requires computing a SHA-1 hash. And, to be > clear, (a) this is only on systems that already support SHA-256 and that we > should support and (b) *not* doing so leaves us potentially more vulnerable to > SHA-1 attacks than doing so. And no SHA-256-supporting tooling will actually > be compromised by a SHA-1 compromise if we cap the event log. > > So is there a way forward? Just saying "read through the comments" seems like > a dead end. > It seems there may be a justification for some form of SHA-1 support in this feature. As I've said, the problem is that it's not explained in the patchset itself. Rather, it just talks about "SHA" and pretends like SHA-1 and SHA-2 are basically the same. In fact, SHA-1 differs drastically from SHA-2 in terms of security. SHA-1 support should be added in a separate patch, with a clearly explained rationale *in the patch itself* for the SHA-1 support *specifically*. - Eric
On 4/3/24 4:56 PM, Eric Biggers wrote: > On Wed, Apr 03, 2024 at 09:32:02AM -0700, Andy Lutomirski wrote: >> On Fri, Feb 23, 2024, at 10:30 AM, Eric Biggers wrote: >>> On Fri, Feb 23, 2024 at 06:20:27PM +0000, Andrew Cooper wrote: >>>> On 23/02/2024 5:54 pm, Eric Biggers wrote: >>>>> On Fri, Feb 23, 2024 at 04:42:11PM +0000, Andrew Cooper wrote: >>>>>> Yes, and I agree. We're not looking to try and force this in with >>>>>> underhand tactics. >>>>>> >>>>>> But a blind "nack to any SHA-1" is similarly damaging in the opposite >>>>>> direction. >>>>>> >>>>> Well, reviewers have said they'd prefer that SHA-1 not be included and given >>>>> some thoughtful reasons for that. But also they've given suggestions on how to >>>>> make the SHA-1 support more palatable, such as splitting it into a separate >>>>> patch and giving it a proper justification. >>>>> >>>>> All suggestions have been ignored. >>>> >>>> The public record demonstrates otherwise. >>>> >>>> But are you saying that you'd be happy if the commit message read >>>> something more like: >>>> >>>> ---8<--- >>>> For better or worse, Secure Launch needs SHA-1 and SHA-256. >>>> >>>> The choice of hashes used lie with the platform firmware, not with >>>> software, and is often outside of the users control. >>>> >>>> Even if we'd prefer to use SHA-256-only, if firmware elected to start us >>>> with the SHA-1 and SHA-256 backs active, we still need SHA-1 to parse >>>> the TPM event log thus far, and deliberately cap the SHA-1 PCRs in order >>>> to safely use SHA-256 for everything else. >>>> --- >>> >>> Please take some time to read through the comments that reviewers have left on >>> previous versions of the patchset. >> >> So I went and read through the old comments, and I'm lost. In brief summary: >> >> If the hardware+firmware only supports SHA-1, then some reviewers would prefer >> Linux not to support DRTM. I personally think this is a bit silly, but it's >> not entirely unreasonable. Maybe it should be a config option? >> >> If the hardware+firmware does support SHA-256, then it sounds (to me, reading >> this -- I haven't dug into the right spec pages) that, for optimal security, >> something still needs to effectively turn SHA-1 *off* at runtime by capping >> the event log properly. And that requires computing a SHA-1 hash. And, to be >> clear, (a) this is only on systems that already support SHA-256 and that we >> should support and (b) *not* doing so leaves us potentially more vulnerable to >> SHA-1 attacks than doing so. And no SHA-256-supporting tooling will actually >> be compromised by a SHA-1 compromise if we cap the event log. >> >> So is there a way forward? Just saying "read through the comments" seems like >> a dead end. >> > > It seems there may be a justification for some form of SHA-1 support in this > feature. As I've said, the problem is that it's not explained in the patchset > itself. Rather, it just talks about "SHA" and pretends like SHA-1 and SHA-2 are > basically the same. In fact, SHA-1 differs drastically from SHA-2 in terms of > security. SHA-1 support should be added in a separate patch, with a clearly > explained rationale *in the patch itself* for the SHA-1 support *specifically*. For the record, we were never trying to "pretend" or obfuscate the use of SHA-1. It was simply expedient to put the hash algorithm changes in one patch. We have now separated the patches for clarity and will add any text that explains our use and/or explain the issues with its use. We went back through the comments and tried to address everything that came up about the use of SHA-1. We will review it all again before posting another patch set. Thank you for your feedback. Ross > > - Eric
On Thu Apr 4, 2024 at 2:56 AM EEST, Eric Biggers wrote: > On Wed, Apr 03, 2024 at 09:32:02AM -0700, Andy Lutomirski wrote: > > On Fri, Feb 23, 2024, at 10:30 AM, Eric Biggers wrote: > > > On Fri, Feb 23, 2024 at 06:20:27PM +0000, Andrew Cooper wrote: > > >> On 23/02/2024 5:54 pm, Eric Biggers wrote: > > >> > On Fri, Feb 23, 2024 at 04:42:11PM +0000, Andrew Cooper wrote: > > >> >> Yes, and I agree. We're not looking to try and force this in with > > >> >> underhand tactics. > > >> >> > > >> >> But a blind "nack to any SHA-1" is similarly damaging in the opposite > > >> >> direction. > > >> >> > > >> > Well, reviewers have said they'd prefer that SHA-1 not be included and given > > >> > some thoughtful reasons for that. But also they've given suggestions on how to > > >> > make the SHA-1 support more palatable, such as splitting it into a separate > > >> > patch and giving it a proper justification. > > >> > > > >> > All suggestions have been ignored. > > >> > > >> The public record demonstrates otherwise. > > >> > > >> But are you saying that you'd be happy if the commit message read > > >> something more like: > > >> > > >> ---8<--- > > >> For better or worse, Secure Launch needs SHA-1 and SHA-256. > > >> > > >> The choice of hashes used lie with the platform firmware, not with > > >> software, and is often outside of the users control. > > >> > > >> Even if we'd prefer to use SHA-256-only, if firmware elected to start us > > >> with the SHA-1 and SHA-256 backs active, we still need SHA-1 to parse > > >> the TPM event log thus far, and deliberately cap the SHA-1 PCRs in order > > >> to safely use SHA-256 for everything else. > > >> --- > > > > > > Please take some time to read through the comments that reviewers have left on > > > previous versions of the patchset. > > > > So I went and read through the old comments, and I'm lost. In brief summary: > > > > If the hardware+firmware only supports SHA-1, then some reviewers would prefer > > Linux not to support DRTM. I personally think this is a bit silly, but it's > > not entirely unreasonable. Maybe it should be a config option? > > > > If the hardware+firmware does support SHA-256, then it sounds (to me, reading > > this -- I haven't dug into the right spec pages) that, for optimal security, > > something still needs to effectively turn SHA-1 *off* at runtime by capping > > the event log properly. And that requires computing a SHA-1 hash. And, to be > > clear, (a) this is only on systems that already support SHA-256 and that we > > should support and (b) *not* doing so leaves us potentially more vulnerable to > > SHA-1 attacks than doing so. And no SHA-256-supporting tooling will actually > > be compromised by a SHA-1 compromise if we cap the event log. > > > > So is there a way forward? Just saying "read through the comments" seems like > > a dead end. > > > > It seems there may be a justification for some form of SHA-1 support in this > feature. As I've said, the problem is that it's not explained in the patchset > itself. Rather, it just talks about "SHA" and pretends like SHA-1 and SHA-2 are > basically the same. In fact, SHA-1 differs drastically from SHA-2 in terms of > security. SHA-1 support should be added in a separate patch, with a clearly > explained rationale *in the patch itself* for the SHA-1 support *specifically*. Yeah, this is important so that we don't end up deleting that support by accident. Just adding to denote that this more than just a "process issue". > - Eric BR, Jarkko
diff --git a/arch/x86/boot/compressed/Makefile b/arch/x86/boot/compressed/Makefile index f19c038409aa..a1b018eb9801 100644 --- a/arch/x86/boot/compressed/Makefile +++ b/arch/x86/boot/compressed/Makefile @@ -118,6 +118,8 @@ vmlinux-objs-$(CONFIG_EFI) += $(obj)/efi.o vmlinux-objs-$(CONFIG_EFI_MIXED) += $(obj)/efi_mixed.o vmlinux-objs-$(CONFIG_EFI_STUB) += $(objtree)/drivers/firmware/efi/libstub/lib.a +vmlinux-objs-$(CONFIG_SECURE_LAUNCH) += $(obj)/early_sha1.o $(obj)/early_sha256.o + $(obj)/vmlinux: $(vmlinux-objs-y) FORCE $(call if_changed,ld) diff --git a/arch/x86/boot/compressed/early_sha1.c b/arch/x86/boot/compressed/early_sha1.c new file mode 100644 index 000000000000..0c7cf6f8157a --- /dev/null +++ b/arch/x86/boot/compressed/early_sha1.c @@ -0,0 +1,12 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (c) 2022 Apertus Solutions, LLC. + */ + +#include <linux/init.h> +#include <linux/linkage.h> +#include <linux/string.h> +#include <asm/boot.h> +#include <asm/unaligned.h> + +#include "../../../../lib/crypto/sha1.c" diff --git a/arch/x86/boot/compressed/early_sha256.c b/arch/x86/boot/compressed/early_sha256.c new file mode 100644 index 000000000000..54930166ffee --- /dev/null +++ b/arch/x86/boot/compressed/early_sha256.c @@ -0,0 +1,6 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (c) 2022 Apertus Solutions, LLC + */ + +#include "../../../../lib/crypto/sha256.c" diff --git a/include/crypto/sha1.h b/include/crypto/sha1.h index 044ecea60ac8..d715dd5332e1 100644 --- a/include/crypto/sha1.h +++ b/include/crypto/sha1.h @@ -42,5 +42,6 @@ extern int crypto_sha1_finup(struct shash_desc *desc, const u8 *data, #define SHA1_WORKSPACE_WORDS 16 void sha1_init(__u32 *buf); void sha1_transform(__u32 *digest, const char *data, __u32 *W); +void sha1(const u8 *data, unsigned int len, u8 *out); #endif /* _CRYPTO_SHA1_H */ diff --git a/lib/crypto/sha1.c b/lib/crypto/sha1.c index 1aebe7be9401..10152125b338 100644 --- a/lib/crypto/sha1.c +++ b/lib/crypto/sha1.c @@ -137,4 +137,85 @@ void sha1_init(__u32 *buf) } EXPORT_SYMBOL(sha1_init); +static void __sha1_transform(u32 *digest, const char *data) +{ + u32 ws[SHA1_WORKSPACE_WORDS]; + + sha1_transform(digest, data, ws); + + memzero_explicit(ws, sizeof(ws)); +} + +static void sha1_update(struct sha1_state *sctx, const u8 *data, unsigned int len) +{ + unsigned int partial = sctx->count % SHA1_BLOCK_SIZE; + + sctx->count += len; + + if (likely((partial + len) >= SHA1_BLOCK_SIZE)) { + int blocks; + + if (partial) { + int p = SHA1_BLOCK_SIZE - partial; + + memcpy(sctx->buffer + partial, data, p); + data += p; + len -= p; + + __sha1_transform(sctx->state, sctx->buffer); + } + + blocks = len / SHA1_BLOCK_SIZE; + len %= SHA1_BLOCK_SIZE; + + if (blocks) { + while (blocks--) { + __sha1_transform(sctx->state, data); + data += SHA1_BLOCK_SIZE; + } + } + partial = 0; + } + + if (len) + memcpy(sctx->buffer + partial, data, len); +} + +static void sha1_final(struct sha1_state *sctx, u8 *out) +{ + const int bit_offset = SHA1_BLOCK_SIZE - sizeof(__be64); + unsigned int partial = sctx->count % SHA1_BLOCK_SIZE; + __be64 *bits = (__be64 *)(sctx->buffer + bit_offset); + __be32 *digest = (__be32 *)out; + int i; + + sctx->buffer[partial++] = 0x80; + if (partial > bit_offset) { + memset(sctx->buffer + partial, 0x0, SHA1_BLOCK_SIZE - partial); + partial = 0; + + __sha1_transform(sctx->state, sctx->buffer); + } + + memset(sctx->buffer + partial, 0x0, bit_offset - partial); + *bits = cpu_to_be64(sctx->count << 3); + __sha1_transform(sctx->state, sctx->buffer); + + for (i = 0; i < SHA1_DIGEST_SIZE / sizeof(__be32); i++) + put_unaligned_be32(sctx->state[i], digest++); + + *sctx = (struct sha1_state){}; +} + +void sha1(const u8 *data, unsigned int len, u8 *out) +{ + struct sha1_state sctx = {0}; + + sha1_init(sctx.state); + sctx.count = 0; + sha1_update(&sctx, data, len); + sha1_final(&sctx, out); +} +EXPORT_SYMBOL(sha1); + MODULE_LICENSE("GPL");