On Wed, Oct 02, 2024 at 10:31:34AM -0700, James Bottomley wrote: > On Wed, 2024-10-02 at 18:03 +0100, Jonathan McDowell wrote: > [...] > > First, I've seen James' post extending the TPM timeouts back in 2018 > > ( > > https://lore.kernel.org/linux-integrity/1531329074.3260.9.camel@Hansen > > Partnership.com/), which doesn't seem to have been picked up. Was an > > alternative resolution found, or are you still using this, James? > > No, because I've got a newer laptop. The problem was seen on a 2015 > XPS-13 with a Nuvoton TPM that was software upgraded to 2.0 (and had > several other problems because of this). I assumed, based on the lack > of reports from others, that this was a problem specific to my TPM and > so didn't push it. Yes, there's somewhat a lack of reports of TPM issues but I can't tell if that's because people aren't using them in anger, or if they're just not having any issues. This is seen across thousands of machines, so it's not a specific TPM issue. > The annoying thing for me was that the TPM didn't seem to recover. > Once it started giving timeouts it carried on timing out until machine > reset, which really caused problems because all my keys are TPM > resident. > > Is yours a permanent problem like mine, or is it transient (TPM > recovers and comes back)? Ah. So the problem I've described is transient; we get a timeout, that sometimes causes problems (e.g. the transient space leakage I've previously sent a patch for), but ultimately the TPM responds just fine next time. We _do_ have a separate issue where the TPM returns 0xFFFF for STS, the kernel does the "invalid TPM_STS.x" with stack thing, then the TPM never responds to a command again until a machine reboot. However in that instance it _does_ still respond to reading the TPM_DID_VID register, and allowing entering/leaving locality, so that looks like it's firmly a TPM problem of some sort. J. -- /-\ | No thanks, I'm already having one. |@/ Debian GNU/Linux Developer | \- |
