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

From: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
To: "Fuchs, Andreas" <andreas.fuchs@sit.fraunhofer.de>
Cc: "tpmdd-devel@lists.sourceforge.net" 
	<tpmdd-devel@lists.sourceforge.net>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	David Howells <dhowells@redhat.com>,
	"gregkh@linuxfoundation.org" <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" <akpm@linux-foundation.org>,
	"Serge E. Hallyn" <serge@hallyn.com>,
	"josh@joshtripplet.org" <josh@joshtripplet.org>,
	"richard.l.maliszewski@intel.com"
	<richard.l.maliszewski@intel.com>,
	"monty.wiseman@intel.com" <monty.wiseman@intel.com>,
	will.c.arthur@intel.com
Subject: Re: [tpmdd-devel] [PATCH 4/4] keys,	trusted: seal/unseal with TPM 2.0 chips
Date: Mon, 5 Oct 2015 16:57:03 +0300	[thread overview]
Message-ID: <20151005135703.GA6196@intel.com> (raw)
In-Reply-To: <9F48E1A823B03B4790B7E6E69430724D9D7AEBD5@EXCH2010A.sit.fraunhofer.de>

On Mon, Oct 05, 2015 at 01:36:18PM +0000, Fuchs, Andreas wrote:
> > It's still unnecessary functionality and increases the kernel image size
> > and every hack requires maintenance. It would probably end up needing
> > compilation flag as there exists efforts like:
> > 
> > https://tiny.wiki.kernel.org/
> > 
> > My simple and stupid solution does not *prevent* adding better
> > synchronization. I would go with that and implement access broker
> > properly and not for just one use case later on.
> 
> Unfortunately, I'm not able to write up some code for this myself atm.
> Other priorities unfortunately.
> 
> 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.

> Cheers,
> Andreas

/Jarkko