From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752372AbbJEIiD (ORCPT ); Mon, 5 Oct 2015 04:38:03 -0400 Received: from mga14.intel.com ([192.55.52.115]:32823 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751462AbbJEIiA (ORCPT ); Mon, 5 Oct 2015 04:38:00 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.17,637,1437462000"; d="scan'208";a="803774082" Date: Mon, 5 Oct 2015 11:37:53 +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" Subject: Re: [tpmdd-devel] [PATCH 4/4] keys, trusted: seal/unseal with TPM 2.0 chips Message-ID: <20151005083753.GA27404@intel.com> References: <1443775102-9727-1-git-send-email-jarkko.sakkinen@linux.intel.com> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9F48E1A823B03B4790B7E6E69430724D9D7AE4FB@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 Sun, Oct 04, 2015 at 06:57:42PM +0000, Fuchs, Andreas wrote: > Hi Jarkko, > > thanks for the clearification... > > However, I'd recommend against doing so. > > Furthermore, if there is a resource-manager running in userspace, > applications only get virtual handles and TPM might be empty > actually... > > If that's what you're aiming for, I'd recommend passing the pointer to > a context-saved-blob and have the kernel load the key this way. That > ensures no problems with resource-manager and handle-mixups. TPM 1.x interface has the same race if you do not use the default value for the 'keyhandle' option. In practice a processs in TCB (or root) would do all the keyctl magic so I do not see huge issue here. It can be orchestrated by the OS/distribution. From my point of view you are over-engineering in wrong place. It would be easy to add a way to provide the sealing key as blob later on if the simple approach chosen would not be sufficient. I'm confident that for 99% of all real-world use cases the interface provided by the patch set is sufficient. > Cheers, > Andreas /Jarkko > From: Jarkko Sakkinen [jarkko.sakkinen@linux.intel.com] > Sent: Saturday, October 03, 2015 12:26 > 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 > Subject: Re: [tpmdd-devel] [PATCH 4/4] keys, trusted: seal/unseal with TPM 2.0 chips > > On Sat, Oct 03, 2015 at 10:00:59AM +0000, Fuchs, Andreas wrote: > > Hi Jarkko, > > > > [snip] > > > > diff --git a/security/keys/trusted.h b/security/keys/trusted.h > > index ff001a5..fc32c47 100644 > > --- a/security/keys/trusted.h > > +++ b/security/keys/trusted.h > > @@ -12,6 +12,13 @@ > > #define TPM_RETURN_OFFSET 6 > > #define TPM_DATA_OFFSET 10 > > > > +/* Transient object handles start from 0x80000000 in TPM 2.0, which makes it > > + * a sane default. > > + */ > > + > > +#define TPM1_SRKHANDLE 0x40000000 > > +#define TPM2_SRKHANDLE 0x80000000 > > + > > #define LOAD32(buffer, offset) (ntohl(*(uint32_t *)&buffer[offset])) > > #define LOAD32N(buffer, offset) (*(uint32_t *)&buffer[offset]) > > #define LOAD16(buffer, offset) (ntohs(*(uint16_t *)&buffer[offset])) > > > > This TPM2_SRKHANDLE is unfortunately wrong. > > > > Transient handles are assigned and returned by the TPM following the > > commands TPM2_CreatePrimary, TPM2_LoadObject and TPM2_ContextLoad. You > > can only use transient handles as returned by the TPM in order to > > refer to the corresponding object created inside the TPM via these > > commands. They can never assumed to be constant. The fact that TPMs > > return 0x80000000 for the first loaded Object and 0x80000001 for the > > second is merely a coincidence... ;-) > > > > TPM2 also has no (single) SRK anymore. You have to create your own SRK > > / Storage Primary Keys via TPM2_CreatePrimary and use the transient > > handle returned from there. This however requires SH-authorization, > > usually via Policy IMHO, so not easy to manage. So IMHO, this might be > > something for the future but for the moment relying on a persistent > > key would be better... > > > > For persistent SRKs it should become a convention to have those > > around. Those handles start with 0x81000000 and the SRKs (or Storage > > primary Keys) shall live within 0x81000000 to 0x8100FFFF (see > > http://www.trustedcomputinggroup.org/resources/registry_of_reserved_tpm_20_handles_and_localities) > > > > I'd recommend to rely on the existence of a handle inside this range > > with an empty auth-value. So maybe install a persistent SRK to > > 0x81000000 via TPM2_EvictControl and then use this from within the > > kernel for anything following. > > P.S. You should check for the key's TPMA_OBJECT to have fixedTPM SET. > > I don't know if there is an actual test for owner-generated SRK > > testing. I'll ask around though... > > > > Note: you can query for handles in this range via > > TPM2_GetCapability(TPM_CAP_HANDLES, 0x81000000) and then look for > > fitting keys. > > > > > > Feel free to discuss other approaches. > > I'm fully aware of all what you said. My take was to use 0x800000000 as > a default value if you don't the handle ID explicitly in 'description' > parameter of the add_key() syscall. > > > Cheers, > > Andreas > > /Jarkko