[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171117235526.GX4276@ziepe.ca>
Date: Fri, 17 Nov 2017 16:55:26 -0700
From: Jason Gunthorpe <jgg@...pe.ca>
To: "Roberts, William C" <william.c.roberts@...el.com>
Cc: Javier Martinez Canillas <javierm@...hat.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
Peter Huewe <peterhuewe@....de>,
"Tricca, Philip B" <philip.b.tricca@...el.com>,
"linux-integrity@...r.kernel.org" <linux-integrity@...r.kernel.org>
Subject: Re: [RFC PATCH] tpm: don't return -EINVAL if TPM command validation
fails
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 :\
> 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..
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
Powered by blists - more mailing lists