All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan McDowell <noodles@earth.li>
To: James Bottomley <James.Bottomley@hansenpartnership.com>
Cc: linux-integrity@vger.kernel.org,
	Jarkko Sakkinen <jarkko@kernel.org>,
	Peter Huewe <peterhuewe@gmx.de>, Jason Gunthorpe <jgg@ziepe.ca>,
	linux-kernel@vger.kernel.org
Subject: Re: Problems with TPM timeouts
Date: Wed, 2 Oct 2024 20:26:44 +0100	[thread overview]
Message-ID: <Zv2edMT2TyGsIiFJ@earth.li> (raw)
In-Reply-To: <a9b94fad8f0d8023ce2459fa11494ff8e83d0b65.camel@HansenPartnership.com>

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 |
\-                              |

      reply	other threads:[~2024-10-02 19:26 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-02 17:03 Problems with TPM timeouts Jonathan McDowell
2024-10-02 17:04 ` [RFC PATCH] tpm: Workaround failed command reception on Infineon devices Jonathan McDowell
2024-10-03 21:59   ` Stefan Berger
2024-10-03 22:25     ` Stefan Berger
2024-10-04 14:47       ` Jonathan McDowell
2024-10-02 17:31 ` Problems with TPM timeouts James Bottomley
2024-10-02 19:26   ` Jonathan McDowell [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Zv2edMT2TyGsIiFJ@earth.li \
    --to=noodles@earth.li \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=jarkko@kernel.org \
    --cc=jgg@ziepe.ca \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterhuewe@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.