From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Cc: Hao Wu <hao.wu@rubrik.com>,
peterhuewe@gmx.de, jgg@ziepe.ca, arnd@arndb.de,
gregkh@linuxfoundation.org, Hamza Attak <hamza@hpe.com>,
nayna@linux.vnet.ibm.com, why2jjj.linux@gmail.com,
zohar@linux.vnet.ibm.com, linux-integrity@vger.kernel.org,
Paul Menzel <pmenzel@molgen.mpg.de>,
Ken Goldman <kgold@linux.ibm.com>,
Seungyeop Han <seungyeop.han@rubrik.com>,
Shrihari Kalkar <shrihari.kalkar@rubrik.com>,
Anish Jhaveri <anish.jhaveri@rubrik.com>
Subject: Re: [PATCH] Fix Atmel TPM crash caused by too frequent queries
Date: Wed, 30 Sep 2020 07:54:58 -0700 [thread overview]
Message-ID: <a97706be196e2e02ca815b3011d3731684905737.camel@HansenPartnership.com> (raw)
In-Reply-To: <20200930021637.GF808399@linux.intel.com>
On Wed, 2020-09-30 at 05:16 +0300, Jarkko Sakkinen wrote:
> On Mon, Sep 28, 2020 at 03:11:39PM -0700, James Bottomley wrote:
> > On Sun, 2020-09-27 at 22:59 -0700, Hao Wu wrote:
> > [...]
> > > > However, there is another possibility: it's something to do
> > > > with the byte read; I notice you don't require the same
> > > > slowdown for the burst count read, which actually reads the
> > > > status register and burst count as a read32. If that really is
> > > > the case, for the atmel would substituting a read32 and just
> > > > throwing the upper bytes away in tpm_tis_status() allow us to
> > > > keep the current timings? I can actually try doing this and
> > > > see if it fixes my nuvoton.
> > >
> > > If would be helpful if you can find the solution without reducing
> > > performance. I think it is a separate problem to address though.
> > > Maybe not worth to mix them in the same fix.
> >
> > Well, if it works, no other fix is needed.
> >
> > This is what I'm currently trying out on my nuvoton with the
> > timings reverted to being those in the vanilla kernel. So far it
> > hasn't crashed, but I haven't run it for long enough to be sure
> > yet.
> >
> > James
>
> OK, so the bus does not like one byte reads but prefers full (32-bit)
> word reads? I.e. what's the context?
It's not supported by anything in the spec just empirical observation.
However, the spec says the status register is 24 bits: the upper 16
being the burst count. When we read the whole status register,
including the burst count, we do a read32. I observed that the
elongated timing was only added for the read8 code not the read32 which
supports the theory that the former causes the Atmel to crash but the
latter doesn't. Of course it's always possible that probabilistically
the Atmel is going to crash on the burst count read, but that's
exercised far less than the status only read.
James
next prev parent reply other threads:[~2020-09-30 14:55 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-26 22:31 [PATCH] Fix Atmel TPM crash caused by too frequent queries Hao Wu
2020-09-26 22:57 ` James Bottomley
2020-09-26 23:10 ` Hao Wu
2020-09-27 18:25 ` James Bottomley
2020-09-28 0:11 ` Hao Wu
2020-09-28 0:15 ` Hao Wu
2020-09-28 1:22 ` James Bottomley
2020-09-28 5:59 ` Hao Wu
2020-09-28 22:11 ` James Bottomley
2020-09-29 4:46 ` Hao Wu
2020-09-30 2:16 ` Jarkko Sakkinen
2020-09-30 14:54 ` James Bottomley [this message]
2020-09-30 15:37 ` Jarkko Sakkinen
2020-09-30 20:48 ` James Bottomley
2020-09-30 21:09 ` Jarkko Sakkinen
2020-09-30 22:31 ` James Bottomley
2020-10-01 1:50 ` Jarkko Sakkinen
2020-10-01 4:53 ` James Bottomley
2020-10-01 18:15 ` Nayna
2020-10-01 18:32 ` James Bottomley
2020-10-01 23:04 ` Jarkko Sakkinen
2020-10-17 6:11 ` Hao Wu
2020-10-18 5:09 ` Jarkko Sakkinen
2020-10-18 5:20 ` Hao Wu
2020-11-14 4:39 ` Hao Wu
2020-11-18 21:11 ` Jarkko Sakkinen
2020-11-18 23:23 ` Hao Wu
2021-05-09 6:18 ` Hao Wu
2021-05-09 6:31 ` Hao Wu
2021-05-10 2:17 ` Mimi Zohar
2021-05-10 3:15 ` Hao Wu
2021-05-10 17:28 ` Jarkko Sakkinen
2020-09-28 1:08 ` Jarkko Sakkinen
2020-09-28 6:03 ` Hao Wu
2020-09-28 14:16 ` Jarkko Sakkinen
2020-09-28 17:49 ` Hao Wu
2020-09-28 19:47 ` Jarkko Sakkinen
2020-09-28 20:27 ` Hao Wu
2020-09-30 2:11 ` Jarkko Sakkinen
2020-09-30 3:41 ` Hao Wu
[not found] ` <EA1EE8F8-F054-4E1B-B830-231398D33CB8@rubrik.com>
2020-10-01 14:16 ` Mimi Zohar
-- strict thread matches above, loose matches on Subject: below --
2021-06-20 23:18 Hao Wu
2021-06-23 13:35 ` Jarkko Sakkinen
2021-06-24 5:49 ` Hao Wu
2021-06-29 20:06 ` Jarkko Sakkinen
2021-06-30 4:27 ` Hao Wu
2021-06-24 5:33 ` Hao Wu
2021-06-29 20:07 ` Jarkko Sakkinen
2020-09-14 6:13 Hao Wu
2020-09-14 6:17 ` Greg KH
2020-09-15 2:52 ` Hao Wu
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=a97706be196e2e02ca815b3011d3731684905737.camel@HansenPartnership.com \
--to=james.bottomley@hansenpartnership.com \
--cc=anish.jhaveri@rubrik.com \
--cc=arnd@arndb.de \
--cc=gregkh@linuxfoundation.org \
--cc=hamza@hpe.com \
--cc=hao.wu@rubrik.com \
--cc=jarkko.sakkinen@linux.intel.com \
--cc=jgg@ziepe.ca \
--cc=kgold@linux.ibm.com \
--cc=linux-integrity@vger.kernel.org \
--cc=nayna@linux.vnet.ibm.com \
--cc=peterhuewe@gmx.de \
--cc=pmenzel@molgen.mpg.de \
--cc=seungyeop.han@rubrik.com \
--cc=shrihari.kalkar@rubrik.com \
--cc=why2jjj.linux@gmail.com \
--cc=zohar@linux.vnet.ibm.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).