Comment # 6 on bug 1197625 from Michael Chang

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