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 reference implementation may return TPM_RC_NV* from TPM2_ContextLoad > since it calls 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
