Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp1529563imm; Wed, 8 Aug 2018 19:56:27 -0700 (PDT) X-Google-Smtp-Source: AA+uWPxFu15iTDeRBFDAQ7fiKl636BfxjoGeoUsrXzYSgT32DgDqbOOJI/qTwimeODA52tSaxoW/ X-Received: by 2002:a63:db15:: with SMTP id e21-v6mr304154pgg.418.1533783386972; Wed, 08 Aug 2018 19:56:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533783386; cv=none; d=google.com; s=arc-20160816; b=Rx2QOpbjXrQHIelMXcvd1koGoJoXVQsQ1bHwpVUzskGM/QTevJW7KN5AKyt20oRmV9 NbNCKTwPiTDPa1baM707OyB+WMeJnn65CsCecFQiL45qF18bMZhqV2oBgPcmzKK3zBXm zKjG77jiGRQYZhXRMb4GaaUOSdbrYZkEH0+heWFwZjrN1rq7WCRKFquwcxvfnv7Nwtaj oAYbeiC8rnLd2IOegI54HXJHrr2367kP6WIdcQCkxiZMBwyyeOB20Yrz5JElA7qN2h+I 1CAZLXe+fUh7+JliFLVlSLaOoZJtSXjrTLTqDTossJFbCzotZS57tbdZkuxOE0pQ2wUp ijfw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=gund+ccmBraNqwpeFAJXRmQSLR4Dv931SlqNajLAx/w=; b=ZJjJ+5HMZlV4/65t4VJzDJJaDPBtxDMyep24DZ0CTGB0T8NE2iSD5707Wc0gVfPj8O nAqqJSE2HfUA59FKhRUvrLNjdtxg9JuERP4kgF1jf34fu46kGakyq574mrRzp/qfCKLu GHC91vabvdTyHZioUVoTvMX7dDQ+DUN1K6mcTI56U6jeJwmt3BI898p2DlWtBpy/oENi PZb8glIat6n9u6rh8I7Ir4iSzbaa+Aw1tP5jOh9hLGuYFu/suceA9NXXix/k0ptfVH9d whs0PJg7ceBYNNqr0LMpSepwNdELDo0pPFO0BLGtxnLlVYtkzZtD70Sm928Y+RmW1Zsf l6/A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 94-v6si5071233plb.59.2018.08.08.19.56.12; Wed, 08 Aug 2018 19:56:26 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727806AbeHIFRz (ORCPT + 99 others); Thu, 9 Aug 2018 01:17:55 -0400 Received: from mga04.intel.com ([192.55.52.120]:8564 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726926AbeHIFRz (ORCPT ); Thu, 9 Aug 2018 01:17:55 -0400 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Aug 2018 19:55:22 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.53,213,1531810800"; d="scan'208";a="78757597" Received: from chenyu-desktop.sh.intel.com (HELO chenyu-desktop) ([10.239.160.116]) by fmsmga004.fm.intel.com with ESMTP; 08 Aug 2018 19:55:19 -0700 Date: Thu, 9 Aug 2018 11:01:35 +0800 From: Yu Chen To: Pavel Machek Cc: Ryan Chen , jlee@suse.com, oneukum@suse.com, "Rafael J. Wysocki" , ebiggers@google.com, Theodore Ts'o , smueller@chronox.de, denkenz@gmail.com, Linux PM list , linux-crypto@vger.kernel.org, Linux Kernel Mailing List , kookoo.gu@intel.com, Zhang Rui Subject: Re: [PATCH 0/4][RFC v2] Introduce the in-kernel hibernation encryption Message-ID: <20180809030135.GA21364@chenyu-desktop> References: <20180723162302.GA4503@sandybridge-desktop> <1532590246.7411.3.camel@suse.com> <20180726081404.GG4244@linux-l9pv.suse> <20180730170415.GQ4244@linux-l9pv.suse> <20180803033702.GB416@sandybridge-desktop> <20180803053445.GC4244@linux-l9pv.suse> <20180805100200.GB22948@amd> <20180806084534.GB12124@chenyu-desktop> <20180808175036.GA16217@amd> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180808175036.GA16217@amd> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Pavel, Joey, Oliver Please let me describe the original requirement and my understanding about hibernation encryption here, thus help us sync on the same thread: On Wed, Aug 08, 2018 at 07:50:36PM +0200, Pavel Machek wrote: > Hi! > > > > > > User space doesn't need to involve. The EFI root key is generated by > > > > > EFI boot stub and be transfer to kernel. It's stored in EFI boot service > > > > > variable that it can only be accessed by trusted EFI binary when > > > > > secure boot is enabled. > > > > > > > > > Okay, this apply to the 'suspend' phase, right? > > > > I'm still a little confused about the 'resume' phase. > > > > Taking encryption as example(not signature), > > > > the purpose of doing hibernation encryption is to prevent other users > > > > from stealing ram content. Say, user A uses a passphrase to generate the > > > > > > No, I don't think that's purpose here. > > > > > > Purpose here is to prevent user from reading/modifying kernel memory > > > content on machine he owns. > > > > > Say, A puts his laptop into hibernation and walks away, > > and B walks by, and opens A's laptop and wakes up the system and he > > can do what he wants. Although EFI key/TPM trusted key is enabled, > > currently there's no certification during resume, which sounds > > unsafe to me. Afterall, the original requirement is to probe > > Define unsafe. > > If you want security against bad people resuming your machines, please Yes, this is one of the requirements. > take a look at existing uswsusp solutions. It defends against that. > > If you want security against bad people tampering with your machines > physically, sorry, there's no way to defend against that. No, this is not the requirement. > > But I thought you were trying to do something for secure boot, and "bad > person resumes your machine" is out of scope there. > Not exactly, secure boot is one solution to meet the requirement. > So please always explain security against _what kind of attack_ you > are trying to improve; intelligent communication is not possible > without that. > User requirement: A is the user, B is the attacker, user A launches a STD and encrypts A's ram data, then writes these encrypted data onto the disk, so that: Even if user B has access to the disk, B could not know the content of A. Which implies: 1. If B unplugs the disk from A's machine, and plugs the disk onto another machine, B could not decode the content without A's 'permission'. 2. If B is using the same machine as A, even A has walked away leaving the system suspend, B could not resume to A's context without A's 'permission'. Previously, there are three proposal for this: a. Enhance the uswsusp(Pavel) b. Using user provided password to generate the key, for encryption(Yu) c. Using security boot(TPM or EFI key) for encryption(Joey) Since I was proposing solution b, I'll say a little more about it. The original idea was that, the user provides a password, then this password is used to generate the key, which means, if user B has provided an incorrect password, the kernel will fail to decrypt the data and is likely to fail the resume process. That is to say, no matter which physical machine B is using, only if he has provided the password, he would be able to resume. In the first version, the key deviration was firstly done in kernel space, which satisfies the requirement and both saftey. Unfortunately it was rejected and people would like to see the key generated in user space instead. However, using user provided key directly is not safe, according to the discussion in the thread. I don't have good idea on how to improve this, but only have some workarounds, say, ask the kernel to use TPM key to protects the user provided 'key', etc. Then let's talk a little more about secure boot. According to my understanding, the situation secure boot tries to deal with is a little different from the user case we raised above - It is an enhancement for case 1, because it refuses to resume once the machine is changed. And it does not cover case 2. But if it is a requirement from the user, that's ok. uswsusp is to do all the staff in user space, and other two aim to do all the staff in kernel space. I'm not arguing which one is better, but I'm not sure how often user is using it, as we don't get uswsusp related bug report on kernel bugzilla (both internally)recent years. Another point is, why the compression is in kernel rather than in uswsusp, it looks like the same case as encryption here. Best, Yu