[pkg-cryptsetup-devel] cryptsetup and hibernation

[Christoph Anton Mitterer]

Hey Guilhem.


Thanks for your reply back then... took me a while to come back to this
;-)


On Fri, 2022-10-07 at 14:20 +0200, Guilhem Moulin wrote:
> >    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.

Am I right that:
- cryptsetup always tries to bring up the root-, resume- (if any was
  detected) and any "initramfs"-crypttab-option-marked devices at
  either local-top or local-block stages[0].
  -> thus before, the resume script is run?

- noearly-crypttab-option is not used for the initramfs at all, so no
  difference at when the device is opened?

- initramfs-crypttab-option doesn't make a difference at which stage
  the dm-crytp device is opened in the initamfs, just *that* it is.

- The order in which cryptsetup devices are unlocked/"decrypted"
  depends on their order in crypttab,...
  So it simply takes any root, resume, initramfs-option devices from
  that and opens them in their order from crypttab?
  Or does it always open root first?


Less cryptsetup specific:
- AFAIU, local-premount/resume is - if there is a resume - the last
  script run from the initramfs, as the system gets then completely
  replaced.
  So the initramfs will not even mount the rootfs anymore (in the
  replacement it's already mounted).



> >  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.

Well in principle it sounds (and is) nice, but adds one further block
layer... just for the passphrase-issue.
Plus it also costs the whole space just to keep the extra resume swap -
which, with a swapfile can be more quickly removed/added (on
demand[1]).


> >  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).

Ah, damn... completely forgot about that (and I wouldn't want to use --
disable-keyring and needlessly deviate from upstream defaults).


> >   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.

Yeah, I didn't realise this when writing back then, but noticed it when
looking at it again now.


>   I guess one
> could write a custom script to that effect

You mean something that temporarily mounts the rootfs just to get the
key?
I think that would actually be dangerous, see at:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774647#76
where I've just described why.


> >    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 .

Thanks for the pointer. I've commented there back then, but no real
move forward.
The initramfs-tools code seems a bit... uhm... "complex" (and perhaps
messy) there.

What did however work in a simple test setup of mine:

- btrfs root fs on top of LUKS
- swapfile on top of btrfs (there are new btrfs filesystem mkswapfile
  and btrfs inspect-internal map-swapfile commands for that)
- not using initramfs-tools RESUME[2]
- setting resume= and resume_offset= at the kernel command line


Thanks,
Chris.




[0] btw, maybe it would make sense to rename
    local-bottom/cryptgnupg-sc, local-bottom/cryptopensc,
    local-bottom/cryptroot to *-cleanup?

[1] Guess it might be even possible to create and activate it (and
    update grub's resume and resume_offset with new values ) just
    before going into hibernation via systemd's systemd-
    hibernate.service.
    Cleanup after resume may be more difficult, because I guess Debian
    won't use systemd-hibernate-resume at .service (as resume happens via
    initramfs not systemd).

[2] Well actually I set RESUME=none, because I think any form of auto-
    detecting the resume device might be a security hole:
    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020713