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

[Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>]

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_tpm_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