Re: [PATCH v3 1/2] tpm: Disable a TPM that stops responding

[Jarkko Sakkinen <jarkko@kernel.org>]

On Fri, Nov 13, 2026 at 02:38:58AM -0800, Breno Leitao wrote:
> A TPM that stops responding fails each command only after the transport
> timeout, and its callers keep sending more: the hwrng thread every 10
> seconds forever, and userspace through /dev/tpmrm0. Each attempt holds
> tpm_mutex for the whole timeout and logs an error:
> 
>   tpm tpm0: invalid TPM_STS.x 0xff, dumping stack for forensics
>   tpm tpm0: tpm_try_transmit: send(): error -62
>   tpm tpm0: tpm_try_transmit: send(): error -62
>   ...
> 
> The core already stops using a TPM it cannot trust: tpm_try_get_ops()
> fails with -EIO once TPM_CHIP_FLAG_DISABLE is set, which
> tpm2_load_null() does when it cannot restore the null key. Set the same
> flag once 60 commands in a row have timed out.
> 
> A completed command, whatever its TPM return code, resets the count.
> Some TPMs stall for half a minute, time out a handful of commands, and
> then recover, so a short streak must not disable them.
> 
> With only the hwrng retrying every 10 seconds, 60 timeouts take more
> than ten minutes. A userspace poller gets there sooner, but each of its
> commands still waits out the transport timeout.
> 
> The limit is the tpm.max_missed_responses boot parameter, so that slow
> pre-production parts, such as FPGA prototypes, can raise it, or set it
> to 0 to never disable the TPM. A disabled TPM stays disabled until the
> driver is rebound or the machine reboots.
> 
> Signed-off-by: Breno Leitao <leitao@debian.org>
> ---
>  Documentation/admin-guide/kernel-parameters.txt |  8 ++++++++
>  drivers/char/tpm/tpm-interface.c                | 14 ++++++++++++++
>  include/linux/tpm.h                             |  1 +
>  3 files changed, 23 insertions(+)
> 
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 1e8317483844d9..cedea8bd468aba 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -7682,6 +7682,14 @@ Kernel parameters
>  			causing a major performance hit, and the space where
>  			machines are deployed is by other means guarded.
>  
> +	tpm.max_missed_responses= [HW,TPM]
> +			Number of commands in a row that may time out before
> +			the TPM is disabled. It stays disabled until the
> +			driver is rebound or the machine reboots. Set to 0
> +			to never disable the TPM.
> +			Format: <unsigned int>
> +			Default: 60
> +
>  	tpm_crb_ffa.busy_timeout_ms= [ARM64,TPM]
>  			Maximum time in milliseconds to retry sending a message
>  			to the TPM service before giving up. This parameter controls
> diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
> index e0385b16616b46..977e205807033d 100644
> --- a/drivers/char/tpm/tpm-interface.c
> +++ b/drivers/char/tpm/tpm-interface.c
> @@ -40,6 +40,11 @@ module_param_named(suspend_pcr, tpm_suspend_pcr, uint, 0644);
>  MODULE_PARM_DESC(suspend_pcr,
>  		 "PCR to use for dummy writes to facilitate flush on suspend.");
>  
> +static unsigned int tpm_max_missed_responses = 60;

This looks good but I started to think this number. I guess it is high
because there's never reset-to-zero for chip->nr_missed_responses.

I think three or four trials at most should be enough, and when there 
is a successful transmission chip->nr_missed_responses should reset.

One thing that bothers me in the commit message is a piece of
information that is missing: when does it start to return error?
From the get go?

I mean based on provided information one could presume that this
could be also fixed at driver init by doing a few smoke tests
and don't let it fully ever initialize.

"A TPM that stops responding fails" is not very locked in scenario.

Br, Jarkko