[Bug 1197625] grub-tpm.efi split still needed?
https://bugzilla.suse.com/show_bug.cgi?id=1197625 https://bugzilla.suse.com/show_bug.cgi?id=1197625#c6 --- Comment #6 from Michael Chang <mchang@suse.com> --- (In reply to Fabian Vogt from comment #5)
(In reply to Michael Chang from comment #4)
(In reply to Fabian Vogt from comment #3)
(In reply to Michael Chang from comment #1)
[snip]
Having the return code would be very helpful.
In the thread there's the theory that appending the entry to the event log causes it to fail, which sounds likely. According to the spec, it would then return EFI_VOLUME_FULL, which is indeed not handled. This also explains why it only fails on snapshot boots (more commands to measure, which are all copied verbatim into the event log!) and why it gets worse on the second attempt.
In the case of EFI_VOLUME_FULL, the correct behaviour is to log that and continue, as the measurement itself was successful. There's the option to retry with EFI_TCG2_EXTEND_ONLY to skip logging, but in the case of a previous EFI_VOLUME_FULL error that will be returned again (it's sticky!), so there's no point...
If the whole point here is to log the error EFI_VOLUME_FULL and continue execution as is, then it is not new to grub. I think there are other occasions where (non critical) errors are handled this way. The problem is do we have the hardware to verify it ? Should we make such error handling a common thing to all tpm's "unknown errors" ?
I hit something related on my machine (boo#1165773), where the FW claimed to have a TPM event log without the TPM being enabled.
Maybe such state can be reflect in EFI_TCG2_PROTOCOL.GetCapability ? It seems testing tpm presence is not enough.
It should be...
My point is that whenever tpm is disabled, no measurement should be performed hence users will not receive any errors related to tpm, otherwise it is confusing. An enhancement can thus be made if the test can cover both tpm presence and enablement and stop in advance. -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply@suse.com