From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751599AbbJFGYP (ORCPT ); Tue, 6 Oct 2015 02:24:15 -0400 Received: from [141.12.72.89] ([141.12.72.89]:33967 "EHLO mailext.sit.fraunhofer.de" rhost-flags-FAIL-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1750853AbbJFGYN convert rfc822-to-8bit (ORCPT ); Tue, 6 Oct 2015 02:24:13 -0400 From: "Fuchs, Andreas" To: Jarkko Sakkinen 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 Thread-Topic: [tpmdd-devel] [PATCH 4/4] keys, trusted: seal/unseal with TPM 2.0 chips Thread-Index: AQHQ/O3SmaygPpaHSk2oQAnc2S6f+55X715zgAGBTICAAkH+poAAxDWAgAAm21GAABC6gIAAIhu2///0c4CAACRtB///5p2AgAAh/fr//+aoAAAk7+fD Date: Tue, 6 Oct 2015 06:22:29 +0000 Message-ID: <9F48E1A823B03B4790B7E6E69430724D9D7AF14E@EXCH2010A.sit.fraunhofer.de> References: <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> <20151005135703.GA6196@intel.com> <9F48E1A823B03B4790B7E6E69430724D9D7AEC1D@EXCH2010A.sit.fraunhofer.de>,<20151005142800.GA7205@intel.com> In-Reply-To: <20151005142800.GA7205@intel.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [79.242.103.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > > 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. We could not agree more. I'm always up for a good discussion... ;-) > > 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. You mean getting rid of the default behaviour ? That sound reasonable to me as well. A later patch could add the possibility to use the TPM2_GetCapability() thing at a later stage then... > > 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. I should have been more clear then. I agree that it can be added later on. Or rather I think it should be added at some later point... 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 ? 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 ?) Cheers, Andreas