Arch Linux

LunarLambda

Member

Registered: 2021-08-02

Posts: 15

[SOLVED?]Can't get sd-encrypt hook to unlock root with detached header

I've been trying to set up a new security scheme for my machine using LUKS2, LVM, and a USB Boot-key.

Because of configuration and support woes around GRUB, I want to boot using a unified kernel image.

Here's what I got:

USB Flash drive "Bootkey":
512 MB ESP Partition: Holds Kernel image
4G LUKS2+ext2 Partition: Holds Keyfile and LUKS Header for /

Disk:
LVM on LUKS2, with ext4-formatted 2 LVs: root, and home

Relevant UUIDs:

Bootkey LUKS2 container: 8b081238-d1eb-4b25-99bd-1f98d7002084
Bootkey ext2 filesystem: 38bee469-f354-4b7d-8ce4-41b7bb87539d

Disk LUKS2 container: 111b21fc-afa0-4ca9-aefa-a4b73763de97
Disk LVM: VUd1WD-aTRK-ubCy-QWt4-rEKP-a8Yv-IAQk99
Disk root filesystem: 281458c7-5f7a-4fe0-8636-d23191c0cba5
Disk home filesystem:  f93bda91-bbf4-4f2a-8fe0-a4000fd65fab

Hooks in /etc/mkinitcpio.conf:

base systemd udev autodetect modconf block sd-vconsole sd-encrypt lvm2 filesystems keyboard fsck

/etc/fstab:

UUID=281458c7-5f7a-4fe0-8636-d23191c0cba5	/         	ext4      	rw,relatime	0 1
UUID=f93bda91-bbf4-4f2a-8fe0-a4000fd65fab	/home     	ext4      	rw,relatime	0 2

And this is where I get stuck.
I've mainly been going off of https://wiki.archlinux.org/title/Dm-cry … figuration, and a lot of the information seems conflicting or outdated.

First I tried to put bootkey and disk in /etc/crypttab.initramfs, that didn't work at all. No matter what I never got it to prompt for the bootkey password.
So instead I tried modifying the kernel commandline using the rd.luks parameters described in systemd-cryptsetup-generator(8):

loglevel=3 rw root=/dev/testing/root
rd.luks.name=8b081238-d1eb-4b25-99bd-1f98d7002084=bootkey
rd.luks.name=111b21fc-afa0-4ca9-aefa-a4b73763de97=cryptlvm
rd.luks.options=111b21fc-afa0-4ca9-aefa-a4b73763de97=header=/header.img:UUID=38bee469-f354-4b7d-8ce4-41b7bb87539d
rd.luks.key=111b21fc-afa0-4ca9-aefa-a4b73763de97=/keyfile.bin:UUID=38bee469-f354-4b7d-8ce4-41b7bb87539d

And this finally let me unlock the bootkey, but no matter what I tried, I still could get it to properly unlock and mount cryptlvm.
I think I might need rd.luks.data since the systemd-cryptsetup-generator manpage mentions it specifically for detached LUKS headers, but I didn't understand what I was actually supposed to specify, and always ended up with a start job for /dev/testing/root, or /dev/disk/by-uuid/111b21fc-afa0-4ca9-aefa-a4b73763de97, which would always time out and drop me into emergency mode (which I can't use since it claims the root account is locked, even though it isn't)

Also of note is that initially I wanted to use a plain dm-crypt for the bootkey, during testing I switched over to LUKS since systemd seems to have some issues with plain dm-crypt devices, and I wanted to rule that out as the cause of the problem.

I tried different ways to specify root, I tried different ways to specify the location of the header and keyfile, nothing worked, and from reading the wiki and talk pages and manuals I'm out of ideas.
I even thought it might've been the use of lvm2 instead of sd-lvm2 in initcpio, but they're the exact same file..

EDIT: On an existing, running system, I tried to setup /etc/crypttab and then start the corresponding systemd-cryptsetup@name services manually, which worked perfectly:

bootkey	UUID=8b081238-d1eb-4b25-99bd-1f98d7002084	none	luks
cryptlvm UUID=111b21fc-afa0-4ca9-aefa-a4b73763de97	/keyfile.bin:/dev/mapper/bootkey	luks,header=/header.img:/dev/mapper/bootkey

However: @bootkey must be started BEFORE @cryptlvm, or it doesn't work. I don't know to accomplish this with /etc/crypttab.initramfs, the order in the file didn't seem to match the order in which services are launched...

Last edited by LunarLambda (2021-08-02 14:39:35)

LunarLambda

Member

Registered: 2021-08-02

Posts: 15

Re: [SOLVED?]Can't get sd-encrypt hook to unlock root with detached header

Okay I solved it but please, please someone explain to me why this works.

I did the following:

/etc/crypttab.initramfs:

bootkey	UUID=8b081238-d1eb-4b25-99bd-1f98d7002084	none	luks
cryptlvm UUID=111b21fc-afa0-4ca9-aefa-a4b73763de97	/keyfile.bin:/dev/mapper/bootkey	luks,header=/header.img:/dev/mapper/bootkey

Kernel command line:

root=/dev/testing/root
rd.luks.uuid=8b081238-d1eb-4b25-99bd-1f98d7002084
rd.luks.uuid=111b21fc-afa0-4ca9-aefa-a4b73763de97

Why does this very specific configuration work and do things in the correct order
And nothing else did. I do not comprehend this. And I desperately want to know.

Does the sd-encrypt hook guarantee rd.luks devices will be unlocked in the order they're listed, whereas a standalone crypttab doesn't?
I don't get it, I really don't. Is there a better way to set this up? I feel like this is working by pure chance and not much else...

Last edited by LunarLambda (2021-08-02 14:42:11)