lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 21 Nov 2017 20:29:07 +0000
From:   "Roberts, William C" <william.c.roberts@...el.com>
To:     Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
        "Javier Martinez Canillas" <javierm@...hat.com>
CC:     "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



> -----Original Message-----
> From: Jarkko Sakkinen [mailto:jarkko.sakkinen@...ux.intel.com]
> Sent: Tuesday, November 21, 2017 4:30 AM
> To: Javier Martinez Canillas <javierm@...hat.com>
> Cc: 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; Roberts,
> William C <william.c.roberts@...el.com>
> Subject: Re: [RFC PATCH] tpm: don't return -EINVAL if TPM command validation
> fails
> 
> On Tue, Nov 21, 2017 at 10:07:34AM +0100, Javier Martinez Canillas wrote:
> > As mentioned, I think this should be documented. I guess most people
> > would see the in-kernel resource manager as a virtualized TPM, since
> > the "TSS TAB and Resource Manager Specification" [0] explains the RM
> > making an analogy with a virtual memory manager:
> >
> > "The Resource Manager (RM) manages the TPM context in a manner similar
> > to a virtual memory manager. It swaps objects, sessions, and sequences
> > in and out of the limited TPM memory as needed."
> 
> A process in virtual memory has a different environment than code running on
> bare metal without page table, doesn't it?
> 
> > And even your latest LPC presentation mention that the handles in the
> > in-kernel resource manager are virtualized [1].
> >
> > And I disagree that it does not matter, since the same spec says:
> >
> > "This layer is mostly transparent to the upper layers of the TSS and
> > is not required."
> >
> > But returning -EINVAL instead of a proper TPM command response with a
> > TPM_RC_COMMAND_CODE code makes it not transparent to the upper layer.
> 
> *mostly*
> 
> > If the TPM spaces infrastructure is not compliant with the spec, then
> > I think that should also be documented.
> 
> TPM specification is not a formal specification AFAIK.

The published parts are, granted many things are changing.

> 
> > > matters less than breaking the sandbox.
> > >
> >
> > 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

> 
> /Jarkko

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ