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 _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
