On Sun, 2021-02-28 at 00:05 +0100, Javier Martinez Canillas wrote: > Currently if an EFI firmware fails to do a TPM measurement for a > file, the error will be propagated to the verifiers framework which > will prevent it to be opened. > > This mean that buggy firmwares will lead to the system not booting > because files won't be allowed to be loaded. But a failure to do a > TPM measurement isn't expected to be a fatal error that causes the > system to be unbootable. > > To avoid this, don't return errors from .write and .verify_string > callbacks and just print a debug message in the case of a TPM > measurement failure.
This does seem somewhat the wrong response. For everyone who is doing measured boot, this will cause a complete break of the verification chain. It looks like this is likely the fault of the bios vendor, so why not push it back to source by failing the boot rather than deferring the problem so it lands on the measured boot implementors. This looks like a simple fault in the UEFI vendor (likely insufficient log space), can't you simply force the motherboard OEM to issue a fix rather than adding a work around to the open source project that first detects it. James _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
