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 | mtott...@akamai.com Senior Software Engineer, Server Platform Engineering /(* Akamai Technologies _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel