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

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

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.

James