LWN: Comments on "Hibernation in the cloud"

Hibernation in the cloud

cortana — Sat, 30 May 2020 08:09:17 +0000

I think it depends how much RAM you have. I have a Dynabook X30 with 8 GiB of RAM that seems to last about a week, and an X40 with 32 GiB that lasts a couple of days. Which makes sense since it takes more power to keep more RAM refreshed.

I don't use hibernate at all any more because it's disabled by Secure Boot. :/

Hibernation in the cloud

jschrod — Fri, 29 May 2020 12:30:38 +0000

Suspend to RAM lasts only a few days; Hibernate to disk will last a week or so.

These are completely different use cases, if one doesn't use the laptop every day.

Hibernation in the cloud

jezuch — Thu, 28 May 2020 05:29:22 +0000

That's how you know you're getting old: you suddenly learn that things you took for granted are considered obsolete :) I have an old beat-up laptop which I still very occasionally use (like, once or twice a year). The kicker: it has no battery. It would be a shame if I couldn't use hibernate on it...

Hibernation in the cloud

leromarinvit — Wed, 27 May 2020 11:18:08 +0000

The concept seems interesting, but I suppose it can only do this locking magic for the LUKS containers it manages itself. Which is kind of a pity for two reasons:

1. File-backed loop devices aren't completely free in terms of performance, as there's at least another file system involved, which might be fragmented, etc. I'd prefer the directory-backed storage option if I were to use systemd-homed, both so I can choose my own file system and to remove the loop overhead, but then I'd lose the crypto locking feature.
2. More importantly, if the root fs isn't encrypted, or encrypted with a key that remains in RAM during suspend, wouldn't an obvious attack vector be to place a backdoor there which leaks the key or data as soon as the user unlocks /home/user again?

Hibernation in the cloud

Fowl — Wed, 27 May 2020 10:44:23 +0000

Why not hibernate the kernel and just restart user space? ;p

Hibernation in the cloud

leromarinvit — Tue, 26 May 2020 19:08:20 +0000

> That's just misconfigured then.
> There's nothing wrong with allowing a couple of password attempts.

I checked a few years ago when I set this up and back then, I didn't find any config option I could change to allow multiple attempts. Of course that's an implementation issue that's easily fixed, as is the slow unlock speed (cryptsetup is a lot faster) - though depending on what's causing the slowness, fixing it might not be as easy in a bootloader.

Hibernation in the cloud

mb — Tue, 26 May 2020 18:43:14 +0000

>the convenience of STR is hard to beat

As I said, hibernation is not a replacement for STR.
I also use STR a lot, if I just want to conserve energy for a short time.

> And if I mistype my (long) passphrase, it takes even longer to error out and then it won't let me try again, and I have to reboot

That's just misconfigured then.
There's nothing wrong with allowing a couple of password attempts.

Hibernation in the cloud

mathstuf — Tue, 26 May 2020 18:37:24 +0000

> I wonder if it would be feasible to purge the disk encryption key from RAM before suspending after freezing most processes, and require it to be unlocked again before unfreezing them. Whatever handles this unlock procedure would need to have its working set pinned in RAM, so it would probably be hard to use fancy X/Wayland based lock screens - maybe with a second single-purpose instance?

systemd-homed aims to support this. https://wiki.archlinux.org/index.php/Systemd-homed

Hibernation in the cloud

Wol — Tue, 26 May 2020 17:18:30 +0000

> But treating my vacation photos like I'm the next Snowden on my way to a safe place to leak a huge cache of data seems a little inconvenient.

https://www.rspb.org.uk/reserves-and-events/events-dates-...

Your holiday photos could be a treasure trove of information to any interested bystander. If an attacker knew you were in a location they were interested in.

Cheers,
Wol

Hibernation in the cloud

leromarinvit — Tue, 26 May 2020 14:28:52 +0000

Encrypting everything by default is certailny a good idea, I do that too. Hibernation (to an encrypted disk) is of course a good way to protect the state of a running system while at rest, and I've used it as such in the past.

But treating my vacation photos like I'm the next Snowden on my way to a safe place to leak a huge cache of data seems a little inconvenient. Like I said, if that were the case, I wouldn't try to bring this data along with me. But for more mundane things, an encrypted drive (whether the laptop is hibernated or turned off) seems good enough for me.

And for taking my laptop around in my backpack, the convenience of STR is hard to beat - even if I do give up a little security for that convenience. Reading a few GB of data from an SSD is fast, but GRUB still takes several seconds to unlock a LUKS container for me. And if I mistype my (long) passphrase, it takes even longer to error out and then it won't let me try again, and I have to reboot - again taking several seconds just to get to the prompt.

Hibernation in the cloud

mb — Tue, 26 May 2020 13:48:56 +0000

>if I had anything really sensitive

I consider all my data sensitive, because whether something is sensitive depends on a lot of environmental circumstances, too. e.g. laws that I don't know of. And it might also change without my immediate knowledge.

So my default is encrypt everything. I actively decide whether information is non-sensitive on a case by case basis, rather than the other way around. That's much easier and much safer.

Hibernation in the cloud

mb — Tue, 26 May 2020 13:43:29 +0000

I don't think STR is an alternative to hibernation. That's a completely different usage scenario.

I rather see hibernation as an alternative to shutdown. With hibernation I get the "features" of shutdown (e.g. no power consumption. No unlocked crypto-drives) and at the same time I don't loose my work setup state.

Let's ask this question: Why shutdown, if you can hibernate?
I don't see a benefit in shutdown, except for a very small speed advantage (Writing/reading a couple of gigabytes takes seconds on SSDs).

STR on the other hand is unsafe w.r.t. disk encryption. So that's not an option.

Hibernation in the cloud

leromarinvit — Tue, 26 May 2020 13:23:57 +0000

I know about the security implications. If I had any really sensitive data, or suspected that I could realistically be the target of targetted surveillance, I wouldn't use STR. Since I'm mostly boring, I worry more about dragnet type surveillance than targetted attacks. That said, air travel is one of the very few times I deliberately shut down my laptop. But again, if I had anything really sensitive, I wouldn't try bringing it along with me, encrypted or not. Much safer to just download it onto a different machine at the destination if it's not too much, or even to mail an encrypted drive - less potential for rubber-hose cryptanalysis there.

I wonder if it would be feasible to purge the disk encryption key from RAM before suspending after freezing most processes, and require it to be unlocked again before unfreezing them. Whatever handles this unlock procedure would need to have its working set pinned in RAM, so it would probably be hard to use fancy X/Wayland based lock screens - maybe with a second single-purpose instance?

That would still leave open the possibility of an active attacker planting a backdoor in RAM via e.g. some Thunderbolt vulnerability, or physical access to the RAM. But at least the latter seems decidedly non-trivial to pull off while keeping the system running. RAM encryption could mitigate out-of-band attacks, but that obviously requires hardware support, and in the end it can only move the bar for successful attacks somewhat higher, not elminate the threat completely. I guess if you have sufficiently sensitive data, you definitely want proper physical security.

Hibernation in the cloud

dsommers — Tue, 26 May 2020 12:17:01 +0000

There was at some point a hybrid solution, which I liked to use at conferences. I see that 'systemd' provides 'hybrid-sleep'. which might be this feature. It basically wrote everything to disk (hibernate) and then suspended to RAM. The idea was, if your laptop goes out of battery while being in sleep - it would restore from disk; otherwise it would restore from normal suspend to RAM. This actually saved me from a few annoying "out-of-battery" situations back in the day.

That said, in today's day and age where encrypted disks are much more important, hibernation is also much safer than sleep/suspend *when* the hibernation "partition" is also encrypted. When you just unsuspend a laptop, the disks are already in a "decrypted state" which makes it easier to access data (where issues around Thunderbolt can even make it easier too, due to the DMA possibility). While an encrypted hibernation partition will need to be decrypted through some user input at restore boot time. The cost of disk based hibernation is that the restore/start-up time is longer than suspend-to-RAM, but the security is higher with hibernate-to-disk.

As I've not had any successful "hibernation" experiences lately, I've usually resorted to normal shutdown - especially during traveling.

Hibernation in the cloud

leromarinvit — Tue, 26 May 2020 11:56:23 +0000

I suppose the alternative for your use case is suspend to RAM. I also used to use hibernation a lot, much like you describe. And it worked very well for me too. But at some point, I switched to STR because it's just faster and essentially provides the same experience, with modern laptops lasting many days in standby (as opposed to something like half a day when I started using hibernation in the early 2000s). I guess the turning point was when RAM sizes exploded some 10-15 years ago, but SSDs weren't yet widespread - so hibernation took longer and longer. With NVMe SSDs being mainstream now, it would probably be as fast as it used to be, but for me personally, it's just not worth the effort to set up and try. On most machines, it will always be noticeably slower than STR because of firmware startup delays (POST etc.).

I guess most 'normal' people treat their laptop more like a phone these days and just close the lid, using whatever the OS does by default.

Hibernation in the cloud

zdzichu — Tue, 26 May 2020 11:20:57 +0000

Suspend (suspend to RAM) is widely used. Hibernation is suspend to disk.

Hibernation in the cloud

mb — Tue, 26 May 2020 10:10:11 +0000

Erm, wait what? Hibernation is considered obsolete?

I always use hibernation. I never shut down the laptop. There's only the occasional reboot, if something has been updated.

And it works great. In the past, like 12 years ago or so, when I started to use it, I had the occasional hibernation or resume failure. Like 1 in 20 times or so. That's gone. I can't remember my last hibernation failure.
I use an encrypted swap volume on an SSD for the hibernation image. It only takes a couple of seconds to hibernate and resume. For me that's a perfect solution. I don't want to re-establish my work setup every time I power up the machine. With hibernation I can continue to work exactly from where I left off.

So what's the alternative to hibernation, if it's obsolete?

Hibernation in the cloud

Cyberax — Tue, 26 May 2020 00:17:41 +0000

> FWIW the AWS spot instance interruption notification happens two minutes before shutdown, not ten minutes.
Technically, AWS document that there's _at_ _least_ a 2 minute guarantee. Hint, hint :)

Hibernation in the cloud

roc — Mon, 25 May 2020 22:37:42 +0000

FWIW the AWS spot instance interruption notification happens two minutes before shutdown, not ten minutes.

Hibernation in the cloud

pbonzini — Mon, 25 May 2020 21:21:23 +0000

You could use suspend to RAM to ensure devices are shut down orderly, and only save the content RAM to disk while it is paused/suspended. You don't need to store device state at all because a machine wakes up from S3 at the usual reset vector (RIP=0xFFFFFFF0) with all devices in their reset state.

This sidesteps the memory management issues that hibernation has, though you still have to cross fingers that the drivers behave. Windows has an edge here since the Microsoft driver certifications stress test the D0->D3->D0 transitions quite a bit.

Hibernation in the cloud

righiandr — Mon, 25 May 2020 19:35:08 +0000

Another nice aspect of using the hibernation code is that the guest kernel has a better understanding of the memory layout and what needs to be saved to disk, instead of dumping everything as a blob. So we can decide for example if we want to save as much as possible and have a faster system on resume, or drop some caches (i.e. clean page cache pages) and reduce some I/O during hibernate/resume.

Hibernation in the cloud

Cyberax — Mon, 25 May 2020 18:52:17 +0000

Well, I was responsible for AWS Spot hibernation :)

The problem with live migration is that cloud providers pass through actual hardware (GPUs and fast network cards) to guests. And it's generally impossible to save their hardware state without cooperation from the guest. As a result, live migration is reserved only for lower-tier instance types that use completely virtual hardware.

Hibernation in the cloud

joib — Mon, 25 May 2020 18:47:38 +0000

If one were a cloud provider implementing hibernation for customers, wouldn't the logical way to go about it to piggyback on the guest live migration code; just dump the data onto disk instead of setting up a target guest?

(Assuming that live migration works well, which I've understood it generally does these days, and hibernation doesn't which apparently Wysocki disagrees with)

Hibernation in the cloud

mrecho — Mon, 25 May 2020 18:34:20 +0000

Maybe have different modes of Hibernation?
Hypervisor/VM mode, Laptop mode, Desktop mode.