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
