On 02/17/2018 12:00 AM, Alexander Steffen wrote:
On 15.02.2018 16:13, Mimi Zohar wrote:
On Thu, 2018-02-15 at 14:12 +0200, Jarkko Sakkinen wrote:
On Fri, Feb 09, 2018 at 12:47:10PM +0100, Alexander Steffen wrote:
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.
The first was accepted.
The 2nd wasn't accpeted mainly for reasons that for me only acceptable
dependency is:
1. Patch that is part of the same patch set.
2. A merged commit.
I didn't event look at the code for the second one at that point
because
it was formally done wrong.
What it is doing would be acceptable for me. I still think that TPM
should be fully tested before letting IMA for example to use it.
Why? The short selftest has worked fine up to now. The full selftest
delays the TPM way too long and causes IMA to go into TPM-bypass mode.
The faster the TPM is available, the better for IMA.
I assume that IMA can deal with the TPM not returning RC_SUCCESS for a
command, right? Then, if speed is the goal, not explicitly triggering
any selftests and instead letting the TPM handle them internally still
seems like the best solution. If the user needs a fully tested TPM for
some reason, he can trigger the selftests himself. But the kernel
cannot at the same time guarantee that all selftests pass (especially
on broken/slow devices that take forever to complete them) and make
the TPM available as early as possible.
I think we had a similar example elsewhere already: The kernel does
not check all SMART results before accessing the hard disk, why should
it do that for the TPM?
It seems all commands, except selftest, the code sleeps in a loop and
checks for the command to finish, but doesn't resend the command.
Only for selftest is the command resent, instead of just waiting for
it to complete. Is there any reason for this?
The selftest command is special in that the vendor can choose to have
it execute its actions synchronously (like all other commands) or
asynchronously (that is, return immediately and schedule the actions
in the background). Only in the asynchronous case is the command
repeated, as a simple way of querying the result. Since we call the
command with fullTest=NO, only missing selftests are scheduled and
with each iteration there should be fewer and fewer tests left to be
executed, similar to how RC_YIELDED works.
To query for the result, it need not send self test command again, I
think we can use TPM2_GetTestResult().
According to Spec, TPM Rev 2.0 Part 3 - Commands , Section 10.4, the
command will return the following possible test results.
TPM_RC_NEEDS_TEST - SelfTest has not been executed.
TPM_RC_TESTING - Tests are still in progress
TPM_RC_FAILURE - Tests Failure.
TPM_RC_SUCCESS - Tests successfully completed.
Thanks & Regards,
- Nayna
Alexander
