On 11/22/2017 4:26 AM, Javier Martinez Canillas wrote:
I still do believe that both interfaces (/dev/tpm and /dev/tpmrm) should be
consistent if possible though.
Agreed. TPM code is hard enough to debug without inconsistencies
between tpm, tpmrm, and the simulator.
In other words, I don't see the value of not
behaving as expected by the spec if this doesn't have security implications
as is the case with the approach suggested by Jason. And the implementation
for sending the synthesized response is also trivial.
The other option that's fixing this in user-space will be a workaround, since
it would either be to check for TPM_RC_SUCCESS instead of TPM_RC_COMMAND_CODE
or make the SAPI library infer that a -EINVAL error means that a command isn't
supported and return a TPM_RC_COMMAND_CODE to the caller.
Remember also that SAPI is just one TSS design. There are currently
three others. And SAPI is targeted more as a building block than an end
user library.
Every TSS implementation would have to do this mapping. How would they
even know to do it if they didn't notice this thread? It wouldn't be
documented anywhere other than deep in kernel code.
