[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] tpm: Pass unknown error as non-fatal, but debug print the er
Javier Martinez Canillas
Re: [PATCH] tpm: Pass unknown error as non-fatal, but debug print the error we got
Tue, 29 Oct 2019 13:12:34 +0100
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.0
On 10/29/19 11:49 AM, Max Tottenham via Grub-devel wrote:
> On 10/25, Javier Martinez Canillas wrote:
>> 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 .
> 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
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
Even for the case you mentioned that EFI firmware could return an
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
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
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.
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement