1. Patchew
  2. linux
  3. View series

[PATCH v3] tpm: tis: Double the timeout B to 4s

Michal Suchanek posted 1 patch 10 months, 1 week ago 
drivers/char/tpm/tpm_tis_core.h | 2 +-
include/linux/tpm.h             | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
[PATCH v3] tpm: tis: Double the timeout B to 4s
Posted by Michal Suchanek 10 months, 1 week ago 
With some Infineon chips the timeouts in tpm_tis_send_data (both B and
C) can reach up to about 2250 ms.

Timeout C is retried since
commit de9e33df7762 ("tpm, tpm_tis: Workaround failed command reception on Infineon devices")

Timeout B still needs to be extended.

The problem is most commonly encountered with context related operation
such as load context/save context. These are issued directly by the
kernel, and there is no retry logic for them.

When a filesystem is set up to use the TPM for unlocking the boot fails,
and restarting the userspace service is ineffective. This is likely
because ignoring a load context/save context result puts the real TPM
state and the TPM state expected by the kernel out of sync.

Chips known to be affected:
tpm_tis IFX1522:00: 2.0 TPM (device-id 0x1D, rev-id 54)
Description: SLB9672
Firmware Revision: 15.22

tpm_tis MSFT0101:00: 2.0 TPM (device-id 0x1B, rev-id 22)
Firmware Revision: 7.83

tpm_tis MSFT0101:00: 2.0 TPM (device-id 0x1A, rev-id 16)
Firmware Revision: 5.63

Link: https://lore.kernel.org/linux-integrity/Z5pI07m0Muapyu9w@kitsune.suse.cz/
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
---
v2: Only extend timeout B
v3: Update commit message
---
 drivers/char/tpm/tpm_tis_core.h | 2 +-
 include/linux/tpm.h             | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/char/tpm/tpm_tis_core.h b/drivers/char/tpm/tpm_tis_core.h
index 970d02c337c7..6c3aa480396b 100644
--- a/drivers/char/tpm/tpm_tis_core.h
+++ b/drivers/char/tpm/tpm_tis_core.h
@@ -54,7 +54,7 @@ enum tis_int_flags {
 enum tis_defaults {
 	TIS_MEM_LEN = 0x5000,
 	TIS_SHORT_TIMEOUT = 750,	/* ms */
-	TIS_LONG_TIMEOUT = 2000,	/* 2 sec */
+	TIS_LONG_TIMEOUT = 4000,	/* 4 secs */
 	TIS_TIMEOUT_MIN_ATML = 14700,	/* usecs */
 	TIS_TIMEOUT_MAX_ATML = 15000,	/* usecs */
 };
diff --git a/include/linux/tpm.h b/include/linux/tpm.h
index 6c3125300c00..3db0b6a87d45 100644
--- a/include/linux/tpm.h
+++ b/include/linux/tpm.h
@@ -224,7 +224,7 @@ enum tpm2_const {
 
 enum tpm2_timeouts {
 	TPM2_TIMEOUT_A          =    750,
-	TPM2_TIMEOUT_B          =   2000,
+	TPM2_TIMEOUT_B          =   4000,
 	TPM2_TIMEOUT_C          =    200,
 	TPM2_TIMEOUT_D          =     30,
 	TPM2_DURATION_SHORT     =     20,
-- 
2.47.1
Re: [PATCH v3] tpm: tis: Double the timeout B to 4s
Posted by Jarkko Sakkinen 10 months, 1 week ago 
On Fri, Apr 04, 2025 at 10:23:14AM +0200, Michal Suchanek wrote:
> With some Infineon chips the timeouts in tpm_tis_send_data (both B and
> C) can reach up to about 2250 ms.
> 
> Timeout C is retried since
> commit de9e33df7762 ("tpm, tpm_tis: Workaround failed command reception on Infineon devices")
> 
> Timeout B still needs to be extended.
> 
> The problem is most commonly encountered with context related operation
> such as load context/save context. These are issued directly by the
> kernel, and there is no retry logic for them.
> 
> When a filesystem is set up to use the TPM for unlocking the boot fails,
> and restarting the userspace service is ineffective. This is likely
> because ignoring a load context/save context result puts the real TPM
> state and the TPM state expected by the kernel out of sync.
> 
> Chips known to be affected:
> tpm_tis IFX1522:00: 2.0 TPM (device-id 0x1D, rev-id 54)
> Description: SLB9672
> Firmware Revision: 15.22
> 
> tpm_tis MSFT0101:00: 2.0 TPM (device-id 0x1B, rev-id 22)
> Firmware Revision: 7.83
> 
> tpm_tis MSFT0101:00: 2.0 TPM (device-id 0x1A, rev-id 16)
> Firmware Revision: 5.63
> 
> Link: https://lore.kernel.org/linux-integrity/Z5pI07m0Muapyu9w@kitsune.suse.cz/
> Signed-off-by: Michal Suchanek <msuchanek@suse.de>
> ---
> v2: Only extend timeout B
> v3: Update commit message
> ---
>  drivers/char/tpm/tpm_tis_core.h | 2 +-
>  include/linux/tpm.h             | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/char/tpm/tpm_tis_core.h b/drivers/char/tpm/tpm_tis_core.h
> index 970d02c337c7..6c3aa480396b 100644
> --- a/drivers/char/tpm/tpm_tis_core.h
> +++ b/drivers/char/tpm/tpm_tis_core.h
> @@ -54,7 +54,7 @@ enum tis_int_flags {
>  enum tis_defaults {
>  	TIS_MEM_LEN = 0x5000,
>  	TIS_SHORT_TIMEOUT = 750,	/* ms */
> -	TIS_LONG_TIMEOUT = 2000,	/* 2 sec */
> +	TIS_LONG_TIMEOUT = 4000,	/* 4 secs */
>  	TIS_TIMEOUT_MIN_ATML = 14700,	/* usecs */
>  	TIS_TIMEOUT_MAX_ATML = 15000,	/* usecs */
>  };
> diff --git a/include/linux/tpm.h b/include/linux/tpm.h
> index 6c3125300c00..3db0b6a87d45 100644
> --- a/include/linux/tpm.h
> +++ b/include/linux/tpm.h
> @@ -224,7 +224,7 @@ enum tpm2_const {
>  
>  enum tpm2_timeouts {
>  	TPM2_TIMEOUT_A          =    750,
> -	TPM2_TIMEOUT_B          =   2000,
> +	TPM2_TIMEOUT_B          =   4000,
>  	TPM2_TIMEOUT_C          =    200,
>  	TPM2_TIMEOUT_D          =     30,
>  	TPM2_DURATION_SHORT     =     20,
> -- 
> 2.47.1
> 
> 

Cc: stable@vger.kernel.org # v6.1+

Probably best that I'll piggyback a patch set for stable with the two
fixes, in order to cause least noise. I need to do this *after* an
ack'd PR to -rc2.

Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>

BR, Jarkko
Re: [PATCH v3] tpm: tis: Double the timeout B to 4s
Posted by Michal Suchánek 8 months, 4 weeks ago 
Hello,

On Fri, Apr 04, 2025 at 11:53:00AM +0300, Jarkko Sakkinen wrote:
> On Fri, Apr 04, 2025 at 10:23:14AM +0200, Michal Suchanek wrote:
> > With some Infineon chips the timeouts in tpm_tis_send_data (both B and
> > C) can reach up to about 2250 ms.
> > 
> > Timeout C is retried since
> > commit de9e33df7762 ("tpm, tpm_tis: Workaround failed command reception on Infineon devices")
> > 
> > Timeout B still needs to be extended.
> > 
> > The problem is most commonly encountered with context related operation
> > such as load context/save context. These are issued directly by the
> > kernel, and there is no retry logic for them.
> > 
> > When a filesystem is set up to use the TPM for unlocking the boot fails,
> > and restarting the userspace service is ineffective. This is likely
> > because ignoring a load context/save context result puts the real TPM
> > state and the TPM state expected by the kernel out of sync.
> > 
> > Chips known to be affected:
> > tpm_tis IFX1522:00: 2.0 TPM (device-id 0x1D, rev-id 54)
> > Description: SLB9672
> > Firmware Revision: 15.22
> > 
> > tpm_tis MSFT0101:00: 2.0 TPM (device-id 0x1B, rev-id 22)
> > Firmware Revision: 7.83
> > 
> > tpm_tis MSFT0101:00: 2.0 TPM (device-id 0x1A, rev-id 16)
> > Firmware Revision: 5.63
> > 
> > Link: https://lore.kernel.org/linux-integrity/Z5pI07m0Muapyu9w@kitsune.suse.cz/
> > Signed-off-by: Michal Suchanek <msuchanek@suse.de>
> > ---
> > v2: Only extend timeout B
> > v3: Update commit message
> > ---
> >  drivers/char/tpm/tpm_tis_core.h | 2 +-
> >  include/linux/tpm.h             | 2 +-
> >  2 files changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/char/tpm/tpm_tis_core.h b/drivers/char/tpm/tpm_tis_core.h
> > index 970d02c337c7..6c3aa480396b 100644
> > --- a/drivers/char/tpm/tpm_tis_core.h
> > +++ b/drivers/char/tpm/tpm_tis_core.h
> > @@ -54,7 +54,7 @@ enum tis_int_flags {
> >  enum tis_defaults {
> >  	TIS_MEM_LEN = 0x5000,
> >  	TIS_SHORT_TIMEOUT = 750,	/* ms */
> > -	TIS_LONG_TIMEOUT = 2000,	/* 2 sec */
> > +	TIS_LONG_TIMEOUT = 4000,	/* 4 secs */
> >  	TIS_TIMEOUT_MIN_ATML = 14700,	/* usecs */
> >  	TIS_TIMEOUT_MAX_ATML = 15000,	/* usecs */
> >  };
> > diff --git a/include/linux/tpm.h b/include/linux/tpm.h
> > index 6c3125300c00..3db0b6a87d45 100644
> > --- a/include/linux/tpm.h
> > +++ b/include/linux/tpm.h
> > @@ -224,7 +224,7 @@ enum tpm2_const {
> >  
> >  enum tpm2_timeouts {
> >  	TPM2_TIMEOUT_A          =    750,
> > -	TPM2_TIMEOUT_B          =   2000,
> > +	TPM2_TIMEOUT_B          =   4000,
> >  	TPM2_TIMEOUT_C          =    200,
> >  	TPM2_TIMEOUT_D          =     30,
> >  	TPM2_DURATION_SHORT     =     20,
> > -- 
> > 2.47.1
> > 
> > 
> 
> Cc: stable@vger.kernel.org # v6.1+
> 
> Probably best that I'll piggyback a patch set for stable with the two
> fixes, in order to cause least noise. I need to do this *after* an
> ack'd PR to -rc2.

While there is talk about stable this does not seem to be applied
anywhere I could find. Is that expected?

Thanks

Michal

> 
> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
> 
> BR, Jarkko
Re: [PATCH v3] tpm: tis: Double the timeout B to 4s
Posted by Jarkko Sakkinen 8 months, 4 weeks ago 
On Wed, May 14, 2025 at 02:10:45PM +0200, Michal Suchánek wrote:
> Hello,
> 
> On Fri, Apr 04, 2025 at 11:53:00AM +0300, Jarkko Sakkinen wrote:
> > On Fri, Apr 04, 2025 at 10:23:14AM +0200, Michal Suchanek wrote:
> > > With some Infineon chips the timeouts in tpm_tis_send_data (both B and
> > > C) can reach up to about 2250 ms.
> > > 
> > > Timeout C is retried since
> > > commit de9e33df7762 ("tpm, tpm_tis: Workaround failed command reception on Infineon devices")
> > > 
> > > Timeout B still needs to be extended.
> > > 
> > > The problem is most commonly encountered with context related operation
> > > such as load context/save context. These are issued directly by the
> > > kernel, and there is no retry logic for them.
> > > 
> > > When a filesystem is set up to use the TPM for unlocking the boot fails,
> > > and restarting the userspace service is ineffective. This is likely
> > > because ignoring a load context/save context result puts the real TPM
> > > state and the TPM state expected by the kernel out of sync.
> > > 
> > > Chips known to be affected:
> > > tpm_tis IFX1522:00: 2.0 TPM (device-id 0x1D, rev-id 54)
> > > Description: SLB9672
> > > Firmware Revision: 15.22
> > > 
> > > tpm_tis MSFT0101:00: 2.0 TPM (device-id 0x1B, rev-id 22)
> > > Firmware Revision: 7.83
> > > 
> > > tpm_tis MSFT0101:00: 2.0 TPM (device-id 0x1A, rev-id 16)
> > > Firmware Revision: 5.63
> > > 
> > > Link: https://lore.kernel.org/linux-integrity/Z5pI07m0Muapyu9w@kitsune.suse.cz/
> > > Signed-off-by: Michal Suchanek <msuchanek@suse.de>
> > > ---
> > > v2: Only extend timeout B
> > > v3: Update commit message
> > > ---
> > >  drivers/char/tpm/tpm_tis_core.h | 2 +-
> > >  include/linux/tpm.h             | 2 +-
> > >  2 files changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/char/tpm/tpm_tis_core.h b/drivers/char/tpm/tpm_tis_core.h
> > > index 970d02c337c7..6c3aa480396b 100644
> > > --- a/drivers/char/tpm/tpm_tis_core.h
> > > +++ b/drivers/char/tpm/tpm_tis_core.h
> > > @@ -54,7 +54,7 @@ enum tis_int_flags {
> > >  enum tis_defaults {
> > >  	TIS_MEM_LEN = 0x5000,
> > >  	TIS_SHORT_TIMEOUT = 750,	/* ms */
> > > -	TIS_LONG_TIMEOUT = 2000,	/* 2 sec */
> > > +	TIS_LONG_TIMEOUT = 4000,	/* 4 secs */
> > >  	TIS_TIMEOUT_MIN_ATML = 14700,	/* usecs */
> > >  	TIS_TIMEOUT_MAX_ATML = 15000,	/* usecs */
> > >  };
> > > diff --git a/include/linux/tpm.h b/include/linux/tpm.h
> > > index 6c3125300c00..3db0b6a87d45 100644
> > > --- a/include/linux/tpm.h
> > > +++ b/include/linux/tpm.h
> > > @@ -224,7 +224,7 @@ enum tpm2_const {
> > >  
> > >  enum tpm2_timeouts {
> > >  	TPM2_TIMEOUT_A          =    750,
> > > -	TPM2_TIMEOUT_B          =   2000,
> > > +	TPM2_TIMEOUT_B          =   4000,
> > >  	TPM2_TIMEOUT_C          =    200,
> > >  	TPM2_TIMEOUT_D          =     30,
> > >  	TPM2_DURATION_SHORT     =     20,
> > > -- 
> > > 2.47.1
> > > 
> > > 
> > 
> > Cc: stable@vger.kernel.org # v6.1+
> > 
> > Probably best that I'll piggyback a patch set for stable with the two
> > fixes, in order to cause least noise. I need to do this *after* an
> > ack'd PR to -rc2.
> 
> While there is talk about stable this does not seem to be applied
> anywhere I could find. Is that expected?

Definitely not. I got shifted away with other work early April and
this was left to my TODO folder, apologies.

Sasha, can you also auto-select this to v6.1+? It is in my next
branch now (should be soon'ish mirrored to linux-next).

BR, Jarkko
Re: [PATCH v3] tpm: tis: Double the timeout B to 4s
Posted by Jarkko Sakkinen 8 months, 4 weeks ago 
On Thu, May 15, 2025 at 04:41:52AM +0300, Jarkko Sakkinen wrote:
> On Wed, May 14, 2025 at 02:10:45PM +0200, Michal Suchánek wrote:
> > Hello,
> > 
> > On Fri, Apr 04, 2025 at 11:53:00AM +0300, Jarkko Sakkinen wrote:
> > > On Fri, Apr 04, 2025 at 10:23:14AM +0200, Michal Suchanek wrote:
> > > > With some Infineon chips the timeouts in tpm_tis_send_data (both B and
> > > > C) can reach up to about 2250 ms.
> > > > 
> > > > Timeout C is retried since
> > > > commit de9e33df7762 ("tpm, tpm_tis: Workaround failed command reception on Infineon devices")
> > > > 
> > > > Timeout B still needs to be extended.
> > > > 
> > > > The problem is most commonly encountered with context related operation
> > > > such as load context/save context. These are issued directly by the
> > > > kernel, and there is no retry logic for them.
> > > > 
> > > > When a filesystem is set up to use the TPM for unlocking the boot fails,
> > > > and restarting the userspace service is ineffective. This is likely
> > > > because ignoring a load context/save context result puts the real TPM
> > > > state and the TPM state expected by the kernel out of sync.
> > > > 
> > > > Chips known to be affected:
> > > > tpm_tis IFX1522:00: 2.0 TPM (device-id 0x1D, rev-id 54)
> > > > Description: SLB9672
> > > > Firmware Revision: 15.22
> > > > 
> > > > tpm_tis MSFT0101:00: 2.0 TPM (device-id 0x1B, rev-id 22)
> > > > Firmware Revision: 7.83
> > > > 
> > > > tpm_tis MSFT0101:00: 2.0 TPM (device-id 0x1A, rev-id 16)
> > > > Firmware Revision: 5.63
> > > > 
> > > > Link: https://lore.kernel.org/linux-integrity/Z5pI07m0Muapyu9w@kitsune.suse.cz/
> > > > Signed-off-by: Michal Suchanek <msuchanek@suse.de>
> > > > ---
> > > > v2: Only extend timeout B
> > > > v3: Update commit message
> > > > ---
> > > >  drivers/char/tpm/tpm_tis_core.h | 2 +-
> > > >  include/linux/tpm.h             | 2 +-
> > > >  2 files changed, 2 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/char/tpm/tpm_tis_core.h b/drivers/char/tpm/tpm_tis_core.h
> > > > index 970d02c337c7..6c3aa480396b 100644
> > > > --- a/drivers/char/tpm/tpm_tis_core.h
> > > > +++ b/drivers/char/tpm/tpm_tis_core.h
> > > > @@ -54,7 +54,7 @@ enum tis_int_flags {
> > > >  enum tis_defaults {
> > > >  	TIS_MEM_LEN = 0x5000,
> > > >  	TIS_SHORT_TIMEOUT = 750,	/* ms */
> > > > -	TIS_LONG_TIMEOUT = 2000,	/* 2 sec */
> > > > +	TIS_LONG_TIMEOUT = 4000,	/* 4 secs */
> > > >  	TIS_TIMEOUT_MIN_ATML = 14700,	/* usecs */
> > > >  	TIS_TIMEOUT_MAX_ATML = 15000,	/* usecs */
> > > >  };
> > > > diff --git a/include/linux/tpm.h b/include/linux/tpm.h
> > > > index 6c3125300c00..3db0b6a87d45 100644
> > > > --- a/include/linux/tpm.h
> > > > +++ b/include/linux/tpm.h
> > > > @@ -224,7 +224,7 @@ enum tpm2_const {
> > > >  
> > > >  enum tpm2_timeouts {
> > > >  	TPM2_TIMEOUT_A          =    750,
> > > > -	TPM2_TIMEOUT_B          =   2000,
> > > > +	TPM2_TIMEOUT_B          =   4000,
> > > >  	TPM2_TIMEOUT_C          =    200,
> > > >  	TPM2_TIMEOUT_D          =     30,
> > > >  	TPM2_DURATION_SHORT     =     20,
> > > > -- 
> > > > 2.47.1
> > > > 
> > > > 
> > > 
> > > Cc: stable@vger.kernel.org # v6.1+
> > > 
> > > Probably best that I'll piggyback a patch set for stable with the two
> > > fixes, in order to cause least noise. I need to do this *after* an
> > > ack'd PR to -rc2.
> > 
> > While there is talk about stable this does not seem to be applied
> > anywhere I could find. Is that expected?
> 
> Definitely not. I got shifted away with other work early April and
> this was left to my TODO folder, apologies.
> 
> Sasha, can you also auto-select this to v6.1+? It is in my next
> branch now (should be soon'ish mirrored to linux-next).

I got shifted away at work for a while and since it has been a while,
and the thread is a bit messy, can you check if there was still
something else I ought to pick up:

https://lore.kernel.org/linux-integrity/D9WD3016M557.1ZXO3GLKGUIIF@kernel.org/

Now "tpm: tis: Double the timeout B to 4s" has a legit commit ID at
least, and will land to 6.15.

BR, Jarkko

Patchew 2.1-devel-b67e4c2

© 2016 - 2026 Red Hat, Inc.