On Sun, Dec 6, 2020 at 11:12 AM Qiyu Yan <yanqiyu@xxxxxxxxxxxxxxxxx> wrote: > > IDK, maybe just because no one is working on this. But changing PRIO may do similar thing, page swap to zram and hibernat to disk. The kernel knows not to write a hibernation image to a swap device backed by zram. In fact it knows it needs contiguous space to write the hibernation image into, ergo a fragmented swap partition can still result in hibernation entry failure. But yeah the bottom line is, resources. I think a higher priority is supporting encrypted authenticated hibernation images. And arguably it's needed for swap as well, because there are all kinds of private user data that can be evicted to swap. It's another advantage of swap on zram, in that since it's volatile, we don't have to worry about it as much when it comes to leaking user data. It's not the same as being encrypted, of course, putting the system in S3 means this private data could still be pilfered if the attacker has physical access. But at least it's not persistent. It is a good idea to setup disk based swap with a random key on each boot. This means you don't have to enter a passphrase. But it also means it can't be used for a hibernation image. The passwordless boot with encrypted authenticated hibernation image also requires a TPM chip, or maybe certain yubikeys could be used. It's a lot of work. > > Or another workaround, swapon the hibernation only file and swapoff all others before hibernation happens. This could be able to do with some tricks with systemd. Yep. This has also been discussed. There's some concern it could result in races when the system is under memory pressure and hibernation is called. It might take some upstream kernel work and also a lot of testing to prove it's reliable. And the problem there already is, hibernation entry isn't reliable for myriad reasons. Adding this funtionality may just make it more complicated without improving reliability. I think a key pre-requisite is working authenticated and signed hibernation images. Until we can bring back hibernation support for systems with UEFI Secure Boot, the most common configuration out of the box, we're kinda stuck not being able to do much of anything with hibernation. There is work happening in the VM world with hibernation, interestingly enough. And some of that work has a good chance of making it more reliable, and helping once we come back full circle on baremetal. They too are concerned about having signed and authenticated hibernation images, even when not in a Secure Boot context, because of the potential for secrecy/privacy leaks in the hibernation image, and ensuring it hasn't been tampered with while in transit. -- Chris Murphy _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-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/users@xxxxxxxxxxxxxxxxxxxxxxx
