Unlock LUKS at initrd with custom options

rinza · 05-19-2023, 11:20 AM

Hi, I'm trying to pass some options when unlocking at boot time my luks encrypted root partition. I'm running elilo and using an initram image which is in fact unlocking the device. Unfortunately nothing I've tried worked so far:

Appending options via rd.luks.options or luks.options parameter in elilo.conf:

Code:

append="... rd.luks.options=<my UUID code>=same-cpu-crypt,submit-from-crypt-cpus,no-read-workqueue,no-write-workqueue"

Adding options to /etc/crypttab, running mkinitrd again and installing the new initrd.gz into the elilo partition:

Code:

mydisk      UUID=<my UUID code>     none     same-cpu-crypt,submit-from-crypt-cpus,no-read-workqueue,no-write-workqueue

When running mkinitrd I already use the flag -T to set the discards option/--allow-discards but i couldn't find in the manual any information on how to add other options. Apparently, Arch uses /etc/crypttab.initramfs as an information resource when building its initrd image, but that don't work in slack. I'd like to know what is the equivalent in Slackware or how to accomplish that. Thanks!

gouttegd · 05-20-2023, 05:29 AM

Quote:

Originally Posted by rinza

Appending options via rd.luks.options or luks.options parameter in elilo.conf

I had never heard of these options until today, but a quick search suggests they are specific to systemd-cryptsetup-generator(8), so it’s not surprising they wouldn’t work on Slackware.

Quote:

Adding options to /etc/crypttab, running mkinitrd again

As far as I know mkinitrd does not use /etc/crypttab.

Quote:

I'd like to know what is the equivalent in Slackware or how to accomplish that.

I am not aware of a mechanism to pass generic options to cryptsetup in the initial ram disk.

What you could do is modify the contents of the initial ram disk “skeleton” that mkinitrd uses to build the actual ram disk, and which is located in /usr/share/mkinitrd/initrd-tree.tar.gz. Extract that archive in a temporary tree somewhere, edit the contents of the init script to add the options you want to the cryptsetup call, then archive the initrd tree again and have mkinitrd build a new ram disk.

rinza · 05-20-2023, 09:34 AM

Quote:

Originally Posted by gouttegd

I had never heard of these options until today, but a quick search suggests they are specific to systemd-cryptsetup-generator(8), so it’s not surprising they wouldn’t work on Slackware.

Oh, I thought all options in append were recognized by any bootloader, but what you pointed out, now it makes sense.

Quote:

Originally Posted by gouttegd

What you could do is modify the contents of the initial ram disk “skeleton” that mkinitrd uses to build the actual ram disk, and which is located in /usr/share/mkinitrd/initrd-tree.tar.gz.

I intended doing something like that, but inspecting the tree I got confused where should I put the options. First idea was into its etc/crypttab, but inspecting the my generated initrd-tree there is no crypttab file, so it must be using some other mechanism to load the options. For example, discards options are loaded with this initrd but I couldn't find via grep any string reference for it in the files of the generated initrd-tree.

Didier Spaier · 05-20-2023, 04:12 PM

In the previous Slint version I had patched mkinitrd to handle such a use case (see attached patch).

Now I use dracut instead, as it handles that without any modification, as you can see lines 3052-3060 of the script functions of the Slint installer. We do not need to store the key elsewhere except in case the user wants an additional partition in which case we store it in /etc/crypttab (lines 1814-1819). These settings allow a full drive encryption (minus the ESP which contains only the EFI boot manager grub.efi)

gouttegd · 05-20-2023, 04:41 PM

Quote:

Originally Posted by rinza

I intended doing something like that, but inspecting the tree I got confused where should I put the options.

The easiest, “quick-and-dirty” way is to put them directly in the initrd’s init script, where it calls cryptsetup:

Code:

/sbin/cryptsetup ADD-YOUR-OPTIONS-HERE ${LUKSOPTS} ${LUKSKEY} luksOpen ${LUKSDEV} ${CRYPTDEV} </dev/tty-1 >/dev/tyy0 2>&1

(Beware that there are two distinct calls to cryptsetup, an early one and a deferred one.)

The problem with that approach is that every time you’ll want to change those options again, you’ll have to again hack the initrd skeleton. So while you’re at it, you might want to take the time to do things in such a way that you could later change the options without having to edit the init script. Your call.

It goes without saying that messing with the init script of the initial ram disk could cause your system to fail to boot if you do it wrong. Whatever you do, I strongly suggest to always keep a LILO entry associated with an unmodified initrd.

rinza · 05-20-2023, 06:06 PM

So it is done in this init file, thanks Didier and gouttegd! Ok, I will study the script and try to implement some simple retrieving of options from /etc/crypttab.initramfs, emulating the Arch strategy. I'll post the code snippet here later if it works (I'll probably start doing it tomorrow, if someone has already done exactly that it would be nice to post here

)

edit: just found out that my grep "discard" on the initrd-tree didn't really missed the "discard" text, it was stuck for some reason at initrd-tree/dev, if you pass --exclude-dir=dev and -I it will complete the grep and match the init file with --allow-discards option!

rinza · 05-20-2023, 08:56 PM

Ok, so I made a potential patch for this but couldn't figure out how to copy local /etc/crypttab.initramfs into /boot/initrd-tree/ during building initird.gz. Any ideas how to do that?

The idea is creating a crypttab.initramfs file with each device in a line along the options, separated by space. The options should be separated with commas only and be in the exact format to be used as argument for cryptsetup like this:

example of /etc/crypttab.initramfs:

Code:

/dev/sda1 --perf-same_cpu_crypt,--perf-submit_from_crypt_cpus,--perf-no_read_workqueue,--perf-no_write_workqueue
/dev/sdb1     --perf-same_cpu_crypt,--perf-submit_from_crypt_cpus

init.patch:

Code:

--- /boot/initrd-tree/init	2023-03-31 14:13:27.000000000 -0300
+++ init	2023-05-20 22:43:50.318346790 -0300
@@ -79,6 +79,7 @@
 LUKSDEV=$(cat /luksdev)
 LUKSTRIM=$(cat /lukstrim 2>/dev/null)
 LUKSKEY=$(cat /lukskey)
+LUKSNEWOPTS=$(cat /crypttab.initramfs 2>/dev/null)
 RESUMEDEV=$(cat /resumedev)
 WAIT=$(cat /wait-for-root)
 KEYMAP=$(cat /keymap)
@@ -241,12 +242,22 @@
         else
           LUKSOPTS=""
         fi
+
+	
+	NEWOPT=$(echo "$LUKSNEWOPTS" | grep -sw "$LUKSDEV")
+	if [ ! -z "$NEWOPT" ]; then
+          # Get comma separated options for the device
+          NEWOPT=$(echo $NEWOPT | tr -s ' ' '\t' | cut -f2 -d$'\t')
+          # Turn into space separated list
+          NEWOPT=$(echo $NEWOPT | tr -s ',' ' ')
+	fi
+
         if [ -z "${LUKSOPTS}" ]; then
           echo "Unlocking LUKS encrypted device '${LUKSDEV}' as luks mapped device '$CRYPTDEV':"
         else
           echo "Unlocking LUKS encrypted device '${LUKSDEV}' as luks mapped device '$CRYPTDEV' with '$LUKSOPTS':"
         fi
-        /sbin/cryptsetup ${LUKSOPTS} ${LUKSKEY} luksOpen ${LUKSDEV} ${CRYPTDEV} </dev/tty0 >/dev/tty0 2>&1
+        /sbin/cryptsetup ${NEWOPT} ${LUKSOPTS} ${LUKSKEY} luksOpen ${LUKSDEV} ${CRYPTDEV} </dev/tty0 >/dev/tty0 2>&1
         if [ "$ROOTDEV" = "$LUKSDEV" -o "$ROOTDEV" = "$CRYPTDEV" ] ; then
           ROOTDEV="/dev/mapper/$CRYPTDEV"
         fi

edit: I know that injecting parameters from some file into a command directly like this is dangerous without parsing for malicious code. But this is a quick and dirty fix. Still, I think a parsing routine would be interesting if someone with time could develop it.

rinza · 05-20-2023, 09:40 PM

Ok, I found that mkinitrd is in fact a bash script not a binary. So here is a patch for adding /etc/crypttab.initramfs into the /boot/initrd-tree:

mkinitrd:

Code:

--- /sbin/mkinitrd	2023-03-31 14:13:27.000000000 -0300
+++ mkinitrd	2023-05-20 23:32:01.386781260 -0300
@@ -561,6 +561,11 @@
   echo $LUKSTRIM > $SOURCE_TREE/lukstrim
 fi
 
+# Check for crypttab.initramfs
+if [ -s /etc/crypttab.initramfs ]; then
+  cat /etc/crypttab.initramfs 1> $SOURCE_TREE/crypttab.initramfs 2> /dev/null
+fi
+
 # If LUKSKEY was set in the config file, then give it a warm welcome:
 if [ ! -z "$LUKSKEY" ]; then
   # $SOURCE_TREE/wait-for-root may have been configured earlier in the script,

Once again, I know this is very dangerous, messing with these files without some security parsing, but until an official solution emerges I think it is a dirty fix.

Didier Spaier · 05-21-2023, 04:15 AM

Quote:

Originally Posted by Didier Spaier

We do not need to store the key elsewhere except in case the user wants an additional partition in which case we store it in /etc/crypttab (lines 1814-1819).

Correction: I forgot to mention that we always store a keyfile in /etc/keys during installation if user choose to encrypt the drive. This allows to gather the key and include it in the new initramfs upon a kernel upgrade, see the function installkeyfile lines 1707-1735 of the script functions.

rinza · 05-21-2023, 07:34 AM

Quote:

Originally Posted by Didier Spaier

Now I use dracut instead, as it handles that without any modification, as you can see lines 3052-3060 of the script functions of the Slint installer.

I see you are using the rd.luks.xxx arguments there, so is it parsed by Slackware or is Slint running some kind of implementation of systemd-cryptsetup-generator?

Didier Spaier · 05-21-2023, 11:21 AM

Quote:

Originally Posted by rinza

I see you are using the rd.luks.xxx arguments there, so is it parsed by Slackware or is Slint running some kind of implementation of systemd-cryptsetup-generator?

Neither. It is parsed by dracut as stated by "man dracut.cmdline" that you can read online.

rinza · 05-21-2023, 11:43 AM

Quote:

Originally Posted by Didier Spaier

Neither. It is parsed by dracut as stated by "man dracut.cmdline" that you can read online.

Ah, I see. Ive never heard of dracut before, interesting.

Didier Spaier · 05-21-2023, 11:55 AM

Quote:

Originally Posted by rinza

Ah, I see. Ive never heard of dracut before, interesting.

There is an article about it on the ArchWiki.