On Mo, 19.08.19 13:58, Chris Murphy (lists@xxxxxxxxxxxxxxxxx) 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#L189 > 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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
