From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 6C64A94D for ; Wed, 27 Jul 2016 19:20:41 +0000 (UTC) Received: from mail-ua0-f175.google.com (mail-ua0-f175.google.com [209.85.217.175]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8EC42107 for ; Wed, 27 Jul 2016 19:20:40 +0000 (UTC) Received: by mail-ua0-f175.google.com with SMTP id 35so24347761uap.1 for ; Wed, 27 Jul 2016 12:20:40 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <1469646020.27356.97.camel@HansenPartnership.com> References: <1469631987.27356.48.camel@HansenPartnership.com> <20150804152622.GY30479@wotan.suse.de> <1468612258.5335.0.camel@linux.vnet.ibm.com> <1468612671.5335.5.camel@linux.vnet.ibm.com> <20160716005213.GL30372@sirena.org.uk> <1469544138.120686.327.camel@infradead.org> <13539.1469633840@warthog.procyon.org.uk> <1469636088.27356.60.camel@HansenPartnership.com> <1469646020.27356.97.camel@HansenPartnership.com> From: Andy Lutomirski Date: Wed, 27 Jul 2016 12:20:20 -0700 Message-ID: To: James Bottomley Content-Type: text/plain; charset=UTF-8 Cc: Mark Brown , "ksummit-discuss@lists.linuxfoundation.org" Subject: Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Wed, Jul 27, 2016 at 12:00 PM, James Bottomley wrote: > On Wed, 2016-07-27 at 10:57 -0700, Andy Lutomirski wrote: >> On Wed, Jul 27, 2016 at 9:14 AM, James Bottomley >> wrote: >> > On Wed, 2016-07-27 at 16:37 +0100, David Howells wrote: >> > > James Bottomley 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. > > 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. --Andy