All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Omar Sandoval <osandov@osandov.com>
Cc: Peter Huewe <peterhuewe@gmx.de>,
	Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
	Jason Gunthorpe <jgg@ziepe.ca>,
	linux-integrity@vger.kernel.org
Subject: Re: [PATCH] tpm_tis: work around status register bug in STMicroelectronics TPM
Date: Thu, 16 Apr 2020 11:02:51 -0700	[thread overview]
Message-ID: <1587060171.15329.7.camel@HansenPartnership.com> (raw)
In-Reply-To: <20200416002442.GB673482@vader>

On Wed, 2020-04-15 at 17:24 -0700, Omar Sandoval wrote:
> On Wed, Apr 15, 2020 at 05:16:05PM -0700, Omar Sandoval wrote:
> > On Wed, Apr 15, 2020 at 04:51:39PM -0700, James Bottomley wrote:
> > > On Wed, 2020-04-15 at 15:45 -0700, Omar Sandoval wrote:
> > > > From: Omar Sandoval <osandov@fb.com>
> > > > 
> > > > We've encountered a particular model of STMicroelectronics TPM
> > > > that transiently returns a bad value in the status register.
> > > > This causes the kernel to believe that the TPM is ready to
> > > > receive a command when it actually isn't, which in turn causes
> > > > the send to time out in get_burstcount(). In testing, reading
> > > > the status register one extra time convinces the TPM to return
> > > > a valid value.
> > > 
> > > Interesting, I've got a very early upgradeable nuvoton that seems
> > > to be behaving like this.
> > 
> > I'll attach the userspace reproducer I used to figure this out. I'd
> > be interested to see if it times out on your TPM, too. Note that it
> > bangs on /dev/mem and assumes that the MMIO address is 0xfed40000.
> > That seems to be the hard-coded address for x86 in the kernel, but
> > just to be safe you might want to check `grep MSFT0101
> > /proc/iomem`.
> 
> Forgot to attach it, of course...


Thanks!  You facebook guys run with interesting kernel options ... I
eventually had to disable CONFIG_STRICT_DEVMEM and rebuild my kernel to
get it to run.

However, the bad news is that this isn't my problem, it seems to be
more timeout related  I get the same symptoms: logs full of

[14570.626594] tpm tpm0: tpm_try_transmit: tpm_send: error -62

and the TPM won't recover until the box is reset.  To get my TPM to be
usable, I have to fiddle our default timeouts like this:

--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -41,8 +41,8 @@ enum tpm_timeout {
        TPM_TIMEOUT_RETRY = 100, /* msecs */
        TPM_TIMEOUT_RANGE_US = 300,     /* usecs */
        TPM_TIMEOUT_POLL = 1,   /* msecs */
-       TPM_TIMEOUT_USECS_MIN = 100,      /* usecs */
-       TPM_TIMEOUT_USECS_MAX = 500      /* usecs */
+       TPM_TIMEOUT_USECS_MIN = 750,      /* usecs */
+       TPM_TIMEOUT_USECS_MAX = 1000,      /* usecs */
 };

But I think the problem is unique to my nuvoton because there haven't
been any other reports of problems like this ... and with these
timeouts my system functions normally in spite of me being a heavy TPM
user.

James


  reply	other threads:[~2020-04-16 18:02 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-15 22:45 [PATCH] tpm_tis: work around status register bug in STMicroelectronics TPM Omar Sandoval
2020-04-15 23:51 ` James Bottomley
2020-04-16  0:16   ` Omar Sandoval
2020-04-16  0:24     ` Omar Sandoval
2020-04-16 18:02       ` James Bottomley [this message]
2020-04-17 23:55         ` Jarkko Sakkinen
2020-04-18  0:12           ` James Bottomley
2020-04-20 20:46             ` Jarkko Sakkinen
2020-04-20 22:28               ` James Bottomley
2020-04-21 14:36                 ` Mimi Zohar
2020-04-21 20:25                   ` Jarkko Sakkinen
2020-04-21 20:31                     ` Mimi Zohar
2020-04-21 20:23                 ` Jarkko Sakkinen
2020-04-21 22:08                   ` James Bottomley
2020-04-16 17:09   ` Jarkko Sakkinen
2020-04-16 17:56     ` James Bottomley
2020-08-27 15:24   ` Jason Andryuk
2020-08-28 23:18     ` Jarkko Sakkinen
2020-08-29  0:12       ` Jason Andryuk
2020-08-31 13:55         ` Jarkko Sakkinen
2020-09-04 12:03         ` Jarkko Sakkinen
2020-04-16 17:08 ` Jarkko Sakkinen
2020-04-16 18:54   ` Omar Sandoval
2020-04-17 23:54     ` Jarkko Sakkinen

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=1587060171.15329.7.camel@HansenPartnership.com \
    --to=james.bottomley@hansenpartnership.com \
    --cc=jarkko.sakkinen@linux.intel.com \
    --cc=jgg@ziepe.ca \
    --cc=linux-integrity@vger.kernel.org \
    --cc=osandov@osandov.com \
    --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.