Re: [PATCH v2 1/2] tpm: Add support for updating TPM2 durations

[Jarkko Sakkinen]

On Sat, Oct 17, 2026 at 03:12:10AM +0300, Jarkko Sakkinen wrote:
> On Fri, Oct 16, 2026 at 04:37:32AM +0000, Surendran Kanagaraj wrote:
> > TPM commands need to complete within the command duration defined
> > in the TPM2 spec or keep answering TPM2_RC_RETRY for at most
> > TPM2_DURATION_LONG (2s).
> > 
> > Devices that have different timeout requirements than the TPM2 spec
> > could exhaust the retry budget or exceed the command duration. These
> > failures disable the device during an auth session, failing all
> > subsequent TPM requests. Worse, when a TPM2_CC_FLUSH_CONTEXT command
> > fails, it leaks the TPM's transient memory:
> > 
> >     tpm tpm0: in retry loop
> >     tpm tpm0: tpm2_load_context: failed with a TPM error 0x0922
> >     ...
> >     tpm tpm0: A TPM error (2338) occurred flushing context
> > 
> > Fix this by overriding the command durations and retry budget
> > based on chip->duration and letting the driver modify the durations
> > during tpm2_get_timeouts() as TPM 1.x does. Chips without
> > the override keep the current durations.
> > 
> > Tested in QEMU with swtpm on tpm_crb, tpm_tis, tpm_tis_i2c, tpm_ibmvtpm
> > and tpm_vtpm_proxy.
> > 
> > Assisted-by: LLM
> > Signed-off-by: Surendran Kanagaraj <surenkj@xxxxxxxxxx>
> > ---
> > V1 -> V2:
> > - Drop chip->busy_timeout_ms. TPM2 durations and the TPM2_RC_RETRY
> >   budget now come from chip->duration, which drivers adjust through
> >   ->update_durations() as TPM 1.x does.
> > - Map TPM2_CC_SELF_TEST and TPM2_CC_VERIFY_SIGNATURE to TPM_LONG with
> >   floors of 3s and 30s since their durations do not fit SHORT, MEDIUM,
> >   LONG durations.
> > - Keep the TPM2 defaults for commands sent before tpm2_get_timeouts()
> >   has run such as the one in tpm2_probe() and keep the 2s retry
> >   budget for TPM 1.x chips.
> > - Keep the first TPM2_RC_RETRY wait at TPM2_DURATION_SHORT instead of
> >   chip->duration[TPM_SHORT].
> > - Return early from tpm_tis_update_durations() for TPM2 chips, since
> >   its overrides are for TPM 1.x.
> > - Rename from "tpm: Add per-chip timeout for transient unavailability".
> > 
> > v1: https://lore.kernel.org/linux-integrity/20260923142834.16786-2-surenkj@xxxxxxxxxx/
> 
> While the issue does get addressed the patch also makes the code
> base worse. What would be more feasible would be to address the
> architectural issue.
> 
> We absolutely do not want a new special to tpm_transmit().

I.e. unifying and adding coherency would be what I would emphasize
here not shortcircuiting the actual issues and adding special
conditions.

I think this change is optimizing for being non-distruptive as an
optimal goals e.g., by not reconsidering TPM ops etc. and like
the bird eye picture. I think this would be a good chance to
do something much more long term than this.

This is BTW something to look up for with LLM generated changes: LLMs
often optimize towards a bug fix type of minimum side-effect change. It
is probably good to make this type of reflection when pre-checking any
feature patch. I'm not complaining, this isjust something that I just
realized. Just another way to look up whether LLM generated result is
"good" or "bad" because it is very easy to get a blind eye for this.

Br, Jarkko