From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752854AbbJFPHn (ORCPT ); Tue, 6 Oct 2015 11:07:43 -0400 Received: from mga02.intel.com ([134.134.136.20]:35190 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752193AbbJFPHk (ORCPT ); Tue, 6 Oct 2015 11:07:40 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.17,644,1437462000"; d="scan'208";a="820560275" Date: Tue, 6 Oct 2015 18:05:31 +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: <20151006150531.GA7075@intel.com> References: <20151005115649.GA32138@intel.com> <9F48E1A823B03B4790B7E6E69430724D9D7AEAB1@EXCH2010A.sit.fraunhofer.de> <20151005131733.GA4459@intel.com> <9F48E1A823B03B4790B7E6E69430724D9D7AEBD5@EXCH2010A.sit.fraunhofer.de> <20151005135703.GA6196@intel.com> <9F48E1A823B03B4790B7E6E69430724D9D7AEC1D@EXCH2010A.sit.fraunhofer.de> <20151005142800.GA7205@intel.com> <9F48E1A823B03B4790B7E6E69430724D9D7AF14E@EXCH2010A.sit.fraunhofer.de> <20151006122644.GA22991@intel.com> <9F48E1A823B03B4790B7E6E69430724D9D7B056A@EXCH2010A.sit.fraunhofer.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9F48E1A823B03B4790B7E6E69430724D9D7B056A@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 Tue, Oct 06, 2015 at 01:16:02PM +0000, Fuchs, Andreas wrote: > > > I was just trying to point out that the concept is not too difficult, since > > > kernel-space (minimal) resource-manager makes a lot of people go "oh god, > > > never ever, way too big, way too complicated", which IMHO it is not. > > > Until then, I think that the call should just return -EBUSY when you cannot > > > load the sealed data if no slots are available ? > > > > Well this is kind of argument where there is no argument. I already had > > plans how to do access broker back in 2014 that are more or less along > > the lines of the pseudo code you sent. The problem is the lack of active > > maintainers in the subsystem. That's why I get easily frustated > > discussing about access broker in the first place :) > > > > I would have implemented access broker months and months ago if I didn't > > have so much code in the queue for this subsystem. There can be literally > > months delay without any feedback. Right now I have four different > > patches or patch sets in the queue: > > > > - PPI support (yes you cannot enable TPM chips at the moment from Linux) > > - Two bug fixes (CRB command buffer alignment, dTPM2 ACPI hot plugging) > > - Basic trusted keys > > > > I wouldn't blame any particular person about the situation but things > > cannot continue like this. I've been thinking if I could acquire > > co-maintainership of the subsystem for TPM 2 parts (don't really have > > time or expertise for TPM 1.x parts). > > I think I know this situation. You have all my sympathies... ;-) > > > I could post my architecture (never really written it except in my head > > but should not take too long time) to my blog at jsakkine.blogspot.com > > if you are interested discussing more. > > Well, I came in to tpmdd-devel rather recently and only with a small time budget > to spend, but I'd be highly interested to learn about your thoughts. > > As you can tell, I've been involved on the userspace side of things and > therefore already bent my head around some different architectures for > different scenarios. Also your input might help us in the specification of > userspace side as well. > > So please go ahead and write it up, if you can spare the time. > Or let's get on the phone some time. > > > > I looked at Patch 3/4 and it seems you default to -EPERM on TPM2_Create()- > > > and TPM2_Load()-failures ? > > > You might want to test against rc == TPM_RC_OBJECT_MEMORY and return -EBUSY > > > in those cases. Would you agree ? > > > (P.S. I can cross-post there if that's prefered ?) > > > > Have to check the return values. I posted this patch set already in > > early July. You are the first reviewer in three months for this patch > > set. > > > > I think the reason was that for TPM 1.x returned -EPERM in all error > > scenarios and I didn't want to endanger behaviour of command-line tools > > such as 'keyctl'. I would keep it that way unless you can guarantee that > > command-line tools will continue work correctly if I change it to > > -EBUSY. > > > > Anyway, I will recheck this part of the patch set but likely are not > > going to do any changes because I don't want to break the user space. > > > > I will consider revising the patch set with keyhandle required as an > > explicit option. > > Hmm... Will the old keyctl work without modification with the 2.0 patches > anyways ? Yes it does and it should. I've been using keyctl utility to test my patch set. > The different keyHandle values and missing default keyHandle will yield > "differences" anyways, I'd say. > IMHO, we should get it as correct as possible given that TPM 2.0 is still > very young. > > Is adding "additional" ReturnCodes considered ABI-incompatible breaking > anyways ? Yes they are if they make the user space utiltiy malfunction. > Cheers, > Andreas /Jarkko