From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751643AbbJEN5O (ORCPT ); Mon, 5 Oct 2015 09:57:14 -0400 Received: from mga14.intel.com ([192.55.52.115]:38735 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751032AbbJEN5J (ORCPT ); Mon, 5 Oct 2015 09:57:09 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.17,638,1437462000"; d="scan'208";a="819720615" Date: Mon, 5 Oct 2015 16:57:03 +0300 From: Jarkko Sakkinen To: "Fuchs, Andreas" Cc: "tpmdd-devel@lists.sourceforge.net" , "linux-kernel@vger.kernel.org" , David Howells , "gregkh@linuxfoundation.org" , "open list:KEYS-TRUSTED" , "open list:KEYS-TRUSTED" , James Morris , David Safford , "akpm@linux-foundation.org" , "Serge E. Hallyn" , "josh@joshtripplet.org" , "richard.l.maliszewski@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 Message-ID: <20151005135703.GA6196@intel.com> References: <1443775102-9727-5-git-send-email-jarkko.sakkinen@linux.intel.com> <9F48E1A823B03B4790B7E6E69430724D9D7ADC91@EXCH2010A.sit.fraunhofer.de> <20151003102655.GA9372@intel.com> <9F48E1A823B03B4790B7E6E69430724D9D7AE4FB@EXCH2010A.sit.fraunhofer.de> <20151005083753.GA27404@intel.com> <9F48E1A823B03B4790B7E6E69430724D9D7AE966@EXCH2010A.sit.fraunhofer.de> <20151005115649.GA32138@intel.com> <9F48E1A823B03B4790B7E6E69430724D9D7AEAB1@EXCH2010A.sit.fraunhofer.de> <20151005131733.GA4459@intel.com> <9F48E1A823B03B4790B7E6E69430724D9D7AEBD5@EXCH2010A.sit.fraunhofer.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9F48E1A823B03B4790B7E6E69430724D9D7AEBD5@EXCH2010A.sit.fraunhofer.de> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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