Re: [PATCH] tpm: Pass unknown error as non-fatal, but debug print the error we got

[Javier Martinez Canillas]

Hello Max,

On 10/29/19 11:49 AM, Max Tottenham via Grub-devel wrote:
> On 10/25, Javier Martinez Canillas wrote:

[snip]

>>>
>>
>> I think that we should go even further and make all the TPM measurement
>> errors to be non-fatal. For example something like the following patch [0].
>>
> 
> This poses a slight problem. For folks who rely on TPM sealed values
> this would potentially make the issue harder to address. 
>

I fail to see how making it a non-fatal error would make this harder for users
that rely on TPM sealed values.

If the HashLogExtendEvent failed and the PCR were not extended, then the sealed
values won't be unsealed by the TPM. So it won't be less secure for users while
still allowing the system to boot for users that aren't relying on PCR values.

And even for users that rely on it, I think that halting the boot is too 
extreme.
For example a user could have a LUKS volume key sealed with a TPM but still have
another key slot with a passphrase as fallback in case the PCR measurements 
fail.

Even for the case you mentioned that EFI firmware could return an 
EFI_VOLUME_FULL
meaning that the extend operation occurred but the event could not be written to
the event log, then attestation software that not only check the PCR values but
also the event logs will determine that the logs are not correct and report that
the system is not healthy.

Then you could reboot your machine enabling debug logs for grub and check if the
call to HashLogExtendEvent is failing and what error code is returning to 
address
the issue and troubleshoot.

In other words, preventing the system from booting should be the last option in
my opinion and only for situations where there is really no other choice.

> Maybe a compile time (or install time) option that allows a strictness
> policy to be set - those who don't care about TPM capability can let it
> default to printing warnings, those who rely on keying material sealed
> to TPM state can explicitly configure GRUB to halt the boot process on
> error?
>

Yes, having a compile time or runtime option to choose this could work. But
I'm still not convinced that halting the boot process due a TPM measurement
failure is the correct thing to do.

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