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. Please take into account that the TPM must complete initialization BEFORE IMA looks for the TPM, otherwise IMA goes into TPM-bypass mode. This consistently happens with a full self-test (option 1). Increasing the wait duration will most likely cause this to happen as well (option 2). Based on James' patch description, which says "There are various theories that resending the self-test command actually causes the tests to restart and thus triggers more TPM_RC_TESTING returns until the timeout is exceeded", I think IMA's detecting the TPM, by doing a PCR read, will cause the self-test to restart (option 2). Reverting the patch that enabled the TPM full self-test, or commenting out self-test completely, allows IMA to properly find the TPM. Side note, if the kernel emits TPM initialization warnings, there should be a successfully completed message as well. Mimi
