On Mon, May 9, 2022 at 6:44 PM Evan Green [off-list ref] wrote:

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.

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).

Thanks!