Discussion:
Bug#948593: Unable to open LUKS device (error allocating crypto tfm) for aes / cbc-essiv:sha256 sha1 LUKS header
(too old to reply)
Didier 'OdyX' Raboud
2020-01-10 17:00:01 UTC
Permalink
Package: src:linux
Followup-For: Bug #948593

Of course, just after filing this bug, I remembered I could at least try with
MODULES=most, which allowed me to boot. So the problem can be more accurately
described as "some modules gone missing from 5.4+ kernel's initramfs'es with
MODULES=dep for aes/cbc-essiv:sha256 LUKS header".

From the initramfs' modules' list; the diff (between 5.4.0-1 with MODULES=dep
and 5.4.0-2 with MODULES=most) is attached.

I don't really know if this is a src:linux problem, a src:initramfs-tools
problem (although I'm also affected by #948257) or a missing configuration in my
/etc/crypttab, but there's a regression somewhere!

Cheers, and thanks for your help!
OdyX

-- System Information:
Debian Release: bullseye/sid
APT prefers buildd-unstable
APT policy: (990, 'buildd-unstable'), (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (100, 'experimental'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.UTF-8 (charmap=UTF-8), LANGUAGE=fr_CH:fr (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Guilhem Moulin
2020-01-11 13:10:01 UTC
Permalink
Hi OdyX,
From diffing the initramfs'es, I see that kernel/arch/x86/crypto/aes-x86_64.ko
was present in 5.3.0-3 kernels, but not present anymore in 5.4.0-1 or 5.4.0-2
kernels.
kernel/arch/x86/crypto/aes-x86_64.ko isn't in 5.4.0-2's module tree. Do
you build the initramfs with MODULES="most", MODULES="dep", or something
else? Looking at the output of

cut -d" " -f1 /proc/modules | xargs -d"\\n" /sbin/modinfo -F filename | grep /crypto/

before and after (formatting and) opening a cbc-essiv:sha256 device
with

$ cryptsetup luksFormat --type luks1 --cipher aes-cbc-essiv:sha256 --hash sha1 /tmp/disk.img <<<test
$ cryptsetup luksOpen --debug /tmp/disk.img test_crypt <<<test

I see that the ‘essiv’ module (and its dependency ‘authenc’) has been
loaded. Is that module missing from your 5.4.0-2 initramfs? If so,
could you please add it to ‘/etc/initramfs-tools/modules’, re-generate
the initramfs and see if that helps?

Devices formatted since 2:1.6.1-1 (June 2013) use XTS by default and
AFAICT aren't affected. For other devices and when the initramfs is built
with MODULES!="most" I guess we should change populate_CRYPTO_MODULES() so
the ivmode is appended too, not only cipher+chainmode+ivopts.

Cheers,
--
Guilhem.
Didier 'OdyX' Raboud
2020-01-13 08:00:02 UTC
Permalink
Hello Guilhem,
Post by Guilhem Moulin
From diffing the initramfs'es, I see that
kernel/arch/x86/crypto/aes-x86_64.ko was present in 5.3.0-3 kernels, but
not present anymore in 5.4.0-1 or 5.4.0-2 kernels.
kernel/arch/x86/crypto/aes-x86_64.ko isn't in 5.4.0-2's module tree. Do
you build the initramfs with MODULES="most", MODULES="dep", or something
else? Looking at the output of
cut -d" " -f1 /proc/modules | xargs -d"\\n" /sbin/modinfo -F filename | grep /crypto/
before and after (formatting and) opening a cbc-essiv:sha256 device
with
$ cryptsetup luksFormat --type luks1 --cipher aes-cbc-essiv:sha256
--hash sha1 /tmp/disk.img <<<test $ cryptsetup luksOpen --debug
/tmp/disk.img test_crypt <<<test
I see that the ‘essiv’ module (and its dependency ‘authenc’) has been
loaded. Is that module missing from your 5.4.0-2 initramfs? If so,
could you please add it to ‘/etc/initramfs-tools/modules’, re-generate
the initramfs and see if that helps?
It helps. :-)

I can confirm that adding 'essiv' at the tail of ‘/etc/initramfs-tools/
modules’ is sufficient to let me unlock my LUKS volume with MODULES="dep"-
built initramfs.

Thanks for the hint!
Post by Guilhem Moulin
Devices formatted since 2:1.6.1-1 (June 2013) use XTS by default and
AFAICT aren't affected. For other devices and when the initramfs is built
with MODULES!="most" I guess we should change populate_CRYPTO_MODULES() so
the ivmode is appended too, not only cipher+chainmode+ivopts.
https://sources.debian.org/src/cryptsetup/2:2.2.2-1/debian/initramfs/hooks/
cryptroot/?hl=318#L318

That'd be useful yes!

Cheers,

OdyX
Guilhem Moulin
2020-01-14 01:40:01 UTC
Permalink
Control: retitle -1 cryptsetup-initramfs: Can't open aes-cbc-essiv:sha256 dm-crypt targets with a 5.4 kernel and an initramfs built with MODULES=dep
Control: found -1 2:1.6.6-5
Control: tag -1 pending

Hi,
Post by Guilhem Moulin
Devices formatted since 2:1.6.1-1 (June 2013) use XTS by default and
AFAICT aren't affected. For other devices and when the initramfs is built
with MODULES!="most" I guess we should change populate_CRYPTO_MODULES() so
the ivmode is appended too, not only cipher+chainmode+ivopts.
https://sources.debian.org/src/cryptsetup/2:2.2.2-1/debian/initramfs/hooks/cryptroot/?hl=318#L318
That'd be useful yes!
This should fix it: https://salsa.debian.org/cryptsetup-team/cryptsetup/commit/6b75e4bda81ec63f42c46368e7b078c827ef0aad .
AFAICT all versions of the initramfs hook are affected since 2006 (but
only on 5.4 kernels and for initramfs images built with MODULES=dep).

Kernel modules named after the IV generator are now added to the
initramfs image when found under /kernel/crypto/. If there is no
matching modules (for instance with aes-cbc-essiv:sha256 on older
kernels, or with aes-xts-plain64 on any kernel) the initramfs image
should be identical.

Cheers,
--
Guilhem.
Loading...