Re: [PATCH v8 06/15] x86: Add early SHA support for Secure Launch early measurements

From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Ard Biesheuvel <ardb@kernel.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Ross Philipson <ross.philipson@oracle.com>,
	linux-kernel@vger.kernel.org, x86@kernel.org,
	linux-integrity@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-crypto@vger.kernel.org, kexec@lists.infradead.org,
	linux-efi@vger.kernel.org, dpsmith@apertussolutions.com,
	tglx@linutronix.de, mingo@redhat.com, bp@alien8.de,
	hpa@zytor.com, dave.hansen@linux.intel.com, mjg59@srcf.ucam.org,
	James.Bottomley@hansenpartnership.com, peterhuewe@gmx.de,
	jarkko@kernel.org, jgg@ziepe.ca, luto@amacapital.net,
	nivedita@alum.mit.edu, herbert@gondor.apana.org.au,
	davem@davemloft.net, kanth.ghatraju@oracle.com,
	trenchboot-devel@googlegroups.com,
	Eric Biggers <ebiggers@kernel.org>
Subject: Re: [PATCH v8 06/15] x86: Add early SHA support for Secure Launch early measurements
Date: Thu, 22 Feb 2024 12:30:50 +0000	[thread overview]
Message-ID: <1a8e69a7-89eb-4d36-94d6-0da662d8b72f@citrix.com> (raw)
In-Reply-To: <CAMj1kXFTu+bV2kQhAyu15hrYai20NcBLb4Zu8XG2Y-XjL0f+rw@mail.gmail.com>

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