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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux Kernel]     [Linux Kernel Hardening]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux