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
