| Message ID | 20250404082325.13876-1-msuchanek@suse.de (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | [v3] tpm: tis: Double the timeout B to 4s | expand |
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
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,
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(-)