From patchwork Sat Oct 3 10:00:59 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Fuchs, Andreas" X-Patchwork-Id: 525871 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.sourceforge.net (lists.sourceforge.net [216.34.181.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 7B6941402B2 for ; Sat, 3 Oct 2015 20:18:30 +1000 (AEST) Received: from localhost ([127.0.0.1] helo=sfs-ml-3.v29.ch3.sourceforge.com) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1ZiJtX-00084J-Ft; Sat, 03 Oct 2015 10:18:23 +0000 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1ZiJtW-00084E-KE for tpmdd-devel@lists.sourceforge.net; Sat, 03 Oct 2015 10:18:22 +0000 X-ACL-Warn: Received: from mailext.sit.fraunhofer.de ([141.12.72.89]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1ZiJtT-0000mJ-HA for tpmdd-devel@lists.sourceforge.net; Sat, 03 Oct 2015 10:18:22 +0000 Received: from mail.sit.fraunhofer.de (exch2010b.sit.fraunhofer.de [141.12.84.194]) by mailext.sit.fraunhofer.de (8.14.4/8.14.4/Debian-2ubuntu2.1) with ESMTP id t93A15wx032045 (version=TLSv1/SSLv3 cipher=AES256-SHA256 bits=256 verify=NOT); Sat, 3 Oct 2015 12:01:07 +0200 Received: from EXCH2010A.sit.fraunhofer.de ([169.254.1.11]) by EXCH2010B.sit.fraunhofer.de ([141.12.84.194]) with mapi id 14.03.0248.002; Sat, 3 Oct 2015 12:01:00 +0200 From: "Fuchs, Andreas" To: Jarkko Sakkinen , "tpmdd-devel@lists.sourceforge.net" , "linux-kernel@vger.kernel.org" Thread-Topic: [tpmdd-devel] [PATCH 4/4] keys, trusted: seal/unseal with TPM 2.0 chips Thread-Index: AQHQ/O3SmaygPpaHSk2oQAnc2S6f+55X715z Date: Sat, 3 Oct 2015 10:00:59 +0000 Message-ID: <9F48E1A823B03B4790B7E6E69430724D9D7ADC91@EXCH2010A.sit.fraunhofer.de> References: <1443775102-9727-1-git-send-email-jarkko.sakkinen@linux.intel.com>, <1443775102-9727-5-git-send-email-jarkko.sakkinen@linux.intel.com> In-Reply-To: <1443775102-9727-5-git-send-email-jarkko.sakkinen@linux.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] MIME-Version: 1.0 X-Spam-Score: -0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1ZiJtT-0000mJ-HA Cc: "gregkh@linuxfoundation.org" , David Safford , David Howells , "open list:KEYS-TRUSTED" , "open list:KEYS-TRUSTED" , James Morris , "akpm@linux-foundation.org" , "Serge E. Hallyn" Subject: Re: [tpmdd-devel] [PATCH 4/4] keys, trusted: seal/unseal with TPM 2.0 chips X-BeenThere: tpmdd-devel@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Tpm Device Driver maintainance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tpmdd-devel-bounces@lists.sourceforge.net Hi Jarkko, [snip] 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. Cheers, Andreas ------------------------------------------------------------------------------ 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]))