RE: [tpmdd-devel] [PATCH 4/4] keys, trusted: seal/unseal with TPM 2.0 chips

["Arthur, Will C" <will.c.arthur@intel.com>]

I'm having trouble following the arguments here.

Can someone summarize the two (or more) different approaches being proposed?

Will Arthur
Intel Corporation
Server Security Firmware
803-216-2101

-----Original Message-----
From: Jarkko Sakkinen [mailto:jarkko.sakkinen@linux.intel.com] 
Sent: Monday, October 5, 2015 10:28 AM
To: Fuchs, Andreas <andreas.fuchs@sit.fraunhofer.de>
Cc: tpmdd-devel@lists.sourceforge.net; linux-kernel@vger.kernel.org; David Howells <dhowells@redhat.com>; gregkh@linuxfoundation.org; open list:KEYS-TRUSTED <linux-security-module@vger.kernel.org>; open list:KEYS-TRUSTED <keyrings@vger.kernel.org>; James Morris <james.l.morris@oracle.com>; David Safford <safford@us.ibm.com>; akpm@linux-foundation.org; Serge E. Hallyn <serge@hallyn.com>; josh@joshtripplet.org; Maliszewski, Richard L <richard.l.maliszewski@intel.com>; Wiseman, Monty <monty.wiseman@intel.com>; Arthur, Will C <will.c.arthur@intel.com>
Subject: Re: [tpmdd-devel] [PATCH 4/4] keys, trusted: seal/unseal with TPM 2.0 chips

On Mon, Oct 05, 2015 at 02:13:15PM +0000, Fuchs, Andreas wrote:
> > > I was just pointing out, that the proposed patch will not fit in 
> > > with the current approach in TSS2.0, before this user-facing 
> > > kernel API is set in stone and _corrected_ new syscalls need to be added later.
> > 
> > Why you would want new system calls? Do you know how hard it is to 
> > get new system calls accepted? It's usually nearly impossible to get 
> > new system calls in. You are going wrong direction there.
> > 
> > I do not see why couldn't survive in TSS 2.0 implementation for a 
> > while without in-kernel access broker even if the world isn't 
> > perfect and improve from that when the support becomes available. 
> > I'm not frankly following your rationale here.
> > 
> > On the other hand I see use for the kernel images without access 
> > broker in small embdedded devices.
> > 
> > I CC'd to Will Arthur as he has been working with TSS 2.0 for along 
> > time just in case.
> > 
> > > Also, the pseudo-code proposal should be a proper minimal access 
> > > broker that should solve most accesses to TPM transient objects down the road.
> > > Session-brokering is a different beast of course.
> > 
> > I don't mean to be rude but pseudo code doesn't matter much. We know 
> > what is required from an access broker in terms of TPM 2.0 commands 
> > and locking. Only working code matters at this point.
> > 
> > I still don't see why you couldn't add access broker later on. The 
> > patch set does not make the API worse than it is right now.
> 
> OK, I guess we got stuck in the follow-up discussions and missed the points. 

Yup, don't get me wrong here. I like this discussion and am willing to listen to reasonable arguments.

> My 1st point is:
> 
> TPM1.2's 0x40000000 SRK handle was a well-known, singleton, 
> always-present key, that could be relied upon.
> 
> TPM2.0's 0x80000000 is a temporary, TPM-assigned, context-specific 
> handle, that cannot be relied upon.
> 
> Therefore, I think your patch should not use it.
> 
> Instead, I'd recommend using the closest equivalent to an SRK that 
> TPM2.0 has to offer, which is within the range 0x81000000 to 0x8100FFFF.
> (see 
> http://www.trustedcomputinggroup.org/resources/registry_of_reserved_tp
> m_20_handles_and_localities) You might want to use 
> TPM2_GetCapability() to find the correct one.
> 
> Also User-Space could reference any of these handles in the 
> 0x81000000-0x81FFFFFF range. This would be fine.

Alright. How about requiring keyhandle as explicit option for TPM 2.0?
Would that be a more reasonable solution in your opinion? That would acceptable for me.

> My 2nd point is:
> 
> It is IMHO a bad idea to allow user-space to provide transient handles 
> as parameter to the TPM, because TSS2.0 will virtualize handles and 
> /dev/tpm0 is single-access only.
> Instead I'd recommend passing context-saved-blobs to the kernel.
> 
> Then you brought up the valid point that this requires kernel-space 
> resource broker and I provided some sketch-idea in pseudo-code for 
> discussion of general approach. I did not know that the access broker was solved already.

Yeah. I'm not against implementing the broker and how I've been thinking implementing it is not too far away what you just suggested.

I'm not just seeing why that couldn't be done as a separate patch set later on.

> Conclusion
> 
> I would just like to prevent having an API that expects (and defaults 
> to) transient handles be set in stone for the kernel, since it will 
> not meet reality... ;-)
> 
> 
> 
> @Will: Hope you're doing fine... Maybe we can discuss the TSS-side of 
> things tomorrow...
> 
> Cheers,
> Andreas--

/Jarkko