From: Yu Chen Subject: Re: [PATCH 0/4][RFC v2] Introduce the in-kernel hibernation encryption Date: Thu, 9 Aug 2018 11:01:35 +0800 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 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 To: Pavel Machek Return-path: Content-Disposition: inline In-Reply-To: <20180808175036.GA16217@amd> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-crypto.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