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

[Max Tottenham]

On 11/06, Daniel Kiper wrote:
> 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

I think that makes sense, I think it's correct to assume that in the
general case this should not prevent the system from booting. 

As long as there is some sort of compile time ./configure option that
would allow halting behavior (which by default is disabled). It can be
tricky to read the error messages as they flash by before you get stuck
at a later prompt.


-- 
Max Tottenham       | address@hidden
Senior Software Engineer, Server Platform Engineering
/(* Akamai Technologies