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. Best regards, -- Javier Martinez Canillas Software Engineer - Desktop Hardware Enablement Red Hat _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel