Google Working On Linux Encrypted Hibernation Support

[Danny3]

Compared to Canonical who is too busy wasting time to implement Snap garbage instead of fixing hibernation, even the normal one!
But yeah they think they can just hide the hibernate button and all is fine, nobody will notice it, at the same time working like help to push their Snap crap that nobody wants!

[waxhead]

They might as well fix unencrypted hibernation first. It literally never ever worked for me.

Apparently hibernate to multiple smaller swap devices is a no-go for some reason. Could this be your problem too? Try one large swap device and see if it works for you.

[anarki2]

They might as well fix unencrypted hibernation first. It literally never ever worked for me.

[ClosedSource]

Encrypted hibernation isn't something I ever thought about but it is a good idea.

A necessity. Try running "strings /dev/your/swap".

[darkbasic]

Finally, this was much needed.

[schmidtbag]

Encrypted hibernation isn't something I ever thought about but it is a good idea.

[archkde]

I use two partitions on my SSD - a non-encrypted ESP, and a LUKS encrypted partition which contains LVM encrypted volumes, including /boot. One of the LVM volumes is swap. So my hibernate is encrypted.

I'm obviously ignorant of the benefits of Google's approach here: could someone outline the benefits compared to my set-up?

As already stated in the article, Google wants a hibernation implementation that makes it impossible for malicious userspace to tamper with the kernel itself. Concretely, with your approach (which, coincidentally, I happen to use myself as well), userspace may write a malicious hibernation image which can be used to inject unauthorized code into the kernel on resume.
Now, malicious userspace already has the potential to do pretty much all damage it may want to (including stealing and/or wiping your data), I'm not convinced of the direct benefits for regular desktop use-cases. An indirect benefit may be that hibernation may finally work with integrity lockdown enabled, which includes by default most distributions on Secure Boot systems.

[bzs0]

Love to see this change. I already do hibernation to encrypted swap based on TPM but it took a while to figure out. An automatic way to set it up and rejection of resuming from unencrypted snapshot would boost ease of use and confidence.

an easier way to setup the unlocking of an encrypted drive via TPM

`systemd-cyrptenroll` might be what you're looking for, for generic partitions. Should be offered by most up-to-date distros

[Old Grouch]

I use two partitions on my SSD - a non-encrypted ESP, and a LUKS encrypted partition which contains LVM encrypted volumes, including /boot. One of the LVM volumes is swap. So my hibernate is encrypted.

I'm obviously ignorant of the benefits of Google's approach here: could someone outline the benefits compared to my set-up?

[gfunk]

good to see.. I think a lot of people are using unencrypted swap partitions for hibernation

also be nice to see an easier way to setup the unlocking of an encrypted drive via TPM although I guess this is down to how/if distros offer it