Greetings,
the new version of tpm_tis.c in Linux 3.4 is calling TPM_ContinueSelfTest
in the probe function. I have a few questions.
1. why do we do this? Typically the self test is started in the firmware.
Are we hitting cases in which the self test hasn't completed by the time
the kernel has loaded and has reached the TPM driver?
2. the semantics of ContinueSelfTest are annoyingly vague. If the self
test is not running, will ContinueSelfTest start it? Perhaps only if the
self test hasn't been run since power on? Because otherwise it seems that
running it another time might unnecessarily delay boot.
2. a comment in tpm_do_selftest mentions that some TPMs may return error
0xa (10) BAD_ORDINAL. In fact, that's what I am seeing on an Infineon TPM
at boot. But... why? The TPM specification does not list error 0xa among
those that can be returned by ContinueSelfTest. It almost seems that there
could be an error in building the request packet, but the code seems
equivalent to that before the change.
I am almost thinking that we may need some additional kernel configuration
settings to deal with various kinds of TPMs, not to mention board-level
differences. For instance, some Chromebooks keep the TPM turned on during
suspend-to-RAM (S3 state for x86), so the kernel doesn't need to save the
state at suspend, and it would be better if it didn't.
Thanks!
Luigi
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
TrouSerS-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/trousers-users
