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

[Javier Martinez Canillas]

Hello James,

On 2/28/21 8:10 AM, James Bottomley wrote:
> On Sun, 2021-02-28 at 00:05 +0100, Javier Martinez Canillas wrote:
>> Currently if an EFI firmware fails to do a TPM measurement for a
>> file, the error will be propagated to the verifiers framework which
>> will prevent it to be opened.
>>
>> This mean that buggy firmwares will lead to the system not booting
>> because files won't be allowed to be loaded. But a failure to do a
>> TPM measurement isn't expected to be a fatal error that causes the
>> system to be unbootable.
>>
>> To avoid this, don't return errors from .write and .verify_string
>> callbacks and just print a debug message in the case of a TPM
>> measurement failure.
> 
> This does seem somewhat the wrong response.  For everyone who is doing
> measured boot, this will cause a complete break of the verification
> chain.   It looks like this is likely the fault of the bios vendor, so

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. 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.

For me this is just a by-product of using the verifier framework as a way
to hook the TPM measurements into the file open path. It's not really a
verification, buffers passed aren't validated like with other verifiers.

> why not push it back to source by failing the boot rather than
> deferring the problem so it lands on the measured boot implementors.
> 
> This looks like a simple fault in the UEFI vendor (likely insufficient
> log space), can't you simply force the motherboard OEM to issue a fix
> rather than adding a work around to the open source project that first
> detects it.
>

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. They don't care or might even know what a TPM
is, they just want to boot their OS.

And in many cases the faulty firmware is from a vendor that doesn't even
provide firmware updates or at least doesn't provide them through LVFS.

So now the user (who can't boot their machine) has to report the issue,
wait for a firmware fix and figure out a way to update it. For my this is
not acceptable and quite antisocial for users.
 
> James
> 
> 

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