[pkg-cryptsetup-devel] Bug#959423: Bug#959423: cryptsetup-initramfs: MODULES=dep missed "ecb" since linux-5.6.0

[Guilhem Moulin]

Control: retitle -1 cryptsetup-initramfs: Can't open AES-XTS device from initrd.img-5.6.0-1-amd64 built with MODULES=dep on systems lacking AES-NI
Control: tag -1 pending

Hi,

On Sat, 02 May 2020 at 11:19:48 +0200, Adrien CLERC wrote:
> It seems that linux-5.6 changes a lot of things in crypto modules, and I
> started to add everything in /etc/initramfs-tools/modules from
> /lib/modules/5.6.0-1-amd64/kernel/crypto/.
> After bisecting the whole list, I figured out that I just need to add "ecb" in
> the list.

Thanks for the detailed report :-)  I believe this is the same issue as #883595
(and https://gitlab.com/cryptsetup/cryptsetup/issues/319 ) but it's
beyond me why the ‘xts’ doesn't depend on ‘ecb’ despite Milan's patch
being applied upstream:

    https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/crypto/Kconfig?h=v5.6.7#n435
    https://sources.debian.org/src/linux/5.6.7-1/crypto/Kconfig/#L435

But I think I now understand why no one else complained since >4.10
landed in sid.  On a minimal Buster VM running on CPUs without AES-NI
support I see:

    $ grep -Fw -e{ecb,xts} /proc/modules
    ecb 16384 4 - Live 0xffffffffc0395000
    xts 16384 2 - Live 0xffffffffc038b000

initrd.img-4.19.0-8-amd64 built with MODULES=dep *does* include ‘ecb’.

    $ lsinitramfs /boot/initrd.img-4.19.0-8-amd64 | grep -E "/kernel/crypto/(ecb|xts)"
    usr/lib/modules/4.19.0-8-amd64/kernel/crypto/ecb.ko
    usr/lib/modules/4.19.0-8-amd64/kernel/crypto/xts.ko

This is because the root FS is in ext4 format (like on your system, and
also the d-i default) and (unlike ‘xts’) the ‘ext4’ module… does depend
on ‘ecb’, at least for kernel versions between 4.10 and 4.19.  Sigh.

    $ modprobe --all --set-version=4.19.0-8-amd64 \
        --ignore-install --quiet --show-depends ext4
    […]
    insmod /lib/modules/4.19.0-8-amd64/kernel/crypto/ecb.ko 
    […]
    insmod /lib/modules/4.19.0-8-amd64/kernel/fs/ext4/ext4.ko 
    $ modprobe --all --set-version=4.19.0-8-amd64 \
        --ignore-install --quiet --show-depends xts
    […]
    insmod /lib/modules/4.19.0-8-amd64/kernel/crypto/xts.ko

(It might be that initrd.img-4.19.0-8-amd64 built MODULES=dep won't
include ‘ecb’ either on other file system types.  ‘btrfs’ for instance
doesn't depend on ‘ecb’, and without AES-NI I can't open my btrfs root
FS from a initrd.img-4.19.0-8-amd64 built with MODULES=dep.)

Now, installing current Bullseye (5.5.0-2-amd64) and sid (5.6.0-1-amd64)
kernels on that box, I see that 5.5.0-2-amd64's ‘ecb’ and ‘xts’ are both
builtin for some reason.

    $ modinfo -F filename -k 4.19.0-8-amd64 ecb xts
    /lib/modules/4.19.0-8-amd64/kernel/crypto/ecb.ko
    /lib/modules/4.19.0-8-amd64/kernel/crypto/xts.ko
    $ modinfo -F filename -k 5.5.0-2-amd64 ecb xts
    name:           ecb
    (builtin)
    name:           ecb
    (builtin)
    name:           xts
    (builtin)
    name:           xts
    (builtin)
    $ modinfo -F filename -k 5.6.0-1-amd64 ecb xts
    /lib/modules/5.6.0-1-amd64/kernel/crypto/ecb.ko
    /lib/modules/5.6.0-1-amd64/kernel/crypto/xts.ko
 
So while initrd.img-5.5.0-2-amd64 contains neither it's not an issue
since they're builtin.  On the other hand on 5.6.0-1-amd64 ‘ext4’ no
longer depends on ‘ecb’ so initrd.img-5.5.0-2-amd64 won't include it
unless it's explicitly included in /etc/initramfs-tools/modules.

    $ lsinitramfs /boot/initrd.img-5.5.0-2-amd64 | grep -E "/kernel/crypto/(ecb|xts)"
    $ lsinitramfs /boot/initrd.img-5.6.0-1-amd64 | grep -E "/kernel/crypto/(ecb|xts)"
    usr/lib/modules/5.6.0-1-amd64/kernel/crypto/xts.ko

All in all: 1/ I don't understand why #883595 isn't fixed while the
patch seems applied upstream; and 2/ for now a workaround for us is to
unconditionally copy ‘ecb’ when the host CPU lacks AES-NI support.  This
also fixes the problem with non-EXT root FS on Buster kernels.

Tested in 8 different scenarios, each with initrd.img-5.6.0-1-amd64 and
MODULES=dep: with aes-xts-plain64 and serpent-xts-plain64; with ext4 and
btrfs root file systems; on CPUs with and without AES-NI support.

Cheers,
-- 
Guilhem.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-cryptsetup-devel/attachments/20200502/91b353c8/attachment.sig>