Hey.
Is this still followed up or already supported to some extent in the
meantime?
I've looked through the previous messages and suggested patches and
some notes on these:
- Auto-detection of resume device, when resuming happens, is most
likely a security hole, as I've described previously in #1020713.
Similarly, auto-detection of a resume device when performing the
hibernation, could be quite disastrous for the security of people:
Just imagine someone has attached some HDD which has swap partition
(unencrypted)... and the system would somehow automatically start to
use that and thereby leak likely sensitive data (at least the dm-
crypt keys of the running system.
For those who run some full disk encryption, it should be possible
to disable any such auto-detections and only use a statically
configured swap device/swapfile instead.
- People may have their swapfile on top of some dm-crypt block layer...
either directly (in case of a swap "partition") or indirectly (in
case of a swapfile where the fs and possibly further DM layers are in
between.)
- The auto-detection of the resume_offset using filefrag does not
generally work, as the values will be wrong for swap files on btrfs
(the kernel wants the physical offset with respect to the block
device, which filefrag doesn't give with btrfs.
btrfs-progs 6.1 brought a new command for that:
btrfs inspect-internal map-swapfile
with the --resume-offset option.
Btw. there's now also:
btrfs filesyste mkswapfile
- Also on btrfs, people that want to use btrfs and a swapfile will
most likely want to have that in a separate btrfs subvolume.
The reason for this is subvolumes containing a swapfile have several
limitations (e.g. no snapshots).
This in turn however, may need some further support from any
integration into initramfs-tools:
One could have something like e.g. /var/local/hibernate/swapfile
where hibernate is a btrfs subvolume, that is really created at that
path (i.e. not just mounted at it).
That should subvolume should then be available as soon as the fs is
mounted.
Even if / is not the actual / on the btrfs.
E.g. when the real top-level subvolume of the btrfs contains:
/root-subvol/var/local/hibernate/swapfile
and is mounted with -o subvol=/root-subvol to / things should still
be there as soon as the root fs is there.
It could however be, that people choose a different layout, with the
top-level subvolume containing:
/root-subvol/
/hibernate/swapfile
where both, /root-subvol and /hibernate are subvols and where
/root-subvol/ is / ... in which case hibernate would not even be
visible in the normal system, unless manually mounted to some point
below / .
In this case, initramfs-tools need to either support this, or at
least somehow fail gracefully.
Some further questions that came to my mind:
Does anyone here know, whether the kernel somehow invalidates the swap
file once it has been unhibernated from - or does initramfs-tools
somehow disable it from being used again?
I ask because in my e.g. my case I boot from USB stick (which contains
GRUB/kernel/intiamfs)... and that USB stick is typically already gone
once the system has finished booting... so initramfs-tools couldn't
just regenerate the initramfs with new information to not use the swap
file on next boot.
Not sure whether this would even work right now, but in principle
people may want to disable swap until it's really actually needed for
hibernation.
The problem is that vm.swappiness doesn't really disable swapping (even
if set to 0, the kernel still might swap). Also it would affect any
swap area and not just the one that should only be used for
hibernation.
So my hope would be that systemd's hibernate.target could perhaps be
used to make some other service (that actually starts the hibernation-
swap on-demand only, right before needed) reverse depend on the former.
It could perhaps even allow to create the swapfile right on-demand
(freeing up disk space otherwise).
But in that case, and if initramfs-tools also do some work with the
file (e.g. determining the offset) it would kinda need to support
something like this, or at least it would be nice if it did.
So... is there any consensus already, how hibernation from swapfiles
should look like in Debian?
Thanks,
Chris.
