Message-ID: <20180809030135.GA21364@chenyu-desktop>
Date:   Thu, 9 Aug 2018 11:01:35 +0800
From:   Yu Chen <yu.c.chen@...el.com>
To:     Pavel Machek <pavel@....cz>
Cc:     Ryan Chen <yu.chen.surf@...il.com>, jlee@...e.com,
        oneukum@...e.com, "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
        ebiggers@...gle.com, Theodore Ts'o <tytso@....edu>,
        smueller@...onox.de, denkenz@...il.com,
        Linux PM list <linux-pm@...r.kernel.org>,
        linux-crypto@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        kookoo.gu@...el.com, Zhang Rui <rui.zhang@...el.com>
Subject: Re: [PATCH 0/4][RFC v2] Introduce the in-kernel hibernation
 encryption

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

Powered by blists - more mailing lists