[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171126140646.hhjtyy26h5ebyd5a@linux.intel.com>
Date: Sun, 26 Nov 2017 16:06:46 +0200
From: Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
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>,
Peter Huewe <peterhuewe@....de>,
"Tricca, Philip B" <philip.b.tricca@...el.com>,
Jason Gunthorpe <jgunthorpe@...idianresearch.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 Tue, Nov 21, 2017 at 08:29:07PM +0000, Roberts, William C wrote:
> > TPM specification is not a formal specification AFAIK.
>
> The published parts are, granted many things are changing.
Yes, how it defines the protocol, you are correct. It does not have a
formal definition of RM behavior or at least I haven't found it.
> > > Yes, sorry for that. It wasn't clear to me that there was a sandbox
> > > and my lack of familiarity with the code was the reason why I posted
> > > as a RFC in the first place.
> > >
> > > Do you agree with Jason's suggestion to send a synthesized TPM command
> > > in the that the command isn't supported?
> >
> > Nope.
>
> We should update the elf loader to make sure that ELF files don't contain
> Incorrect instructions. We shouldn't have this type of policy in the driver
> considering that the tpm is designed to handle it. Obviously you disagree,
> just understand you're wrong :-P
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.
/Jarkko
Powered by blists - more mailing lists