4 ms·

Or the Gentoo-one or Debian or even the Kernel docs regarding resume=<partition>. There are a few things to consider: - it does not work on encrypted partitio

by ka0lin 5y ago

Or the Gentoo-one or Debian or even the Kernel docs regarding resume=<partition>. There are a few things to consider: - it does not work on encrypted partitions since there is no way to unwrap any key at all - with an active state originating from an encrypted partition gives any attacker the opportunity to manipulate the hibnerated system image - hardening tools often recommend to turn off hibernation in the kernel completely because of #2 (and the implication that this would load any crafted image into your working memory) - recent distributions create /tmp as a tmpfs/ RAM disk which makes hibernation impossible due to power loss of RAM in this sleep state, and /tmp could be the default if nothing else is specified - partition parameters on kernel command lines rise and fall with modules available at boot time/ through the bootloader, e.g. GRUB or Lilo. It might happen that using UUID in the case of hibernation does not work in combination with certain bootloader versions - hardware does not support the power down sleep state, e.g. Raspberry PI or has no peripherals connected triggering a boot process (BIOS does this upon pressing for example the shutdown-key on a USB-keyboard with this enabled in the BIOS which in turn requires the USB-ports to be monitored/ enumerated and powered which isn't the case for any Raspberry) I've been using hibernation for more than a decade on different hardware and distributions but only on that drag-around low-fi laptop ingesting ycombinator, running IRC client or Liferea. I always use the swap partition for this and it has always been /dev/sda2 with 4GByte (currently 5.4.* for Arch, Gentoo and Debian). I trust Grub, currently 2.x but also worked back in the days with 1.x since it is a kernel parameter (and the kernel self-compiled with CONFIG_HIBERNATION=y and copied with a steady hand and a magnetized needle).

r3dey3 5y ago
I have hybernation working fine with root and swap under lvm in a luks encrypted partition. Pretty sure when I set up ubuntu 16.04 or 18.04 it just worked out of the box. Though sound doesn't like to come back properly for the headphone jack and I need to rmmod/modprobe the driver.
Jenda_ 5y ago
> - it does not work on encrypted partitions since there is no way to unwrap any key at all In Debian, this is handled by initramfs scripts: the script asks for password, unlocks the device and then resumes from it. I think this will be the case with other distributions too. Or at least you can hack it yourself (open the device and run "resume" command on it). > - with an active state originating from an encrypted partition gives any attacker the opportunity to manipulate the hibnerated system image This is true, however a) with common encryption modes (XTS) they can only produce garbage, b) it's very difficult to target specific data as the memory allocation is random, c) they can use the same tampering for the system itself (e.g. /bin/bash), d) they can tamper with bootloader or kernel (unless SecureBoot is enabled) anyway. > - recent distributions create /tmp as a tmpfs/ RAM disk which makes hibernation impossible due to power loss of RAM in this sleep state I don't see a problem with this. The content of all tmpfs filesystems is saved into the image (there is much more that could break otherwise, for example /run). > - partition parameters on kernel command lines rise and fall with modules available at boot time/ through the bootloader, e.g. GRUB or Lilo. It might happen that using UUID in the case of hibernation does not work in combination with certain bootloader versions I have never had problem with this and I can imagine a situation when this happens (you are using the same bootloader and initramdisk for normal boot and for resume).

by ka0lin 5y ago

r3dey3 5y ago

I have hybernation working fine with root and swap under lvm in a luks encrypted partition. Pretty sure when I set up ubuntu 16.04 or 18.04 it just worked out of the box. Though sound doesn't like to come back properly for the headphone jack and I need to rmmod/modprobe the driver.

Jenda_ 5y ago

> - it does not work on encrypted partitions since there is no way to unwrap any key at all In Debian, this is handled by initramfs scripts: the script asks for password, unlocks the device and then resumes from it. I think this will be the case with other distributions too. Or at least you can hack it yourself (open the device and run "resume" command on it). > - with an active state originating from an encrypted partition gives any attacker the opportunity to manipulate the hibnerated system image This is true, however a) with common encryption modes (XTS) they can only produce garbage, b) it's very difficult to target specific data as the memory allocation is random, c) they can use the same tampering for the system itself (e.g. /bin/bash), d) they can tamper with bootloader or kernel (unless SecureBoot is enabled) anyway. > - recent distributions create /tmp as a tmpfs/ RAM disk which makes hibernation impossible due to power loss of RAM in this sleep state I don't see a problem with this. The content of all tmpfs filesystems is saved into the image (there is much more that could break otherwise, for example /run). > - partition parameters on kernel command lines rise and fall with modules available at boot time/ through the bootloader, e.g. GRUB or Lilo. It might happen that using UUID in the case of hibernation does not work in combination with certain bootloader versions I have never had problem with this and I can imagine a situation when this happens (you are using the same bootloader and initramdisk for normal boot and for resume).