Re: Should we handle TPM_RC_RETRY internally?

[Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>]

On Sat, Mar 17, 2018 at 01:21:08AM +0000, Andrey Pronin wrote:
>    If the TSS starts retrying commands itself, then it's more than just
>    handling TPM_RC_RETRY.
>    There is also even more cryptic TPM_RC_YIELDED, which allows (suggests?)
>    retrying, and TPM_RC_NV_RATE, which covers one of the few legitimate and
>    easily explainable reasons why a command can fail now but succeed later.
>    And what about TPM_RC_MEMORY, TPM_RC_NV_UNAVAILABLE and such?
>    Though quite exotic, they are all warnings, and all indicate a possibly
>    temporary lack of access/resources. Unlike TPM_RC_*_HANDLES, CONTEXT_GAP
>    etc, they don't require RM to do anything with objects and handles to
>    recover, and may succeed if simply retried after a delay.
>    Shall these retries be also handled in tpm_transmit_cmd() or left up to
>    the caller to take care of? And how are they different from TPM_RC_RETRY
>    case, if the latter?
>    If you are interested in the actual in-kernel use of the commands that
>    can face such codes, look no further than tpm2_load_context().
>    The referenceA implementation may return TPM_RC_NV* fromA TPM2_ContextLoad
>    since it callsA NvIsAvailable().
>    --
>    Andrey

Hey, thanks for this feedback. It changed my point of view.

tpm_transmit_cmd() should be able to handle exactly the subset that in-kernel
clients of the TPM need, not more or less.

I do no want TPM_RC_RETRY logic at this point to tpm_transmit() path. We can
consider that later (maybe). It is at least too late to consider it in 4.17
timeline.

/Jarkko