Comment # 7 on bug 1197625 from Fabian Vogt

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