[Ksummit-discuss] Last minute nominations: mcgrof and toshi
James Bottomley
James.Bottomley at HansenPartnership.com
Wed Jul 27 16:14:48 UTC 2016
On Wed, 2016-07-27 at 16:37 +0100, David Howells wrote:
> James Bottomley <James.Bottomley at 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
More information about the Ksummit-discuss
mailing list