Re: [PATCH] tpm: fix selftest failure regression

[Jason Gunthorpe <jgg@ziepe.ca>]

On Sun, Feb 18, 2018 at 09:16:42AM -0800, James Bottomley wrote:
> On Sun, 2018-02-18 at 10:08 -0700, Jason Gunthorpe wrote:
> > On Fri, Feb 16, 2018 at 12:15:08PM -0800, James Bottomley wrote:
> > > 
> > > It isn't currently since it uses tpm_transmit directly.  My thought
> > > on this is that if the TPM hasn't got its testing crap together by
> > > the time we enter userspace (which will be 10 or more seconds after
> > > we first sent the test commands), then we really have a problem and
> > > the user should see it.
> > 
> > Why would it be 10s? My embedded systems got to userspace in
> > something like 0.5s after sending the startup.
> 
> The misbehaving chips seem to be laptop, and that's about what it takes
> mine to get through the boot sequence ... and I thought waiting 2s for
> the TPM to self test was a long time for me; it must be an eternity to
> you ...

Yes :) The TPMs I used did not take 2 seconds to self test. Maybe all
the new algorithms in TPM2 make it take much longer?

> > Not sure what to do here.. Our model has been that userspace gets a
> > raw view - but it has also been that the kernel makes the TPM fully
> > ready.
> 
> Well, I could move the wait for testing to finish loop to
> tpm_transmit().  That would cope with both cases.  However, I've never
> actually seen this loop activate, even with all the TPM misbehaviour
> I've managed to induce, so I have no objective measure for whether it's
> useful or not.

That is just a time issue, right? Or does the kernel send no commands
early on that are depending on self test?

Jason