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

[Guilhem Moulin]

Control: tag -1 - moreinfo

On Fri, 07 Sep 2018 at 23:22:45 +0200, Raphael Hertzog wrote:
> 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.

It might be related to #902123 though.  Since 2:2.0.3-2 our initramfs
hook needs proc(5) and sysfs(5) resp. mounted to /proc and /sys.  I'm
not sure about live-build, but d-i currently doesn't do that at
finish-install stage.

>> 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

Hmm, so you don't really need the integration provided by
cryptsetup-initramfs then; you want the cryptsetup binary and its shared
library to be included to the initramfs image, but aren't using any of
our boot scripts?  If that's indeed the case then you could as well
bypass our hooks and write your own to add said binaries and modules :-)

>> 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.

I think you do, but probably rely on the initramfs image to contain all
modules users might encounter in real life scenarios.

At initramfs stage one doesn't have access to the modules of the main
system; any module required for a device to be present at this stage
(USB devices, SATA devices, crypt devices, whatever) *has to* be added
to the image.  MODULES="most" is often enough but not always, and
sometimes extra modules need to be added, either manually or imported by
another hook.

>> 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.

It makes sense indeed, we can do that.

> 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.

That sounds like quite a brittle assumption IMHO.  cryptsetup's default
cipher/mode for LUKS changed over time, and they will keep doing so.
For instance upstream changed from cbc-essiv:sha256 to aes-xts-plain64
with 1.6.0; these ciphers require different sets of modules, and on a
CPU without AES-NI one can't unlock a volume formatted with 1.6.0's new
default options from an initramfs lacking the ‘xts’ module.

Similarly when luks2 and AEAD become the default, to unlock such volumes
one will need libgcc and dm-integrity to be included in the initramfs
image.  The latter is currently not included by default, even when the
image is generated with MODULES="most"…

While our hook adds a basic subset of crypto modules to the initramfs,
which are matching the *current* cryptsetup's default ciphers, there is
no guaranty that an initramfs image built today contains all the ciphers
to unlock a crypto volume formatted tomorrow (or yesterday).  We never
claimed this, and that's why our hook script relies on open mapped
devices and the corresponding crypttab(5) entries to determine what's
needed to unlock them.

Maybe it's not relevant for a live ISO image, where 1/ the cryptsetup
binary used to format the drive, 2/ the one from the initramfs, and 3/
the one from the main system, are all the same; but that “USB
Persistence” feature seems to be a union a mount so I guess it's
possible to upgrade, fall out of sync, and get an unbootable system if
one is unlucky.

-- 
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/20180908/2ad244b1/attachment.sig>