[PATCH v6 06/14] x86: Add early SHA support for Secure Launch early measurements

[Andrew Cooper]

On 12/05/2023 12:58 pm, Ard Biesheuvel wrote:
> On Fri, 12 May 2023 at 13:28, Matthew Garrett <mjg59 at srcf.ucam.org> wrote:
>> On Fri, May 12, 2023 at 01:18:45PM +0200, Ard Biesheuvel wrote:
>>> On Fri, 12 May 2023 at 13:04, Matthew Garrett <mjg59 at srcf.ucam.org> wrote:
>>>> On Tue, May 09, 2023 at 06:21:44PM -0700, Eric Biggers wrote:
>>>>
>>>>> SHA-1 is insecure.  Why are you still using SHA-1?  Don't TPMs support SHA-2
>>>>> now?
>>>> TXT is supported on some TPM 1.2 systems as well. TPM 2 systems are also
>>>> at the whim of the firmware in terms of whether the SHA-2 banks are
>>>> enabled. But even if the SHA-2 banks are enabled, if you suddenly stop
>>>> extending the SHA-1 banks, a malicious actor can later turn up and
>>>> extend whatever they want into them and present a SHA-1-only
>>>> attestation. Ideally whatever is handling that attestation should know
>>>> whether or not to expect an attestation with SHA-2, but the easiest way
>>>> to maintain security is to always extend all banks.
>>>>
>>> Wouldn't it make more sense to measure some terminating event into the
>>> SHA-1 banks instead?
>> Unless we assert that SHA-1 events are unsupported, it seems a bit odd
>> to force a policy on people who have both banks enabled. People with
>> mixed fleets are potentially going to be dealing with SHA-1 measurements
>> for a while yet, and while there's obviously a security benefit in using
>> SHA-2 instead it'd be irritating to have to maintain two attestation
>> policies.
> I understand why that matters from an operational perspective.
>
> However, we are dealing with brand new code being proposed for Linux
> mainline, and so this is our only chance to push back on this, as
> otherwise, we will have to maintain it for a very long time.
>
> IOW, D-RTM does not exist today in Linux, and it is up to us to define
> what it will look like. From that perspective, it is downright
> preposterous to even consider supporting SHA-1, given that SHA-1 by
> itself gives none of the guarantees that D-RTM aims to provide. If
> reducing your TCB is important enough to warrant switching to this
> implementation of D-RTM, surely you can upgrade your attestation
> policies as well.

You're suggesting that because Linux has been slow to take D-RTM over
the past decade, you're going to intentionally break people with older
hardware just because you don't feel like using an older algorithm?

That's about the worst possible reason to not take support.

There really are people in the world with older TPM 1.2 systems where
this D-RTM using SHA1 only is an improvement over using the incumbent tboot.

~Andrew