[Top][All Lists]

[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

From: Daniel Kiper
Subject: Re: [PATCH] tpm: Pass unknown error as non-fatal, but debug print the error we got
Date: Wed, 6 Nov 2019 12:37:33 +0100
User-agent: NeoMutt/20170113 (1.7.2)

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


reply via email to

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