Should we handle TPM_RC_RETRY internally?

[James Bottomley <James.Bottomley@HansenPartnership.com>]

I was investigating an apparent bug in the trusted keys implementation
where periodically the key operation barfs and returns an error to
userspace.  It turns out this error is because the TPM returns
TPM_RC_RETRY to an operation.

The TPM spec is a bit unclear why the TPM would return TPM_RC_RETRY,
but it is clear that it may happen on a lot of operations.  I checked
with the microsoft reference implementation:

https://github.com/Microsoft/ms-tpm-20-ref/

Which implies it's only set if the lockout check is invoked by the
command and the previous TPM shutdown wasn't orderly.  It does seem to
me that I've only seen it involving objects with DA implications, which
explains why it's seen in trusted keys.

If I read the UEFI TPM API, it does automatic retries.  This is the
note:

    The firmware SHALL not return TPM2_RC_RETRY prior to the completion
    of the call to ExitBootServices().

    Implementer's Note: the implementation of this function should check
    the return value in the TPM response and, if it is TPM2_RC_RETRY,
    resend the command. The implementation may abort if a sufficient
    number of retries has been done.

I really think if UEFI does it, we should do it too (and it will fix my
trusted key bug).

What does everyone else think?  If it's agreed, I'll code up the patch.

James