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

[Daniel Kiper]

CC-ing Matthew...

On Tue, Oct 29, 2019 at 01:12:34PM +0100, Javier Martinez Canillas wrote:
> 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.

I full agree with Javier. So, I think that by default GRUB should print
warning about TPM failures and continue booting. Though user should have
a choice during installation to disable that behavior and enforce halt
at boot. Maybe even he/she should be able to choose which kind of errors
(numeric values) he/she is going to ignore if any. Of course we can
suggest in the docs which errors are pretty safe to ignore at boot
phase. Or even we can set a reasonable default in the GRUB config.

Daniel