Repository navigation
support dm-integrity standalone mode #7757
Description
Activity
Automated opening of dm-integrity devices cannot be done easily, as arguments are required when opening similar to
cryptsetup. The superblock of integritysetup however contains less information that a LUKS superblock, in fact not even the integrity algorithm in stored and it is critical this is correctly passed or data loss may occur.This means that, in my opinion, dm-integrity devices are not suitable for automated opening without manual definitions. I have just submitted patches to Debian implementing a
/etc/integritytabin similar fashion to/etc/crypttab, which allows for proper definition specification in configuration file.https://salsa.debian.org/cryptsetup-team/cryptsetup/-/merge_requests/22
Edit: some integration could still be useful similar to
/etc/crypttabintegration withcryptsetup{,-pre}.targetspecial built-in, though I am unsure how exactly that should work.I've taken a look the @vermeeren merge request above for debian. Unless I'm missing something, it appears that it runs a script which systematically goes through and sets up items in
/etc/integritytab. Thus, it's not udev driven. I do agree with @vermeeren that something like/etc/integritytabis needed.I've put together a proof of concept: https://github.com/tasleson/dm-integrity-standalone which consists of:
- udev rules file
- helper script and associated
/etc/integritytab - dracut module to allow for root FS support on an integrity target
From some very basic testing, it works. Before I invest more time in this I would like to get some feed back from others on this too. There is also an issue in upstream pertaining to this: https://gitlab.com/cryptsetup/cryptsetup/-/issues/385
adding: @mbroz @vojtechtrefny to the discussion. Please add others as appropriate.
I'd be happy to merge a patch that adds proper support for /etc/integritytab to systemd. It should be done the same way /etc/crypttab and /etc/veritytab area already handled. i.e. see src/veritysetup/ in our tree.
i.e. there should be a generator creating properly ordered service units, and one binary that it calls.
I've put together a proof of concept: https://github.com/tasleson/dm-integrity-standalone which consists of:
* [dracut module](https://github.com/tasleson/dm-integrity-standalone/blob/main/dracut/90dm-integrity/module-setup.sh) to allow for root FS support on an integrity targetPretty please, no more dracut modules for features that may be added in systemd via native services/generators
@oniko Trying to understand these native services/generators. It appears the systemd generator takes some input file and creates systemd unit file(s). The generators get copied into the initramfs image and systemd runs the generators before it processes the resulting unit files during early boot, before the pivot. How does the udev event from the kernel that a block device is present and blockid gets run end up causing the specific unit file(s) to be processed?
@tasleson that's handled like we do for mounts or any kinds of deps: the hypothetical
systemd-integrity@.serviceservice instances simply add dependencies on the.deviceunits that encapsulate the devices they need. The systemd unit engine then takes care of running the stuff at the right moment when the devices have shown up.
https://github.com/torvalds/linux/blob/master/Documentation/device-mapper/dm-integrity.txt
https://gitlab.com/cryptsetup/cryptsetup/blob/master/src/integritysetup.c
note that there is another way to use dm-integrity together with dm-crypt