On 09.02.2018 11:02, 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.
I had proposed some fixes in this direction last year:
https://patchwork.kernel.org/patch/10105483/
https://patchwork.kernel.org/patch/10130535/
Those combine the fast test execution with fullTest = NO for
spec-compliant TPMs with a fallback to 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.
What about option #4? Just not calling TPM2_SelfTest at all.
I had already proposed that solution in
https://www.spinics.net/lists/linux-integrity/msg01007.html, but did not
get much feedback. According to the specification, that won't lose any
test coverage ("If a command requires use of an untested algorithm or
functional module, the TPM performs the test and then completes the
command actions."
(https://trustedcomputinggroup.org/wp-content/uploads/TPM-Rev-2.0-Part-1-Architecture-01.38.pdf
chapter 12.3, page 83/59).) and will definitely be the best option in
terms of performance and complexity of the driver code.
Alexander
