[pkg-cryptsetup-devel] Bug#774647: can't a use key file stored on an encrypted rootfs to unlock the resume device at initramfs stage

[Christoph Anton Mitterer]

Hey.

I recently considered to do the same, i.e.:
- have a passphrase only for the dm-crypt encrypted rootfs
- have a separate dm-crypt encrypted swap device for hibernate only
- use a high-entropy key-file on the rootfs to decrypt the swap device


My understanding of the initramfs-tools boot is as follows:
init-top
...
local-top => here cryptroot opens ("decrypts") the root- and resume-
             device as well as any with "initramfs"-option in crypttab
local-bottom => it retries the same here
local-premount => here, none of these devices has been mounted, yet
                  also here, the resume happens, at which point
                  the system is completely replaced, the initramfs used
                  just before for booting into the resume no longer
                  exists, no mounting of the devices will take place,
                  no pivot_root either
                  (none of this is anyway necessary, as the resumed
                  system has all that already done)

So the only way to get a key-file within the (not mounted) rootfs after
local-top/bottom but before the resume in local-premount would be to
actually mount the root fs before.

This is however pretty dangerous.
Even if the mounting is done read-only, filesystems may perform changes
(at least btrfs does, and I think ext4 may do so too).


There was recently [0], where someone mounted the root-fs in-between
suspend and resume and got corruptions.
While it was argued that the filesystem was frozen at suspend and that
btrfs would *try* to detect (since 6.2) whether it was mounted in-
between,... it was also argued that caching (in the resumed system) may
cause corruptions.


The blockdevice would need to be blockdev --setro first, but even that
may be more complex than one might think:
Consider e.g. multi-device filesystems (again e.g. btrfs), where the
other devices are auto-detected via UUID.


So IMO, this feature cannot be safely implemented.


Maybe the only way to do it safely was a hack:
- create a swapfile in the rootfs (this is anyway required to be not
  moved)
- get it's physical offest into the device (beware: for btrfs special
  commands are needed for that)
- let cryptroot read the key raw from that offest

But, again, quite ugly and hacky.


Cheers,
Chris.



[0] https://lore.kernel.org/linux-btrfs/ba9fb1c9-ccbc-4b93-92f9-a8c17ffab7f6@business-insulting.de/