From: Yu Chen <yu.c.chen@intel.com>
To: Pavel Machek <pavel@ucw.cz>
Cc: Ryan Chen <yu.chen.surf@gmail.com>,
jlee@suse.com, oneukum@suse.com,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
ebiggers@google.com, Theodore Ts'o <tytso@mit.edu>,
smueller@chronox.de, denkenz@gmail.com,
Linux PM list <linux-pm@vger.kernel.org>,
linux-crypto@vger.kernel.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
kookoo.gu@intel.com, Zhang Rui <rui.zhang@intel.com>
Subject: Re: [PATCH 0/4][RFC v2] Introduce the in-kernel hibernation encryption
Date: Mon, 6 Aug 2018 16:45:34 +0800 [thread overview]
Message-ID: <20180806084534.GB12124@chenyu-desktop> (raw)
In-Reply-To: <20180805100200.GB22948@amd>
Hi Pavel,
On Sun, Aug 05, 2018 at 12:02:00PM +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
user for password during resume, which sounds more natural.
> Strange as it may sound, that is what "secure" boot requires (and what
> Disney wants).
>
Ok, I understand this requirement, and I'm also concerning how to
distinguish different users from seeing data of each other.
Joey,
I'm thinking of a possible direction which could take advantage
of the password. It leverages either EFI key or TPM
trusted key to get it done. Does it make sense?
1. The user space generates a symetric key key_user using
the password, and passes the key_user to the kernel as the master
key.
2. The kernel uses the EFI key or TPM trusted key to encrypt
the key_user thus gets a encrypt_key.
3. Uses the encrypt_key to do snapshot encryption
4. During resume, the same encrypt_key is generated following
the same steps(I assume the same EFI key or TPM key could be fetched
during resumed, right?) and do the snapshot decryption.
And this is what fscrypt is doing:
Documentation/filesystems/fscrypt.rst
Best,
Yu
> I guess it may have some non-evil uses,
> too... https://www.linux.com/news/matthew-garrett-explains-how-increase-security-boot-time
>
>
> Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
next prev parent reply other threads:[~2018-08-06 8:45 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-18 16:38 [PATCH 0/4][RFC v2] Introduce the in-kernel hibernation encryption Chen Yu
2018-07-18 16:39 ` [PATCH 1/4][RFC v2] PM / Hibernate: Add helper functions for " Chen Yu
2018-07-18 16:39 ` [PATCH 2/4][RFC v2] PM / hibernate: Install crypto hooks " Chen Yu
2018-07-18 16:40 ` [PATCH 4/4][RFC v2] tools: create power/crypto utility Chen Yu
2018-07-18 20:22 ` [PATCH 0/4][RFC v2] Introduce the in-kernel hibernation encryption Pavel Machek
2018-07-18 23:58 ` Yu Chen
2018-07-19 11:01 ` Pavel Machek
2018-07-19 13:20 ` Yu Chen
2018-07-20 10:25 ` Pavel Machek
2018-07-23 11:42 ` Oliver Neukum
2018-07-23 12:22 ` Pavel Machek
2018-07-23 16:38 ` Yu Chen
2018-07-24 12:05 ` Pavel Machek
2018-07-24 11:49 ` Oliver Neukum
2018-07-24 13:04 ` Pavel Machek
2018-07-23 16:23 ` Yu Chen
2018-07-24 11:40 ` Oliver Neukum
2018-07-24 12:01 ` Pavel Machek
2018-07-24 12:47 ` Oliver Neukum
2018-07-24 13:03 ` Pavel Machek
2018-07-24 13:01 ` Oliver Neukum
2018-07-26 7:30 ` Oliver Neukum
2018-07-26 8:14 ` joeyli
2018-07-30 17:04 ` joeyli
2018-08-03 3:37 ` Yu Chen
2018-08-03 5:34 ` joeyli
2018-08-03 13:14 ` Ryan Chen
2018-08-03 14:05 ` joeyli
2018-08-03 16:09 ` Ryan Chen
2018-08-03 18:06 ` joeyli
2018-08-05 10:02 ` Pavel Machek
2018-08-06 8:45 ` Yu Chen [this message]
2018-08-06 10:39 ` joeyli
2018-08-07 7:43 ` Yu Chen
2018-08-07 16:27 ` joeyli
2018-08-08 17:58 ` Pavel Machek
2018-08-09 3:43 ` Yu Chen
2018-08-09 8:12 ` joeyli
2018-08-08 17:50 ` Pavel Machek
2018-08-09 3:01 ` Yu Chen
2018-08-09 6:53 ` Pavel Machek
2018-08-09 9:03 ` Oliver Neukum
2018-08-09 15:55 ` joeyli
2018-08-06 7:57 ` Yu Chen
2018-08-06 9:48 ` joeyli
2018-08-06 10:07 ` Yu Chen
2018-08-06 10:20 ` Oliver Neukum
2018-08-07 7:38 ` Yu Chen
2018-08-07 7:49 ` Ryan Chen
2018-08-07 10:04 ` Oliver Neukum
2018-07-24 14:47 ` joeyli
2018-07-19 14:58 ` joeyli
[not found] ` <edf92acf665b928f02104bb1835fd50723ab9980.1531924968.git.yu.c.chen@intel.com>
2018-07-19 5:32 ` [PATCH 3/4][RFC v2] PM / Hibernate: Encrypt the snapshot pages before submitted to the block device Yu Chen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180806084534.GB12124@chenyu-desktop \
--to=yu.c.chen@intel.com \
--cc=denkenz@gmail.com \
--cc=ebiggers@google.com \
--cc=jlee@suse.com \
--cc=kookoo.gu@intel.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=oneukum@suse.com \
--cc=pavel@ucw.cz \
--cc=rafael.j.wysocki@intel.com \
--cc=rui.zhang@intel.com \
--cc=smueller@chronox.de \
--cc=tytso@mit.edu \
--cc=yu.chen.surf@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox