On Mo, 19.08.19 13:58, Chris Murphy (lists(a)colorremedies.com) wrote:
I'm skeptical as well. But to further explore this:
1. 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#...
2. 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