Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Wed, 2016-07-27 at 12:20 -0700, Andy Lutomirski wrote:
> On Wed, Jul 27, 2016 at 12:00 PM, James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > On Wed, 2016-07-27 at 10:57 -0700, Andy Lutomirski wrote:
> > > On Wed, Jul 27, 2016 at 9:14 AM, James Bottomley
> > > <James.Bottomley@hansenpartnership.com> wrote:
> > > > On Wed, 2016-07-27 at 16:37 +0100, David Howells wrote:
> > > > > James Bottomley <James.Bottomley@HansenPartnership.com>
> > > > > wrote:
> > > > > 
> > > > > >    3. Integration with existing key management
> > > > > > infrastructures.
> > > > > >   The issue
> > > > > >       here is things like the gnome keyring and the TPM. 
> > > > > >  The
> > > > > > TPM is a
> > > > > >       particularly thorny problem: as a key store, the TPM
> > > > > > has
> > > > > > a very
> > > > > >       limited storage space, so something has effectively
> > > > > > to
> > > > > > swap keys in
> > > > > >       and out as they're used.  This function is currently
> > > > > > performed by a
> > > > > >       userspace stack called the TSS.  However, the kernel
> > > > > > use
> > > > > > of the TPM
> > > > > >       effectively steals the nvram resource behind the
> > > > > > manager's back and
> > > > > >       can lead to resource starvation issues in the TPM and
> > > > > > unexpected
> > > > > >       responses back to the user space TSS.  If the kernel
> > > > > > wants to use
> > > > > >       TPM keys, it needs either to request them properly
> > > > > > from
> > > > > > the TSS or
> > > > > >       we need to pull TPM key management fully into the
> > > > > > kernel
> > > > > > and make
> > > > > >       the TSS use it.
> > > > > 
> > > > > I have partial patches for this, but they're against an old, 
> > > > > pre-tpm2 version of the kernel and need updating.  They 
> > > > > expose TPM keys as a subtype of the asymmetric key type.
> > > > 
> > > > Heh, you really know how to poke a sore spot, since we 
> > > > effectively have two TSSs in Linux: trousers the TPM 1.1 and 
> > > > 1.2 compatible one and ibmtpm20tss for TPM 2.0.  I don't think 
> > > > we have an answer on how we make them work compatibly.  I'm 
> > > > sort of hoping to get some coherence in the TPM Microconference
> > > > at Plumbers
> > > > 
> > > > http://www.linuxplumbersconf.org/2016/ocw/events/LPC2016/tracks
> > > > /585
> > > > 
> > > > However, if we do an upcall to the TSS, then we can't use TPM 
> > > > keys in the pre-boot and have difficulty using them in initrd
> > > > environments, which seems like it might cause problems.
> > > > 
> > > 
> > > I think this nuts.  The kernel should arbitrate use of the TPM's 
> > > key slots and handle context switching.  Doing it in userspace is 
> > > a terrible idea for this and other reasons. 
> > 
> > Hey, I don't disagree, but the user space TSS would have to be 
> > updated as well if we did this.  Right at the moment, the tpmd in 
> > the kernel is a straight TPM command pass through.  We'd need a 
> > more complex interface if the kernel is actually going to manage 
> > TPM key slots.   I think it means quite a big code change, both in 
> > the kernel and for the new interface and for the TSS.
> 
> I admit it's been a while since I read the TPM protocol specs, but I
> think it might be doable without breaking compatibility.  We could
> pretend to pass commands through but instead either emulate a TPM 
> with a whole lot of slots or emulate a TPM with somewhat fewer slots 
> than the real one and remap the slot numbering as needed.

Been there, done that, got the flashing bow tie from our TPM experts as
a "here's a shiny thing small kernel person, you play with it while we
solve the hard security problems" prize.

The reason it doesn't work as simply is that TPM commands mostly
require authentication and may be encrypted (transport wrapped in TPM
speak).  For commands which manipulate keys, the key handle may be part
of the HMAC authentication verifier, so we can't simply replace the key
handle without the HMAC failing to verify or they're encrypted, in
which case we can't even see what the handle is.  The reason the TSS
can do this is that it generates the HMAC and even the wrapping.  It's
hard to see how to solve this without either pulling the whole TSS into
the kernel (yuk) or having a sideband API where the kernel and the TSS
co-operate on key slot handling.

> > Anyway, I put it on the proposed agenda for the Plumbers TPM
> > discussions:
> > 
> > http://wiki.linuxplumbersconf.org/2016:tpms
> 
> If I manage to still be in town, I'll try to make it to that session.

Great, thanks!

James


> --Andy
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
>