From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Bottomley Date: Fri, 11 Jan 2019 15:28:58 +0000 Subject: Re: [PATCH 1/5 v2] PM / hibernate: Create snapshot keys handler Message-Id: <1547220538.2793.6.camel@HansenPartnership.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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> <20190111140226.GA6448@linux.intel.com> In-Reply-To: <20190111140226.GA6448@linux.intel.com> To: Jarkko Sakkinen , Andy Lutomirski Cc: 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 Fri, 2019-01-11 at 16:02 +0200, Jarkko Sakkinen wrote: > 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. Actually, the resource manager only keeps volatile objects separated when in use not when offloaded. The problem here is that the object needs to be persisted across reboots, so either it gets written to the NV area, bypassing the resource manager and making it globally visible or it has to get stored in TPM form in the hibernation image, meaning anyone with access to the TPM who can read the image can extract and load it. Further: anyone with access to the TPM can create a bogus sealed key and encrypt a malicious hibernation image with it. So there are two additional problems 1. Given that the attacker may have access to the binary form of the key, can we make sure only the kernel can get it released? 2. How do we prevent an attacker with access to the TPM from creating a bogus sealed key? This is why I was thinking localities. James 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=-0.8 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS 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 A74A7C43387 for ; Fri, 11 Jan 2019 15:29:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 76B3D218AF for ; Fri, 11 Jan 2019 15:29:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=hansenpartnership.com header.i=@hansenpartnership.com header.b="rXCWuoik" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387592AbfAKP3E (ORCPT ); Fri, 11 Jan 2019 10:29:04 -0500 Received: from bedivere.hansenpartnership.com ([66.63.167.143]:44612 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728941AbfAKP3E (ORCPT ); Fri, 11 Jan 2019 10:29:04 -0500 Received: from localhost (localhost [127.0.0.1]) by bedivere.hansenpartnership.com (Postfix) with ESMTP id 63A888EE491; Fri, 11 Jan 2019 07:29:02 -0800 (PST) Received: from bedivere.hansenpartnership.com ([127.0.0.1]) by localhost (bedivere.hansenpartnership.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id knqUCgmGQTLS; Fri, 11 Jan 2019 07:29:01 -0800 (PST) Received: from [153.66.254.194] (unknown [50.35.68.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bedivere.hansenpartnership.com (Postfix) with ESMTPSA id 058B08EE369; Fri, 11 Jan 2019 07:29:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hansenpartnership.com; s=20151216; t=1547220541; bh=S6CiscRi8b9JhK/2xjPs5aFjuBUbVmlVCSQUIm9Gkbg=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=rXCWuoikEBL7bsHUpVoyOsxAQ/2SsONzczVDpaPOjMR9BZ6bkRhff6vD8TZwDYcEQ J3HZG/M4u6bC6diqs6DtxvbiunFI4ZKErwOtM0JeXVvo9udyA4hQ8PPsR12Q/z/udU VtpsRHgTu8XmuLRcFAwQow/8NiZBU7bQ5b7nn5Fc= Message-ID: <1547220538.2793.6.camel@HansenPartnership.com> Subject: Re: [PATCH 1/5 v2] PM / hibernate: Create snapshot keys handler From: James Bottomley To: Jarkko Sakkinen , Andy Lutomirski Cc: 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 Date: Fri, 11 Jan 2019 07:28:58 -0800 In-Reply-To: <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> <20190111140226.GA6448@linux.intel.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.6 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2019-01-11 at 16:02 +0200, Jarkko Sakkinen wrote: > 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. Actually, the resource manager only keeps volatile objects separated when in use not when offloaded. The problem here is that the object needs to be persisted across reboots, so either it gets written to the NV area, bypassing the resource manager and making it globally visible or it has to get stored in TPM form in the hibernation image, meaning anyone with access to the TPM who can read the image can extract and load it. Further: anyone with access to the TPM can create a bogus sealed key and encrypt a malicious hibernation image with it. So there are two additional problems 1. Given that the attacker may have access to the binary form of the key, can we make sure only the kernel can get it released? 2. How do we prevent an attacker with access to the TPM from creating a bogus sealed key? This is why I was thinking localities. James