Hello Ken, On 12/08/2017 09:20 PM, Ken Goldman wrote: > On 11/26/2017 9:06 AM, Jarkko Sakkinen wrote: >> >> I think -EINVAL is better than synthetizing commands that are not really >> from the TPM. And we would break backwards compatability by doing this. >> >> As I said in an earlier response I would rather compare resource >> manager to virtual memory than virtual machine. > > Agreed that synthesizing a response is not trivial. (It's not that hard > either - a 6 byte hard coded header and a 4 byte big endian integer.) > At the end it was rather trivial. I posted that patch and got merged today: http://git.infradead.org/users/jjs/linux-tpmdd.git/commitdiff/40ee8cc47c95de22a34c10561f2c00e3c665a29f?hp=7b4edc34bc7542068fa530c0d38babdac95a5e46 > But what would be wrong with sending an unknown command to the TPM and > letting it handle the response? > > 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. Best regards, -- Javier Martinez Canillas Software Engineer - Desktop Hardware Enablement Red Hat
