From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jarkko Sakkinen Date: Fri, 11 Jan 2019 16:04:13 +0000 Subject: Re: [PATCH 1/5 v2] PM / hibernate: Create snapshot keys handler Message-Id: <20190111160413.GB12093@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit List-Id: References: <20190103143227.9138-1-jlee@suse.com> <4499700.LRS4F2YjjC@tauon.chronox.de> <20190108050358.llsox32hggn2jioe@gondor.apana.org.au> <1565399.7ulKdI1fm5@tauon.chronox.de> <1546994671.6077.10.camel@HansenPartnership.com> <1547016579.2789.17.camel@HansenPartnership.com> In-Reply-To: To: Andy Lutomirski Cc: James Bottomley , Stephan Mueller , Herbert Xu , "Lee, Chun-Yi" , "Rafael J . Wysocki" , Pavel Machek , LKML , linux-pm@vger.kernel.org, keyrings@vger.kernel.org, "Rafael J. Wysocki" , Chen Yu , Oliver Neukum , Ryan Chen , David Howells , Giovanni Gherdovich , Randy Dunlap , Jann Horn On Wed, Jan 09, 2019 at 10:34:42AM -0800, Andy Lutomirski wrote: > I suppose I should go read the 2.0 spec. I’ve read the 1.2 spec, but I > always assumed that 2.0 was essentially a superset of 1.2 > functionality. They are essentially different protocols. No real compatibility. > Can the kernel filter TPM 2.0 operations? If so, then a signature > that the kernel would have prevented user code from generating is de > facto an attestation that the kernel generated it (or that the kernel > was compromised, which is sort of equivalent). You shoud look into TPM resource manager that I implemented with great work from James on session swapping and see how far it scales what you have in mind. It is currently exposed only to the user space but could be easily made an in-kernel API. Side-topic: right now the TPM driver can be compiled as a module when its APIs are not used by the kernel (namely IMA and trusted keys) with some Kconfig magic. Since it looks like that there will be even more customers, I think it would make sense to make the TPM driver core as part of the core kernel (device drivers for different types of chips could still be modules). I've proposed this before maybe two times, but it has always been rejected. /Jarkko From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A3560C43387 for ; Fri, 11 Jan 2019 16:04:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7C26121872 for ; Fri, 11 Jan 2019 16:04:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1733238AbfAKQEX (ORCPT ); Fri, 11 Jan 2019 11:04:23 -0500 Received: from mga02.intel.com ([134.134.136.20]:24559 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729359AbfAKQEX (ORCPT ); Fri, 11 Jan 2019 11:04:23 -0500 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jan 2019 08:04:22 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,466,1539673200"; d="scan'208";a="125175893" Received: from gandrejc-mobl1.ger.corp.intel.com (HELO localhost) ([10.249.254.144]) by FMSMGA003.fm.intel.com with ESMTP; 11 Jan 2019 08:04:14 -0800 Date: Fri, 11 Jan 2019 18:04:13 +0200 From: Jarkko Sakkinen To: Andy Lutomirski Cc: James Bottomley , Stephan Mueller , Herbert Xu , "Lee, Chun-Yi" , "Rafael J . Wysocki" , Pavel Machek , LKML , linux-pm@vger.kernel.org, keyrings@vger.kernel.org, "Rafael J. Wysocki" , Chen Yu , Oliver Neukum , Ryan Chen , David Howells , Giovanni Gherdovich , Randy Dunlap , Jann Horn Subject: Re: [PATCH 1/5 v2] PM / hibernate: Create snapshot keys handler Message-ID: <20190111160413.GB12093@linux.intel.com> References: <20190103143227.9138-1-jlee@suse.com> <4499700.LRS4F2YjjC@tauon.chronox.de> <20190108050358.llsox32hggn2jioe@gondor.apana.org.au> <1565399.7ulKdI1fm5@tauon.chronox.de> <1546994671.6077.10.camel@HansenPartnership.com> <1547016579.2789.17.camel@HansenPartnership.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 09, 2019 at 10:34:42AM -0800, Andy Lutomirski wrote: > I suppose I should go read the 2.0 spec. I’ve read the 1.2 spec, but I > always assumed that 2.0 was essentially a superset of 1.2 > functionality. They are essentially different protocols. No real compatibility. > Can the kernel filter TPM 2.0 operations? If so, then a signature > that the kernel would have prevented user code from generating is de > facto an attestation that the kernel generated it (or that the kernel > was compromised, which is sort of equivalent). You shoud look into TPM resource manager that I implemented with great work from James on session swapping and see how far it scales what you have in mind. It is currently exposed only to the user space but could be easily made an in-kernel API. Side-topic: right now the TPM driver can be compiled as a module when its APIs are not used by the kernel (namely IMA and trusted keys) with some Kconfig magic. Since it looks like that there will be even more customers, I think it would make sense to make the TPM driver core as part of the core kernel (device drivers for different types of chips could still be modules). I've proposed this before maybe two times, but it has always been rejected. /Jarkko