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

Javier Martinez Canillas
2017-12-08T21:34:59Z

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