On Sun, 2021-02-28 at 18:58 +0100, Javier Martinez Canillas wrote: > [re-sending since I got a 'Recipient server unavailable or busy' > error, sorry if someone gets this email twice] > > Hello James, > > On 2/28/21 8:10 AM, James Bottomley wrote: > > 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 > > I don't see how that would be the case. For anyone doing measured > boot, they can check the TPM event log to verify what has been > measured during the boot path.
No, they can't ... that's the point, the log will no longer verify because of the failure. That's why this is a break in the measurement chain. If you're requesting verified boot, which is an opt-in by inserting the TPM grub module, this is an unrecoverable failure. > It's up to attestation software to check that and not > be enforced by the bootloaders in my opinion. > > As far as I can tell there is nothing in the TCG specs that mention > that a failure to measure should prevent a system to boot. The point I'm making are that the specs are somewhat badly written so as not to contemplate failure like this. The reason a UEFI TCG event write fails in this case is probably because there is insufficient log space (if it were a TPM failure, it would have failed and been disabled early in the boot sequence). The UEFI BIOS vendor is supposed to ensure enough space in the logs and if they don't the problem needs to be reported back to them. > For me this is just a by-product of using the verifier framework as a > way to hook the TPM measurements into the file open path. It's not > really a verification, buffers passed aren't validated like with > other verifiers. > > > 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. > > > > You are looking through the lenses of the people doing trusted boot > but what about those who are not? For them, they just updated GRUB > and now the machine doesn't boot. The verifiers are optional ... if they just updated grub but don't intend to do a measured boot, why did they insert the grub tpm verifier module? > They don't care or might even know what a TPM is, they just want to > boot their OS. Then, as I said, why would they insert the TPM grub module? > And in many cases the faulty firmware is from a vendor that doesn't > even provide firmware updates or at least doesn't provide them > through LVFS. > > So now the user (who can't boot their machine) has to report the > issue, wait for a firmware fix and figure out a way to update it. For > my this is not acceptable and quite antisocial for users. Isn't the fix for the user to report the problem either directly or to you for onward transmission to the UEFI vendor and then stop their current boot from inserting the TPM module, which will remove the failing verifier? That is assuming they don't want or are OK not doing measured boot ... if it's a requirement, then I agree they have no choice but to wait for the BIOS to be fixed. James _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
