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 D5EAAC43387 for ; Fri, 11 Jan 2019 14:02:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B042A2177B for ; Fri, 11 Jan 2019 14:02:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1733003AbfAKOCi (ORCPT ); Fri, 11 Jan 2019 09:02:38 -0500 Received: from mga14.intel.com ([192.55.52.115]:47234 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729247AbfAKOCh (ORCPT ); Fri, 11 Jan 2019 09:02:37 -0500 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jan 2019 06:02:36 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,465,1539673200"; d="scan'208";a="107502868" Received: from gandrejc-mobl1.ger.corp.intel.com (HELO localhost) ([10.249.254.144]) by orsmga006.jf.intel.com with ESMTP; 11 Jan 2019 06:02:28 -0800 Date: Fri, 11 Jan 2019 16:02:26 +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: <20190111140226.GA6448@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 Tue, Jan 08, 2019 at 05:43:53PM -0800, Andy Lutomirski wrote: > (Also, do we have a sensible story of how the TPM interacts with > hibernation at all? Presumably we should at least try to replay the > PCR operations that have occurred so that we can massage the PCRs into > the same state post-hibernation. Also, do we have any way for the > kernel to sign something with the TPM along with an attestation that > the signature was requested *by the kernel*? Something like a > sub-hierarchy of keys that the kernel explicitly prevents userspace > from accessing?) Kernel can keep it is own key hierarchy in memory as TPM2 chips allow to offload data in encrypted form and load it to TPM when it needs to use it. The in-kernel resource manager that I initiated couple years ago provides this type of functionality. /Jarkko