Re: [PATCH] Fix Atmel TPM crash caused by too frequent queries

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 13:48:15 -0700	[thread overview]
Message-ID: <95aafaa1e3037cb7b99ae0e76c02a419d366a407.camel@HansenPartnership.com> (raw)
In-Reply-To: <20200930153715.GC52739@linux.intel.com>

On Wed, 2020-09-30 at 18:37 +0300, Jarkko Sakkinen wrote:
> On Wed, Sep 30, 2020 at 07:54:58AM -0700, James Bottomley wrote:
> > 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.
> 
> This paragraph is good enough explanation for me. Can you include it
> to the final commit as soon as we hear how your fix works for Hao?

Sure.  I'm afraid I have to report that it didn't work for me.  My
Nuvoton is definitely annoyed by the frequency of the prodding rather
than the register width.

James