So a funny confluence of events has happened in my life. Until recently the majority of my time was spent with a mobile machine, so it got used every day. When I wasn’t using it, it slept in S3 state (suspend to ram). Since I used it every day, it never ran out of battery in S3 (which forces it to S4, suspend to disk).
Fast forward to a bit, and the mobile computer is not used too often (less than once per week). And, annoyingly, it is always with a flat battery and no resume that it is pulled out of its slot. How could this happen? I’m used to finding ~100% power and an instant-on? it seems that as the battery runs out it would normally wake up, write the snap to disk, and then go to S4 (power off). But now it is not. Hmm.
Last week I posted about UEFI secureboot, how to make a self-signed system with a fully encrypted disk. So my first thought was there of course, maybe it doesn’t want to suspend to the encrypted swap?
Turns out no. Turns out there is an attack vector that people were worried about, that some malware would write to the swap file and then force a reboot, causing the malware to be loaded as the kernel. So, the good folks in Linux land disable suspend to disk.
$ cat /sys/power/disk [disabled]
Now, whenever an opportunity for improvement crops up in the OSS world, you generally find someone who has (attempted) to solve it.
Here we can see a set of patches to allow signature verification of a hibernate snapshot. And a great discussion on stackexchange about the why and whynot. But, tl;dr: no hibernate for me.
This is my laptop not sleeping 🙂
Leave a Reply