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

[Javier Martinez Canillas]

On 11/18/2017 12:55 AM, Jason Gunthorpe wrote:
> On Fri, Nov 17, 2017 at 07:14:21PM +0000, Roberts, William C wrote:
> 
>> I don't know why spaces would filter by command code. But it does
>> seem to be loaded By getting the command codes from the tpm in
>> tpm2_get_tpm_pt().
> 
> Ah, I forgot. So my remark is not quite right :\
> 

Right, so it seems I didn't completely misunderstand the code after all :)

>> I don't think that itâs the right fix. I don't think the in-kernel
>> RM should be filtering, but please enlighten my ignorance. Phillip
>> did the userspace RM and understand the RM issues way better than I.
> 
> It needs to prevent unauthorized stuff from being sent to the TPM, so
> if the kernel does not know how to parse the command it shouldn't send
> it. It is a matter of security..
>

What I fail to understand is why that's not a problem when the TPM spaces
infrastructure isn't used, tpm_validate_command() function just returns
true if space is NULL. So when sending command to /dev/tpm0 directly, a
rogue user-space program can send any arbitrary data to the TPM.

And also according to the TCG spec, the TPM should validate the command
header before it attempts to process the command.

> I can't remember if we synthezied responses for anything else, it
> could make sense to return the usual not supported command response
> for this specific thing. But the length error should remain EINVAL I
> think..
>
> Jason
> 

Best regards,
-- 
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat