On Mo, 19.08.19 13:58, Chris Murphy (lists@colorremedies.com) wrote:
I'm skeptical as well. But to further explore this:
- Does the kernel know better than to write a hibernation image (all
or part) to a /dev/zram device? e.g. a system with: 8GiB RAM, 8GiB swap on ZRAM, 8GiB swap partition. We can use swap priority to use the ZRAM device first, and conventional swap partition second. If the user, today, were to hibernate, what happens?
Usespace takes care of this. It tells the kernel which swap device to hibernate to and it nowadays understands that zswap is not a candidate, and picks the largest swap with the highes prio these days:
https://github.com/systemd/systemd/blob/master/src/shared/sleep-config.c#L18...
- Are you suggesting it would be possible to build support for
multiple swaps and have them dynamically enabled/disabled? e.g. the same system as above, but the 8GiB swap on disk is actually made across two partitions. i.e. a 2GiB partition and 6GiB partition. Normal operation would call for swapon for /dev/zram *and* the small on-disk swap. Only for hibernation would swapon happen for the larger on-disk swap partition (the 2GiB one always stays on).
Yes, that's what I was suggesting.
That's... interesting. It sounds potentially complicated. I can't estimate if it could be fragile.
Yeah. It's an idea. No sure it's a good one though.
Let's consider something else: Hibernation is subject to kernel lockdown policy on UEFI Secure Boot enabled computers. What percentage of Fedora users these days are likely subject to this lockdown? Are we able to effectively support hibernation? On the one hand, Fedora does not block on hibernation bugs (kernel or firmware), thus not supported. But tacitly hibernation is supported because a bunch of users pushed an effort with Anaconda folks to make sure the swap device is set with "resume=" boot parameter with out of the box installations.
We probably should look into supporting hibernation to encrypted swap with a key tied to the TPM. That way hibernation should be fully safe.
Another complicating issue: the Workstation working group has an issue to explore better protecting user data by encrypting /home by default. Of course, user data absolutely can and does leak into swap. Therefore I think we're obligated to consider encrypting swap too. And if swap is encrypted, how does resume from hibernation work? I guess kernel+initramfs load, and plymouth asks for passphrase which unlocks encrypted swap, and the kernel knows to resume from that device-mapper device?
I am pretty sure swap encryption really should be tied to the TPM. In fact, it's one of the very few cases where tying things to the TPM exclusively really makes sense.
So far noone prepared convincing patches to do this though. If anyone wants to look into this, I'd be happy to review a patch for systemd-cryptsetup for example.
Lennart
-- Lennart Poettering, Berlin