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, 3 Jan 2017 17:56:13 -0700
From:   Jason Gunthorpe <jgunthorpe@...idianresearch.com>
To:     James Bottomley <James.Bottomley@...senPartnership.com>
Cc:     Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
        linux-security-module@...r.kernel.org,
        tpmdd-devel@...ts.sourceforge.net,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager

On Tue, Jan 03, 2017 at 04:29:59PM -0800, James Bottomley wrote:
> On Tue, 2017-01-03 at 17:17 -0700, Jason Gunthorpe wrote:
> > On Tue, Jan 03, 2017 at 02:39:58PM -0800, James Bottomley wrote:
> > 
> > > > I think we should also consider TPM 1.2 support in all of this, 
> > > > it is still a very popular peice of hardware and it is equally 
> > > > able to support a RM.
> > > 
> > > I've been running with the openssl and gnome-keyring patches in 1.2 
> > > for months now.  The thing about 1.2 is that the volatile store is 
> > > much larger, so there's a lot less of a need for a RM.  It's only a
> > > requirement in 2.0 because most shipping TPMs only seem to have 
> > > room for about 3 objects.
> > 
> > It would be great if the 1.2 RM could support just enough to allow 
> > RSA key operations from userspace, without key virtualization. That 
> > would allow the plugins that already exist to move to the RM 
> > interface and we can get rid of the hard dependency on trousers.
> [getting long, let's divide into separate issues]
> 
> They actually already do: Trousers, for all its annoying complexity,
> doesn't actually implement a resource manager, so we should be able to
> do all the RSA operations we want today with the current 1.2 interface
> and no RM.

The current interface cannot be used by unprivileged users. I want to
see the kernel provide an unprivileged safe interface for both TPM 1.2
and TPM 2.0

> The difficulty is no API ... unless you want to speak at
> the TPM command level and do all the HMAC calculations yourself.

I think the openssl RSA method could certainly do the TPM command
level with not really a big problem.

That would avoid all these crazy dependencies and debate :|

I have a very good idea what that would look like for tpm 1.2 and I
would estimate < 500 lines....

Jason

Powered by blists - more mailing lists