grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] tpm: Don't propagate measurement failures to the verifiers l


From: Javier Martinez Canillas
Subject: Re: [PATCH] tpm: Don't propagate measurement failures to the verifiers layer
Date: Sun, 28 Feb 2021 23:42:48 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0

On 2/28/21 7:25 PM, James Bottomley wrote:
> On Sun, 2021-02-28 at 18:58 +0100, Javier Martinez Canillas wrote:

[snip]

>> I don't see how that would be the case. For anyone doing measured
>> boot, they can check the TPM event log to verify what has been
>> measured during the boot path.
> 
> No, they can't ... that's the point, the log will no longer verify
> because of the failure.  That's why this is a break in the measurement

Yes, my point was that the attestation software can verify if there are
any gaps in the TPM logs due the failure to measure the boot components.

> chain.  If you're requesting verified boot, which is an opt-in by
> inserting the TPM grub module, this is an unrecoverable failure.
>

But it's not really optional, since most distros disable module loading
in GRUB if Secure Boot is enabled. Instead, a curated list of modules
are built-in the signed EFI binary. The tpm module is one of these that
we include in Fedora.

The other option would be to not include the tpm module, but that would
mean that users wanting to do measured boot will have to disable Secure
Boot. And usually people who care about TPM measurements are security
minded people who want to use it in conjunction with Secure Boot.
 
>>  It's up to attestation software to check that and not
>> be enforced by the bootloaders in my opinion.
>>
>> As far as I can tell there is nothing in the TCG specs that mention
>> that a failure to measure should prevent a system to boot.
> 
> The point I'm making are that the specs are somewhat badly written so
> as not to contemplate failure like this.  The reason a UEFI TCG event
> write fails in this case is probably because there is insufficient log
> space (if it were a TPM failure, it would have failed and been disabled
> early in the boot sequence).
> 
> The UEFI BIOS vendor is supposed to ensure enough space in the logs and
> if they don't the problem needs to be reported back to them.
>

I'm not arguing that EFI firmware vendors don't have to get reports about
broken TPM support and fix it. I'm just arguing that uses shouldn't be left
with a system that fails to boot due that.

Since we are logging the errors, users can verify if there were failures
with the TPM measurements and report back any issues that are found.

[snip] 

>> You are looking through the lenses of the people doing trusted boot
>> but what about those who are not? For them, they just updated GRUB
>> and now the machine doesn't boot.
> 
> The verifiers are optional ... if they just updated grub but don't
> intend to do a measured boot, why did they insert the grub tpm verifier
> module?
> 

It's not optional mentioned. By the way, is not only Fedora that uses this
approach but also other distros are carrying similar patches. For example
Ubuntu [0]. Their patch is slightly different in the sense that they don't
propagate any errors the that happens when calling the EFI firmware, while
we don't propagate any errors that happen when measuring, regardless of the
firmware interface.

Anyways, mainline is free to disagree with this approach and not take this
patch. But I don't think that any distro would trade preventing machines to
boot over the possibility of breaking the trusted boot chain.

So in that case, it would just be yet another patch that Fedora, Ubuntu (and
possibly others distros) will have to carry downstream in their packages.

[0]: 
https://git.launchpad.net/~ubuntu-core-dev/grub/+git/ubuntu/commit/?h=ubuntu&id=2460a6e237a

Best regards,
-- 
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat




reply via email to

[Prev in Thread] Current Thread [Next in Thread]