https://bugzilla.suse.com/show_bug.cgi?id=1197625 https://bugzilla.suse.com/show_bug.cgi?id=1197625#c7 --- Comment #7 from Fabian Vogt <fvogt@suse.com> --- (In reply to Michael Chang from comment #6)

(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 ?

The original reporter might be available or if nobody is available for testing we could add the patch and wait for someone to complain...

Should we make such error handling a common thing to all tpm's "unknown errors" ?

No, that's potentially a security issue.

...

...

...

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.

Yes, that should already be the case. If even with disabled TPM the protocol returns that it's present, that's a FW bug we can't do anything about. -- You are receiving this mail because: You are on the CC list for the bug.