Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#908220: cryptsetup-initramfs: Need a clean way to force cryptsetup in initramfs
2,031 views
Skip to first unread message
Raphaël Hertzog
Sep 7, 2018, 9:50:03 AM9/7/18
to
Package: cryptsetup-initramfs
Version: 2:2.0.4-2
Severity: normal
User: de...@kali.org
Usertags: origin-kali
Hello,
In Kali we build a live image and we include cryptsetup by default so that
users can easily enable encrypted persistence following our instructions:
https://docs.kali.org/downloading/kali-linux-live-usb-persistence
However that no longer works... when the live image is created, there's
no encrypted device detected and you see that in the build log:
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.
The only way that I found to force the inclusion of cryptsetup is by
setting CRYPTSETUP=y in /etc/cryptsetup-initramfs/conf-hook. But when you do that
you get another worrying warning:
cryptsetup: WARNING: Honoring CRYPTSETUP=[y|n] will deprecated in the future.
Please uninstall the 'cryptsetup-initramfs' package if you don't want the
cryptsetup initramfs integration.
So what's the proper way to tell cryptsetup to put its files in the initramfs, no matter
what it detects, without generating a warning? Ideally I would like to
be able to do it by adding a supplementary file, not by modifying an existing
configuration file (as Debian policy forbids this).
Users very much dislike all those warnings and they report them to us in Kali... so
there must be a way to not get a warning. I would be more than happy if installing
cryptsetup-initramfs was sufficient. If the user doesn't want it in the initramfs, he
just removes the package.
Thank you for considering our request.
Related Kali tickets for reference:
https://bugs.kali.org/view.php?id=4945
https://bugs.kali.org/view.php?id=4719
-- Package-specific info:
-- System Information:
Debian Release: buster/sid
APT prefers oldoldstable
APT policy: (500, 'oldoldstable'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.16.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages cryptsetup-initramfs depends on:
ii busybox 1:1.27.2-3
ii cryptsetup-run 2:2.0.4-2
ii initramfs-tools [linux-initramfs-tool] 0.132
Versions of packages cryptsetup-initramfs recommends:
ii console-setup 1.185
ii kbd 2.0.4-4
cryptsetup-initramfs suggests no packages.
-- no debconf information
Version: 2:2.0.4-2
Severity: normal
User: de...@kali.org
Usertags: origin-kali
Hello,
In Kali we build a live image and we include cryptsetup by default so that
users can easily enable encrypted persistence following our instructions:
https://docs.kali.org/downloading/kali-linux-live-usb-persistence
However that no longer works... when the live image is created, there's
no encrypted device detected and you see that in the build log:
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.
The only way that I found to force the inclusion of cryptsetup is by
setting CRYPTSETUP=y in /etc/cryptsetup-initramfs/conf-hook. But when you do that
you get another worrying warning:
cryptsetup: WARNING: Honoring CRYPTSETUP=[y|n] will deprecated in the future.
Please uninstall the 'cryptsetup-initramfs' package if you don't want the
cryptsetup initramfs integration.
So what's the proper way to tell cryptsetup to put its files in the initramfs, no matter
what it detects, without generating a warning? Ideally I would like to
be able to do it by adding a supplementary file, not by modifying an existing
configuration file (as Debian policy forbids this).
Users very much dislike all those warnings and they report them to us in Kali... so
there must be a way to not get a warning. I would be more than happy if installing
cryptsetup-initramfs was sufficient. If the user doesn't want it in the initramfs, he
just removes the package.
Thank you for considering our request.
Related Kali tickets for reference:
https://bugs.kali.org/view.php?id=4945
https://bugs.kali.org/view.php?id=4719
-- Package-specific info:
-- System Information:
Debian Release: buster/sid
APT prefers oldoldstable
APT policy: (500, 'oldoldstable'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.16.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages cryptsetup-initramfs depends on:
ii busybox 1:1.27.2-3
ii cryptsetup-run 2:2.0.4-2
ii initramfs-tools [linux-initramfs-tool] 0.132
Versions of packages cryptsetup-initramfs recommends:
ii console-setup 1.185
ii kbd 2.0.4-4
cryptsetup-initramfs suggests no packages.
-- no debconf information
Guilhem Moulin
Sep 7, 2018, 11:00:03 AM9/7/18
to
Control: severity -1 wishlist
Control: tag -1 moreinfo
Hi Raphaël,
On Fri, 07 Sep 2018 at 15:41:26 +0200, Raphaël Hertzog wrote:
> However that no longer works... when the live image is created, there's
> no encrypted device detected and you see that in the build log:
>
> 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`?
> The only way that I found to force the inclusion of cryptsetup is by
> setting CRYPTSETUP=y in /etc/cryptsetup-initramfs/conf-hook. But when you do that
> you get another worrying warning:
>
> cryptsetup: WARNING: Honoring CRYPTSETUP=[y|n] will deprecated in the future.
> Please uninstall the 'cryptsetup-initramfs' package if you don't want the
> cryptsetup initramfs integration.
>
> So what's the proper way to tell cryptsetup to put its files in the
> initramfs, no matter what it detects, without generating a warning?
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?
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.
> Users very much dislike all those warnings and they report them to us
> in Kali... so there must be a way to not get a warning. I would be
> more than happy if installing cryptsetup-initramfs was sufficient. If
> the user doesn't want it in the initramfs, he just removes the
> package.
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.
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.
Cheers,
--
Guilhem.
Control: tag -1 moreinfo
Hi Raphaël,
On Fri, 07 Sep 2018 at 15:41:26 +0200, Raphaël Hertzog wrote:
> However that no longer works... when the live image is created, there's
> no encrypted device detected and you see that in the build log:
>
> 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.
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`?
> The only way that I found to force the inclusion of cryptsetup is by
> setting CRYPTSETUP=y in /etc/cryptsetup-initramfs/conf-hook. But when you do that
> you get another worrying warning:
>
> cryptsetup: WARNING: Honoring CRYPTSETUP=[y|n] will deprecated in the future.
> Please uninstall the 'cryptsetup-initramfs' package if you don't want the
> cryptsetup initramfs integration.
>
> So what's the proper way to tell cryptsetup to put its files in the
> initramfs, no matter what it detects, without generating a warning?
script, or by typing a `cryptsetup open --type=luks` command manually?
Or do you rely on our own (‘cryptroot’) initramfs boot script?
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.
> Users very much dislike all those warnings and they report them to us
> in Kali... so there must be a way to not get a warning. I would be
> more than happy if installing cryptsetup-initramfs was sufficient. If
> the user doesn't want it in the initramfs, he just removes the
> package.
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.
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.
Cheers,
--
Guilhem.
Raphael Hertzog
Sep 7, 2018, 5:30:04 PM9/7/18
to
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/
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`?
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?
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.
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.
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.
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/
Guilhem Moulin
Sep 7, 2018, 11:10:02 PM9/7/18
to
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.
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.
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
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.
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.
> 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.
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.
Raphael Hertzog
Sep 8, 2018, 3:50:03 AM9/8/18
to
Hi,
On Sat, 08 Sep 2018, Guilhem Moulin wrote:
> > 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.
I just checked, /proc and /sys are mounted in the chroot when live-build
installs the packages.
> 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 :-)
Hum, there's also this line which calls your hook script:
https://salsa.debian.org/live-team/live-boot/blob/master/components/9990-main.sh#L7
It's possibly to support the cryptopts= kernel command line?
Or maybe for dealing with a crypttab that the user embedded in the live
image? (one of the selling features of live-build is the possibility to
customize almost everything)
> I think you do, but probably rely on the initramfs image to contain all
> modules users might encounter in real life scenarios.
Definitely.
> > 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.
Great, thank you!
> 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
Indeed.
> 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.
The persistence feature does not allow to update the kernel/initrd. It can
be updated in the overlay file system but the kernel/initrd are booted
before the persistence partition is mounted so you always end up using
the kernel/initrd embedded in the ISO.
On Sat, 08 Sep 2018, Guilhem Moulin wrote:
> > 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.
installs the packages.
> 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 :-)
https://salsa.debian.org/live-team/live-boot/blob/master/components/9990-main.sh#L7
It's possibly to support the cryptopts= kernel command line?
Or maybe for dealing with a crypttab that the user embedded in the live
image? (one of the selling features of live-build is the possibility to
customize almost everything)
> I think you do, but probably rely on the initramfs image to contain all
> modules users might encounter in real life scenarios.
> > 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.
> 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.
be updated in the overlay file system but the kernel/initrd are booted
before the persistence partition is mounted so you always end up using
the kernel/initrd embedded in the ISO.
Guilhem Moulin
Sep 8, 2018, 9:20:03 AM9/8/18
to
Control: retitle -1 cryptsetup-initramfs: Please silence the warning when the hook config contains CRYPTSETUP="y"
On Sat, 08 Sep 2018 at 09:39:27 +0200, Raphael Hertzog wrote:
> On Sat, 08 Sep 2018, Guilhem Moulin wrote:
>> 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 :-)
>
> Hum, there's also this line which calls your hook script:
> https://salsa.debian.org/live-team/live-boot/blob/master/components/9990-main.sh#L7
>
> It's possibly to support the cryptopts= kernel command line?
> Or maybe for dealing with a crypttab that the user embedded in the live
> image? (one of the selling features of live-build is the possibility to
> customize almost everything)
> […]
>> 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.
>
> The persistence feature does not allow to update the kernel/initrd. It can
> be updated in the overlay file system but the kernel/initrd are booted
> before the persistence partition is mounted so you always end up using
> the kernel/initrd embedded in the ISO.
I see, thanks for the explanation! So we'll just silence the warning
when the hook configuration contains CRYPTSETUP="y".
--
Guilhem.
On Sat, 08 Sep 2018 at 09:39:27 +0200, Raphael Hertzog wrote:
> On Sat, 08 Sep 2018, Guilhem Moulin wrote:
>> 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 :-)
>
> Hum, there's also this line which calls your hook script:
> https://salsa.debian.org/live-team/live-boot/blob/master/components/9990-main.sh#L7
>
> It's possibly to support the cryptopts= kernel command line?
> Or maybe for dealing with a crypttab that the user embedded in the live
> image? (one of the selling features of live-build is the possibility to
> customize almost everything)
>> 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.
>
> The persistence feature does not allow to update the kernel/initrd. It can
> be updated in the overlay file system but the kernel/initrd are booted
> before the persistence partition is mounted so you always end up using
> the kernel/initrd embedded in the ISO.
when the hook configuration contains CRYPTSETUP="y".
--
Guilhem.
Raphael Hertzog
Sep 9, 2018, 5:20:03 AM9/9/18
to
On Sat, 08 Sep 2018, Guilhem Moulin wrote:
> > The persistence feature does not allow to update the kernel/initrd. It can
> > be updated in the overlay file system but the kernel/initrd are booted
> > before the persistence partition is mounted so you always end up using
> > the kernel/initrd embedded in the ISO.
>
> I see, thanks for the explanation! So we'll just silence the warning
> when the hook configuration contains CRYPTSETUP="y".
Is there a way to set this hook configuration without modifying the
> > The persistence feature does not allow to update the kernel/initrd. It can
> > be updated in the overlay file system but the kernel/initrd are booted
> > before the persistence partition is mounted so you always end up using
> > the kernel/initrd embedded in the ISO.
>
> I see, thanks for the explanation! So we'll just silence the warning
> when the hook configuration contains CRYPTSETUP="y".
/etc/cryptsetup-initramfs/conf-hook conffile (which is managed by dpkg
and that I'd rather not modify)?
Guilhem Moulin
Sep 9, 2018, 6:30:02 AM9/9/18
to
On Sun, 09 Sep 2018 at 11:08:46 +0200, Raphael Hertzog wrote:
> On Sat, 08 Sep 2018, Guilhem Moulin wrote:
>>> The persistence feature does not allow to update the kernel/initrd. It can
>>> be updated in the overlay file system but the kernel/initrd are booted
>>> before the persistence partition is mounted so you always end up using
>>> the kernel/initrd embedded in the ISO.
>>
>> I see, thanks for the explanation! So we'll just silence the warning
>> when the hook configuration contains CRYPTSETUP="y".
>
> Is there a way to set this hook configuration without modifying the
> /etc/cryptsetup-initramfs/conf-hook conffile (which is managed by dpkg
> and that I'd rather not modify)?
Nope.
> On Sat, 08 Sep 2018, Guilhem Moulin wrote:
>>> The persistence feature does not allow to update the kernel/initrd. It can
>>> be updated in the overlay file system but the kernel/initrd are booted
>>> before the persistence partition is mounted so you always end up using
>>> the kernel/initrd embedded in the ISO.
>>
>> I see, thanks for the explanation! So we'll just silence the warning
>> when the hook configuration contains CRYPTSETUP="y".
>
> Is there a way to set this hook configuration without modifying the
> /etc/cryptsetup-initramfs/conf-hook conffile (which is managed by dpkg
> and that I'd rather not modify)?
--
Guilhem.
0 new messages