Thread (16 messages) 16 messages, 6 authors, 2022-08-06

Re: [PATCH 00/10] Encrypted Hibernation

From: Evan Green <hidden>
Date: 2022-05-17 17:42:24
Also in: keyrings, linux-doc, linux-integrity, linux-pm, lkml

Hi Rafael,

On Tue, May 17, 2022 at 9:06 AM Rafael J. Wysocki [off-list ref] wrote:
On Mon, May 9, 2022 at 6:44 PM Evan Green [off-list ref] wrote:
quoted
On Fri, May 6, 2022 at 9:08 AM Pavel Machek [off-list ref] wrote:
quoted
Hi!
quoted
We are exploring enabling hibernation in some new scenarios. However,
our security team has a few requirements, listed below:
1. The hibernate image must be encrypted with protection derived from
   both the platform (eg TPM) and user authentication data (eg
   password).
2. Hibernation must not be a vector by which a malicious userspace can
   escalate to the kernel.
Can you (or your security team) explain why requirement 2. is needed?

On normal systems, trusted userspace handles kernel upgrades (for example),
so it can escalate to kernel priviledges.
Our systems are a little more sealed up than a normal distro, we use
Verified Boot [1]. To summarize, RO firmware with an embedded public
key verifies that the kernel+commandline was signed by Google. The
commandline includes the root hash of the rootfs as well (where the
modules live). So when an update is applied (A/B style, including the
whole rootfs), assuming the RO firmware stayed RO (which requires
physical measures to defeat), we can guarantee that the kernel,
commandline, and rootfs have not been tampered with.

Verified boot gives us confidence that on each boot, we're at least
starting from known code. This makes it more challenging for an
attacker to persist an exploit across reboot. With the kernel and
modules verified, we try to make it non-trivial for someone who does
manage to gain root execution once from escalating to kernel
execution. Hibernation would be one obvious escalation route, so we're
hoping to find a way to enable it without handing out that easy
primitive.

[1] https://www.chromium.org/chromium-os/chromiumos-design-docs/verified-boot/
So I guess this really is an RFC.
Yes, I suppose it is.
Honestly, I need more time to go through this and there are pieces of
it that need to be looked at other people (like the TPM-related
changes).
No problem, thanks for the reply to let me know. I expect some back
and forth in terms of what should be hidden behind abstractions and
where exactly things should live. But I wanted to get this out to
upstream as early as I could, just to get initial reactions on the
overall concept and design. Looking forward to hearing your thoughts
when you get a chance, and let me know if there are others I should be
adding that I've missed.

-Evan
Thanks!
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help