[pkg-cryptsetup-devel] cryptsetup and hibernation

[Guilhem Moulin]

Hi Chris,

On Mon, 26 Sep 2022 at 13:15:37 +0200, Christoph Anton Mitterer wrote:
> 1) My assumption is that in general works roughly the following:
>  - The kernel freezes the processes, and stores an in a swap area (or
>    does it have to be swap?).
>  - When I start the system again, a fresh kernel is loaded from
>    wherever I boot from, e.g. some boot USB stick.
>  - I guess somewhere in between here, the initramfs must run and e.g.
>    set up dm-crypt or LVM.
>    So initramfs scrip hooks DO run before the hibernated image is
>    restored, right?

AFAIK the resume script runs at local-premount stage, so (depending on
how prerequisite are resolved) some -premount scripts might not run,
and no -bottom scripts is run.  Scripts at earlier stages do run though.

> 2) When one now encrypts the swap area to protect the memory contents
>  from the hibernated session...
>  ... is the RESUME= parameter from initramfs tools the "decrypted"
>  dm-crypt volume? Or does it have to be set to the device containing
>  the ("encrypted") dm-crypt volume?

The former, see initramfs.conf(5)

  RESUME
    Specifies the device used for suspend-to-disk (hibernation), which
    the initramfs code should attempt to resume from.  If this is not
    defined or is set to auto, mkinitramfs will automatically select the
    largest available swap partition.

>  c) Use one dm-crypt volume, and place e.g. LVM in that

That's what d-i's guided “encrypted filesystem” layout defaults to and
is what I'd personally recommend.

>  d) Use decrypt_derived.
>     My understanding is that this simply takes the hex encoded master
>     key from some other (already "opened") dm-crypt mapping as
>     passphrase for the target device (i.e. the swap area),... so it's
>     not used as the master key for the swap area, but just as the
>     keyslot passphrase (in terms of LUKS).

One downside is that it doesn't work when the volume key of the source
device is loaded in the kernel keyring (default for LUKS2).

>   e) Use a keyfile that is on another device that is "decrypted"
>      during the initramfs.

One issue is here is that the mapped device needs to be mounted for the
keyfile to be available.  The rootfs is mounted between local-premount
and local-bottom stages, so after local-premount/resume.  I guess one
could write a custom script to that effect, but that's not something
cryptsetup-initramfs supports at the moment, see
https://bugs.debian.org/774647 .

>    f) Use a swap file within the root fs (which is anyway already
>       decrypted in the initamfs).
> […]
>       => But is that supported by initramfs-tools respectively
>          cryptsetup?

Haven't tried it myself but I see there is https://bugs.debian.org/890950 .
If initramfs-tools were to support resuming from swapfiles then I don't
see why cryptsetup-initramfs shouldn't (please file a bug if it doesn't).

-- 
Guilhem.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-cryptsetup-devel/attachments/20221007/d3e06338/attachment.sig>