[pkg-cryptsetup-devel] Bug#908220: Bug#908220: cryptsetup-initramfs: Need a clean way to force cryptsetup in initramfs

[Raphael Hertzog]

Hi,

On Fri, 07 Sep 2018, Guilhem Moulin wrote:
> >   update-initramfs: Generating /boot/initrd.img-4.17.0-kali3-amd64
> >   cryptsetup: WARNING: Couldn't determine root device
> >   cryptsetup: ERROR: Couldn't resolve device /dev/sdb4
> >   cryptsetup: WARNING: The initramfs image may not contain cryptsetup binaries 
> > 	nor crypto modules. If that's on purpose, you may want to uninstall the 
> > 	'cryptsetup-initramfs' package in order to disable the cryptsetup initramfs 
> > 	integration and avoid this warning.
> 
> Do you have the proc(5) and sysfs(5) pseudo-filesystems respectively
> mounted to /proc and /sys?  The “WARNING: Couldn't determine root
> device” suggests it's either not the case, or that the file system
> holding / is not backed up by a block device (eg, ZFS).  Can you share
> what /proc/mounts contains before you type `update-initramfs -u`?

I don't think this is relevant, at this point live-build is just
installing packages in a chroot. The end result is an ISO image...
there's no associated device. It can be copied on a DVD or burnt
on an USB key.

> How do you unlock that disk at initramfs stage?  Using a custom boot
> script, or by typing a `cryptsetup open --type=luks` command manually?
> Or do you rely on our own (‘cryptroot’) initramfs boot script?

live-boot rebuilds the initramfs image and hooks itself in the process,
it does manually open all luks containers:

open_luks_container() is the way to open the luks partitition:
https://salsa.debian.org/live-team/live-boot/blob/master/components/9990-misc-helpers.sh#L830

find_persistence_media() is the place where all partititions
are scanned for luks:
https://salsa.debian.org/live-team/live-boot/blob/master/components/9990-misc-helpers.sh#L1043

> Adding the cryptsetup binaries to the initramfs image might not be
> sufficient, especially if the initramfs image isn't compiled with
> MODULES="most".  That's why we warn the user that modules might me
> missing if auto detection fails to determine which device(s) need to be
> unlocked at initramfs stage and/or which modules are required to map the
> crypt devices.  Failure to unlock the root device is arguably worse than
> false positives.

This is not so much a problem for us because the use case is always to add
an encrypted partition after the ISO image copied onto an USB key. We
don't need any special driver.

> Before the package split (cf. #783297 and #813220) users could add
> CRYPTSETUP=n to disable initramfs integration.  As the warning suggests
> we're deprecating this; we'll remove the warning once buster is
> released, instead installing cryptsetup-initramfs will silently trigger
> execution of our initramfs hook scripts.

Can't you just trigger the warning only when CRYPTSETUP=n? If it's set to "y",
it doesn't match the old use case... it just means that we want to enable
it.

> 
> But for said hook scripts to work reliably, the device needs to present
> and mapped (unlocked) when the initramfs image is built.  Otherwise, as
> I wrote above, the hook doesn't know which crypto modules need to be
> present in the image.  Moreover, the device needs to have an entry in
> the crypttab(5) to pass suitable options (--type, --header, etc.) to
> `cryptsetup open`.  In order to force a device to be considered at
> initramfs stage, you can add the ‘initramfs’ to its crypttab(5) entry.

We don't have any crypttab in our case, we just scan all partitions and
try opening them with default options (just passing the key). We can't
have any device present when the initramfs is generated... because the
encrypted partition gets added later by the user, not by us who are
generating the ISO image. We just want that cryptsetup continues to use
the sane defaults that it has been using up to now and we want to be able
to force its installation into the initrd.

If options were one day really needed, we would alter live-boot to
forward options supplied by the user on the kernel command line, but we
never had the case up to now.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 523 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-cryptsetup-devel/attachments/20180907/08a863b6/attachment.sig>