From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752104AbbJCK1E (ORCPT ); Sat, 3 Oct 2015 06:27:04 -0400 Received: from mga14.intel.com ([192.55.52.115]:9466 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751825AbbJCK1A (ORCPT ); Sat, 3 Oct 2015 06:27:00 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.17,628,1437462000"; d="scan'208";a="818519040" Date: Sat, 3 Oct 2015 13:26:55 +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: <20151003102655.GA9372@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9F48E1A823B03B4790B7E6E69430724D9D7ADC91@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 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