[Bookworm] cannot unlock LUKS2 volume from initramfs

[bklop]

With RBPI OS Lite 64 based on Debian 11 (2023-05-03-raspios-bullseye-arm64-lite.img.xz) running on a RBPI CM4 I can decrypt a LUKS2 volume encrypted with Adiantum from initramfs. The procedure I follow for building initramfs:

sudo apt install busybox cryptsetup initramfs-tools

Check that the algorithms are available: cryptsetup benchmark -c xchacha20,aes-adiantum-plain64

/etc/initramfs-tools/hooks/luks_hooks

#!/bin/sh -e
PREREQS=""
case $1 in
        prereqs) echo "${PREREQS}"; exit 0;;
esac

. /usr/share/initramfs-tools/hook-functions

copy_exec /sbin/resize2fs /sbin
copy_exec /sbin/fdisk /sbin
copy_exec /sbin/cryptsetup /sbin

sudo chmod +x /etc/initramfs-tools/hooks/luks_hooks

/etc/initramfs-tools/modules

algif_skcipher
xchacha20
adiantum
aes_arm
sha256
nhpoly1305
dm-crypt

Finally, build a new initramfs: sudo -E CRYPTSETUP=y mkinitramfs -o /boot/initramfs.gz

I then update /boot/cmdline.txt etc. And during reboot I get bumped into a shell where I can unlock a volume: cryptsetup luksOpen /dev/XYZ crypted

This works fine with Debian 11. When I followed the same procedure with Bookworm (2023-12-11-raspios-bookworm-arm64-lite.img.xz) everything works fine until I boot into initramfs and try to unlock the volume, where I got this error:

_libgcc_s.so.1 must be installed for pthreadexit to work

I realized it was most likely this issue: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1960080

So I added libpthread and libgcc to my luks_hooks script:

#!/bin/sh -e
PREREQS=""
case $1 in
        prereqs) echo "${PREREQS}"; exit 0;;
esac

. /usr/share/initramfs-tools/hook-functions

copy_exec /usr/lib/aarch64-linux-gnu/libgcc_s.so.1 /usr/lib/aarch64-linux-gnu
copy_exec /usr/lib/aarch64-linux-gnu/libpthread.so.0 /usr/lib/aarch64-linux-gnu
copy_exec /sbin/resize2fs /sbin
copy_exec /sbin/fdisk /sbin
copy_exec /sbin/cryptsetup /sbin

After building a new initramfs I then checked the archive for the presence of the modules:

lsinitramfs /boot/initramfs.gz | grep -P "libgcc"
lsinitramfs /boot/initramfs.gz | grep -P "sbin/(cryptsetup|resize2fs|fdisk)"
lsinitramfs /boot/initramfs.gz | grep -P "(algif_skcipher|chacha|adiantum|aes-arm|sha256|nhpoly1305|dm-crypt)"

However, after booting into initramfs I still cannot use cryptfs to unlock the volume: Cannot use xchacha20,aes-adiantum-plain64 cipher

[XECDesign]

@tdewey-rpi, since you're looking at something similar, is this something you've stumbled upon?

[tdewey-rpi]

ACK.

I'm going to try and reproduce something along these lines now.

[tdewey-rpi]

Thanks for the report, @blkop.

I've been able to reproduce part of your failure and methodology. I can confirm I'm seeing files explicitly named in the hooks file be transferred to the resultant initramfs, but it appears that the documentation for mkinitramfs isn't aligning with observed behaviour on bookworm. Specifically, it says:

mkinitramfs will automatically detect which libraries the executable depends on and copy them to the initramfs

And sure enough, the adiantum module isn't being copied into the initramfs, while it's present on the installed system:

initramfs: usr/lib/modules/6.1.0-rpi8-rpi-2712/kernel/arch/arm64/crypto/chacha-neon.ko usr/lib/modules/6.1.0-rpi8-rpi-2712/kernel/arch/arm64/crypto/poly1305-neon.ko usr/lib/modules/6.1.0-rpi8-rpi-2712/kernel/arch/arm64/lib/xor-neon.ko usr/lib/modules/6.1.0-rpi8-rpi-2712/kernel/crypto/blake2b_generic.ko usr/lib/modules/6.1.0-rpi8-rpi-2712/kernel/crypto/xor.ko usr/lib/modules/6.1.0-rpi8-rpi-2712/kernel/lib/crypto/libarc4.ko usr/lib/modules/6.1.0-rpi8-rpi-2712/kernel/lib/crypto/libchacha.ko usr/lib/modules/6.1.0-rpi8-rpi-2712/kernel/lib/crypto/libchacha20poly1305.ko usr/lib/modules/6.1.0-rpi8-rpi-2712/kernel/lib/crypto/libcurve25519-generic.ko

Installed system: tdewey@tdewey-pi:/usr/lib/modules/6.1.0-rpi8-rpi-2712/kernel/arch/arm64/crypto $ ls aes-arm64.ko.xz aes-ce-ccm.ko.xz aes-neon-blk.ko.xz chacha-neon.ko.xz poly1305-neon.ko.xz sha256-arm64.ko.xz sha3-ce.ko.xz sha512-ce.ko.xz sm4-ce-cipher.ko.xz aes-ce-blk.ko.xz aes-ce-cipher.ko.xz aes-neon-bs.ko.xz ghash-ce.ko.xz sha1-ce.ko.xz sha2-ce.ko.xz sha512-arm64.ko.xz sm3-ce.ko.xz tdewey@tdewey-pi:/usr/lib/modules/6.1.0-rpi8-rpi-2712/kernel/arch/arm64/crypto $ ls /usr/lib/modules/6.1.0-rpi8-rpi-2712/kernel/crypto adiantum.ko.xz algif_hash.ko.xz authencesn.ko.xz cast_common.ko.xz chacha_generic.ko.xz ctr.ko.xz echainiv.ko.xz ghash-generic.ko.xz md4.ko.xz poly1305_generic.ko.xz sm4.ko.xz xcbc.ko.xz aes_generic.ko.xz algif_rng.ko.xz authenc.ko.xz cbc.ko.xz cmac.ko.xz drbg.ko.xz essiv.ko.xz hmac.ko.xz md5.ko.xz seqiv.ko.xz twofish_common.ko.xz xor.ko.xz af_alg.ko.xz algif_skcipher.ko.xz blake2b_generic.ko.xz ccm.ko.xz cryptd.ko.xz ecc.ko.xz gcm.ko.xz jitterentropy_rng.ko.xz michael_mic.ko.xz sha3_generic.ko.xz twofish_generic.ko.xz xxhash_generic.ko.xz algif_aead.ko.xz async_tx cast5_generic.ko.xz chacha20poly1305.ko.xz crypto_user.ko.xz ecdh_generic.ko.xz gf128mul.ko.xz lz4.ko.xz nhpoly1305.ko.xz sm3.ko.xz wp512.ko.xz zstd.ko.xz tdewey@tdewey-pi:/usr/lib/modules/6.1.0-rpi8-rpi-2712/kernel/arch/arm64/crypto $ ls /usr/lib/modules/6.1.0-rpi8-rpi-2712/kernel/lib/crypto libaes.ko.xz libarc4.ko.xz libchacha20poly1305.ko.xz libchacha.ko.xz libcurve25519-generic.ko.xz libcurve25519.ko.xz libpoly1305.ko.xz

Have you tried adding the kernel modules to /etc/initramfs-tools/modules? Having done so on my build, I now see those objects where I'd expect.

Just saw your modules file - the only way I can investigate further is to spin up another device, so I'll schedule this digging.

[tdewey-rpi]

Can you confirm you have libpoly1305.ko in your initramfs?

[bklop]

Yes libpoly1305.ko was copied:

pi@raspberrypi:~ $ lsinitramfs /boot/initramfs.gz | grep -P "(cryptsetup|adiantum|libpoly1305)"
usr/lib/aarch64-linux-gnu/libcryptsetup.so.12
usr/lib/aarch64-linux-gnu/libcryptsetup.so.12.9.0
usr/lib/modules/6.1.0-rpi7-rpi-v8/kernel/crypto/adiantum.ko
usr/lib/modules/6.1.0-rpi7-rpi-v8/kernel/lib/crypto/libpoly1305.ko

[bklop]

@tdewey-rpi did you get a chance to look into this?

[AutumnSpark1226]

I followed the same (I guess; this one? https://rr-developer.github.io/LUKS-on-Raspberry-Pi/) tutorial and got similar errors. Firstly, I noticed that everthing that was in /boot in the tutorial must now be in /boot/firmware. You can move /boot/initramfs.gz to /boot/firmware/initramfs.gz Secondly, on 64bit RasPi OS installations the aes_arm module doesn't exist. Instead you should use the aes_arm64 module. Manually adding libgcc_s.so.1 and libpthread.so.0 is still required.