On Thu, Jun 16, 2022 at 8:42 AM Evan Green <evgreen@xxxxxxxxxxxx> wrote: > > On Tue, May 17, 2022 at 10:34 AM Evan Green <evgreen@xxxxxxxxxxxx> wrote: > > > > Hi Rafael, > > > > On Tue, May 17, 2022 at 9:06 AM Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote: > > > > > > On Mon, May 9, 2022 at 6:44 PM Evan Green <evgreen@xxxxxxxxxxxx> wrote: > > > > > > > > On Fri, May 6, 2022 at 9:08 AM Pavel Machek <pavel@xxxxxx> wrote: > > > > > > > > > > Hi! > > > > > > > > > > > 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. > > Gentle bump in case this dropped off of radars, I'd still appreciate > any feedback folks had on this series. One more bump here, as we'd really love to get encrypted hibernation to a form upstream would accept if at all possible. We were considering landing this in our Chrome OS tree for now, then coming back in a couple months with a "we've been baking this ourselves and it's going so great, oooh yeah". I'm not sure if upstream would find that compelling or not. But in any case, some guidance towards making this more upstream friendly would be well appreciated. One thing I realized in attempting to pick this myself is that the trusted key blob format has moved to ASN.1. So I should really move the creation ticket to the new ASN.1 format (if I can figure out the right OID for that piece), which would allow me to drop a lot of the ugly stuff in tpm2_unpack_blob(). Maybe if I get no other comments I'll work on that and resend. -Evan
