memfd_secret() in 5.14 [LWN.net]

memfd_secret() in 5.14

Posted Aug 8, 2021 5:21 UTC (Sun) by pabs (subscriber, #43278)
In reply to: memfd_secret() in 5.14 by malor
Parent article: memfd_secret() in 5.14

Does hibernation still work these days? I thought it was broken by the secure boot patches.

to post comments

memfd_secret() in 5.14

Posted Aug 10, 2021 1:34 UTC (Tue) by calumapplepie (guest, #143655) [Link] (2 responses)

Nope. Works like a charm.

Bit finnicky, though. You might remember me, I was talking about running a kernel bisect in #debian-next for a while, to figure out when hibernate-to-swapfile broke. Of course, while I was testing kernels to see where I should put the bisection bounds, it magically started working. On every one of the QEMU images I had created, including the ones that I had just found to not work.

Of course, when was the last time you read a story with charms that were completely explained, logical, and infallible? Sounds like a boring story to me, and I sure am glad that hibernation isn't like that!

memfd_secret() in 5.14

Posted Aug 10, 2021 1:51 UTC (Tue) by pabs (subscriber, #43278) [Link] (1 responses)

Hmm, I wonder how the kernel knows the hibernation image is trustworthy. Normally that requires a trust chain from Microsoft to the thing being loaded, but with hibernation there can be none since only code running on the machine can sign the hibernation image.

memfd_secret() in 5.14

Posted Aug 10, 2021 8:59 UTC (Tue) by NYKevin (subscriber, #129325) [Link]

Secure boot checks the signature on the thing that receives control from UEFI (e.g. GRUB). It doesn't know or care about the fact that GRUB hands control over to the Linux kernel, much less what RAM image the Linux kernel subsequently decides to load up.

Otherwise, this chain of attestation would never end. You'd have to sign the kernel, and systemd, and GNOME, and Firefox, and...