Re: [RFC PATCH] tpm: don't return -EINVAL if TPM command validation fails

[Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>]

Ken, Javier,

Here's my counterpart to you :-) Sorry for the delay. I'm quite busy
upstreaming SGX ATM.

> I agree with you. As I said in this thread, I don't understand the security
> implications that Jason says. The patch in $SUBJECT just avoids all the TPM
> spaces code paths and sends the command that user-space passed to the kernel
> to the real TPM2 hardware as it would do when writing to /dev/tpm? directly.
> 
> The kernel should provide mechanism and not policy in my opinion, so it should
> be up to user-space to decide what programs are allowed to access the chardevs
> or not. In any case, I'm also OK with the solution that was suggested and was
> merged.

I would say kernel should keep the amount of policy minimal. Your
statement is a "textbook definition" what kernel should do. Sandbox
always requires some policy.

We do not have TPMA_CC entry for unknown command so we don't know how it
might change the TPM state so obviously we must block such command and
not let it through. There is no other option when doing an RM
implementation.

If we ignore security implications, it can at least completely break the
in-kernel RM state.

I did not really get the Ken's comment about incompatibility with
different RM's. I guess all TPM user spaces should be able to handle
TPM_RC_COMMAND_CODE and top bits are part of the TCG standard
(TSS2_RESMGR_TPM_RC_LAYER):

https://trustedcomputinggroup.org/wp-content/uploads/TCG-TSS-2.0-Overview-and-Common-Structures-Specification-Version-0.90-Revision-02.pdf

/Jarkko