On Fri, 2018-02-09 at 12:02 +0200, Jarkko Sakkinen wrote: > On Thu, Feb 08, 2018 at 09:02:00AM -0800, James Bottomley wrote: > > > > There is an identified regression: the TPM driver will now > > periodically > > fail to attach. However, there's no point reviewing until we agree > > what the fix is. I was just waiting to verify this fixed my > > problem > > (which means seeing the messages it spits out proving the TPM has > > remained in self test). I have now seen this and the driver still > > works, so I can submit a formal patch. > > For the self-test the duration falls down to 2 seconds as the specs > do > not contain any well-defined duration for it, or at least I haven't > found it. > > I see three alternative ways the fix the self-test: > > 1. Execute self-test with fullTest = YES. > 2. Have a flag TPM_CHIP_TESTING that is set when the self-test is > started. Issue a warning on time-out. Check for this flag in > tpm_transmit_cmd() and tpm_write() and resend self-test command > if the flag is stil test before the actual command. Return -EBUSY > and print a warning if self-test is still active. > 3. Increase the duration to the "correct" value if we have one. Actually, I disagree. The first principle we got out of the discussion was don't re-send the selftest command if the TPM says it's still running self tests, so we definitely need only to send it once. I think if the TPM returns returns RC_TESTING we continue on booting and let it run selftest in the background. We don't need a flag because it will return RC_TESTING to any command that tries to exercise a system under test. So all we need to do is look for that return, pause and retry up to a timeout. If you look at the patch I submitted: https://marc.info/?l=linux-integrity&m=151812288917753 That's pretty much what it does. I really think adding more delay to boot up to try and determine when the selftests "finish" is the wrong way to do this given that data from the XPS-13 confirms this is somewhere above 2s, which is already a huge boot wait. James
