On 16.02.2018 19:59, James Bottomley wrote:
On Fri, 2018-02-16 at 10:17 -0800, James Bottomley wrote:
On Fri, 2018-02-16 at 10:34 +0200, Jarkko Sakkinen wrote:
Hi
See the comments below and please include this as a prequel patch
for the next version:
https://patchwork.kernel.org/patch/10208965/
Actually, I've got another curious bit of behaviour from my Nuvoton:
After an experiment with primary EK generation that sent it into
failure mode (connected with something else, nothing to do with
this), it's taken to returning 232 (TPM_RC_COMMAND_CODE) to a partial
self test periodically on boot. According to the manual this is
impossible, so I think it's something to do with
tpm_validate_command. I think, perhaps, we shouldn't call the
getcaps for the command codes until the self test is over, but I need
to do more debugging to track down what's going on.
I've also got other reports of TPM_RC_COMMAND_CODE failures during
self test, so this isn't just my screwed up chip.
This isn't anything to do with us synthesizing TPM_RC_COMMAND_CODE, the
status is definitely coming from the chip. If I run a full self test
immediately after this, everything works as normal.
Interesting. What you call full and partial self test, those are the
same command (TPM2_SelfTest), just with fullTest=YES and fullTest=NO,
right? Then it seems even stranger that whether you get RC_COMMAND_CODE
does not depend on the command but on the parameter.
Can anyone from the manufacturers shed any light on the
TPM_RC_COMMAND_CODE return from a partial self test?
It's the first time I see this usage of that return code. The
specification says that this code means "command code not supported",
which to me sounds rather like "command not implemented", not "command
temporarily not available". Maybe this is just a bug in this TPM
implementation?
Alexander
