# Mender + dm-verity integration **URL:** \ **Category:** General Discussions\ **Tags:** yocto, nxp, toradex\ **Created:** [January 9, 2024, 8:47pm UTC](https://hub.mender.io/t/mender-dm-verity-integration/6452 "2024-01-09T20:47:38Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![Globulo](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/globulo/32/2529_2.png) [@Globulo](https://hub.mender.io/u/Globulo)\ **Post date:** [January 9, 2024, 8:47pm UTC](https://hub.mender.io/t/mender-dm-verity-integration/6452/1 "2024-01-09T20:47:38Z")
Hi, We are improving the security of a system based on a Toradex Verdin iMX8M Mini module. We have been successfully using mender in this system for a long time previously. But now, as part of the security hardening we have integrated dm-verity to avoid modifications of the rootfs. Our problem is the device-mapper used by dm-verity, regardless of the physical device being used, mounts the rootfs from device /dev/dm-0 and this confuses the mender-client, as expected. This is the result of mount: ` /dev/dm-0 on / type ext4 (ro,relatime)` And this is the result of the command “stat /” ```auto stat / File: / Size: 4096 Blocks: 8 IO Block: 4096 directory Device: 253,0 Inode: 2 Links: 21 Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2024-01-06 00:21:16.000000000 +0100 Modify: 2024-01-06 00:21:16.000000000 +0100 Change: 2024-01-06 00:21:16.000000000 +0100 Birth: 2024-01-06 00:21:16.000000000 +0100 ``` This is the log output from mender when I try to install the artifact: ```auto root@XXXX-00005003:~# mender install /tmp/usb/XXXX-dev-01.00-20240107215702.mender INFO[0000] Loaded configuration file: /var/lib/mender/mender.conf INFO[0000] Loaded configuration file: /etc/mender/mender.conf INFO[0000] 'UpdateControlMapExpirationTimeSeconds' is not set in the Mender configuration file. Falling back to the default of 2*UpdatePollIntervalSeconds INFO[0000] 'UpdateControlMapBootExpirationTimeSeconds' is not set in the Mender configuration file. Falling back to the default of 600 seconds INFO[0000] Mender running on partition: /dev/dm-0 INFO[0001] Mender running on partition: /dev/dm-0 INFO[0001] Start updating from local image file: [/tmp/usb/XXXX-dev-01.00-20240107215702.mender] Installing Artifact of size 394884608... INFO[0001] No public key was provided for authenticating the artifact ERRO[0001] Download failed: Payload: can not install Payload: XXXX-dev-01.00-verdin-imx8mm.ext4: Active root partition matches neither RootfsPartA nor RootfsPartB. ERRO[0001] Payload: can not install Payload: XXXX-dev-01.00-verdin-imx8mm.ext4: Active root partition matches neither RootfsPartA nor RootfsPartB. ``` As you can see, it detects /dev/dm-0 and obviously it doesn’t match RootfsPartA neither RootfsPartB that are defined as /dev/mmcblk0p2 and /dev/mmcblk0p3. Using commands like dmsetup is possible to figure out the physical physical device attached to the dm device: ```auto root@XXXX-00005003:~# dmsetup deps -o devname verity: 1 dependencies : (mmcblk0p2) ``` **My question is:** What would you consider the best approach to update the mender client so it notices the device is provided by device-mapper and tries to look “deeper” to find the real device? Is there a standard way that we could use? or we have to simply patch mender-client? We would be more than happy to contribute the patch to the community so this is why I ask for “best approach”. ---
**Author:** ![TheYoctoJester](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/theyoctojester/32/1444_2.png) [@TheYoctoJester](https://hub.mender.io/u/TheYoctoJester)\ **Post date:** [January 11, 2024, 1:56pm UTC](https://hub.mender.io/t/mender-dm-verity-integration/6452/2 "2024-01-11T13:56:42Z")
Hi @Globulo, Hmm, good question. Just guessing would be a custom fork of the rootfs update module. Since the new C+±Client, this is a separate Update Module anyways, so modifying if for that use case should not be super complicated. Please see [mender/support/modules/rootfs-image at master · mendersoftware/mender · GitHub](https://github.com/mendersoftware/mender/blob/master/support/modules/rootfs-image) Greets, Josef ---
**Author:** ![Globulo](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/globulo/32/2529_2.png) [@Globulo](https://hub.mender.io/u/Globulo)\ **Post date:** [January 11, 2024, 8:39pm UTC](https://hub.mender.io/t/mender-dm-verity-integration/6452/3 "2024-01-11T20:39:55Z")
Hi, I’ve reviewed the current code of our mender client in Go (3.5.1 runtime: go1.17.13) and I can more or less see how it resolves the rootfs, etc. I’ve added an ugly patch as a PoC to solve the situation. We could live with it but I’m interested in your suggestion. So I have some questions: - Is the new c++ client already “production ready”? My understanding is, its still an alpha. - What you had shown me is a shellscript. Is the new client handling the whole rootfs update as an external module (shellscript) as opossed to current client doing it from GO code?. - Is it possible to update the rootfs as a shellscript-module in current GO client?. **Also as a side note:** Sounds strange to me that no one came with similar problem. In the end, afaik, there are not much other alternatives when it comes to hardening an embedded system, might be we are going the wrong direction trying to integrate mender+dm-verity? How are other users of mender hardening their rootfs? Thanks for the support. ---
**Author:** ![TheYoctoJester](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/theyoctojester/32/1444_2.png) [@TheYoctoJester](https://hub.mender.io/u/TheYoctoJester)\ **Post date:** [January 12, 2024, 8:35am UTC](https://hub.mender.io/t/mender-dm-verity-integration/6452/4 "2024-01-12T08:35:29Z")
Hi @Globulo No, I think the approach is correct. It’s not just integrity checking one needs for hardening but the whole bootchain needs to be carefully reviewed, like `u-boot` dropping into a shell, etc. For your questions: - the C+±client is pretty close to release. We‘re ironing out the last glitches by now, but I would consider it RC-quality. For something that is currently in R&D, it is definitely my go-to suggestion. - Yes, I‘ve shown you an Update Module in Shellscript. The new client will handle the whole rootfs update as an external module, not internally anymore. That is correct. - You can definitely handle a rootfs update as a module on the Go client too. This will need a different artifact type string for identification then as far as I can see, so it is not as streamlined. For a PoC on the Go client, let me put it like that: it would be interesting to have it visible for others that face the same problem and cannot upgrade the client for whatever reason, but I don‘t see any immediate way for such to be implemented in the mainline client, sorry. Greetz, Josef ---
**Author:** ![Globulo](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/globulo/32/2529_2.png) [@Globulo](https://hub.mender.io/u/Globulo)\ **Post date:** [January 12, 2024, 8:36pm UTC](https://hub.mender.io/t/mender-dm-verity-integration/6452/5 "2024-01-12T20:36:12Z")
> [@TheYoctoJester](#): > > No, I think the approach is correct. It’s not just integrity checking one needs for hardening but the whole bootchain needs to be carefully reviewed, like `u-boot` dropping into a shell, etc. Yes, of course, we have the full pack of complementary features: Signed + hardened u-boot/kernel, etc. Signed roothashes for dm-verity and all the bells and whistles. We are currently updating the required hashes and signatures in u-boot-env by simply using a state script now. The problem I’ve mentioned was just the last obstacle to finish the mender integration into the hardened system. > [@TheYoctoJester](#): > > the C+±client is pretty close to release. We‘re ironing out the last glitches by now, but I would consider it RC-quality. For something that is currently in R&D, it is definitely my go-to suggestion. Cool, so I’m going to integrate it in our current build and see how it goes. > [@TheYoctoJester](#): > > For a PoC on the Go client, let me put it like that: it would be interesting to have it visible for others that face the same problem and cannot upgrade the client for whatever reason, but I don‘t see any immediate way for such to be implemented in the mainline client, sorry. No need. Decision is to try the c++ client. The fact that a script is used as a module for rootfs update sounds more attractive as we could change some other details. Definitely more granularity and flexibility. **Question:** Is there some specific documentation for this new approach? Again, thanks for the support. ---
**Author:** ![omarfaruk](https://avatars.discourse-cdn.com/v4/letter/o/9d8465/32.png) [@omarfaruk](https://hub.mender.io/u/omarfaruk)\ **Post date:** [June 24, 2025, 10:43am UTC](https://hub.mender.io/t/mender-dm-verity-integration/6452/6 "2025-06-24T10:43:05Z")
Hi @Globulo, I’m currently working with the Toradex Verdin iMX8M Mini module and have encountered a circular dependency issue between the `fitImage` and the root filesystem (rootfs). Specifically, I’m struggling to install the `fitImage` into the `/boot` directory of rootfs and generating the .verity file afterwards Could you share insights on how you resolved this challenge? Any guidance or references would be greatly appreciated. Thanks in advance. ---
**Author:** ![TheYoctoJester](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/theyoctojester/32/1444_2.png) [@TheYoctoJester](https://hub.mender.io/u/TheYoctoJester)\ **Post date:** [June 24, 2025, 1:45pm UTC](https://hub.mender.io/t/mender-dm-verity-integration/6452/7 "2025-06-24T13:45:47Z")
Hi @omarfaruk, Having a `fitImage` and `dm-verity` is kinda exclusive in a shared root partition. So a classic approach would be to break the `fitImage` out into a separate partition. This might be the Mender boot partition which also holds the bootloader, or a more advanced, additional A/B setup. In either case, it will require careful handling, probably through a specialized Update Module. Greetz, Josef ---
**Author:** ![omarfaruk](https://avatars.discourse-cdn.com/v4/letter/o/9d8465/32.png) [@omarfaruk](https://hub.mender.io/u/omarfaruk)\ **Post date:** [June 26, 2025, 7:05am UTC](https://hub.mender.io/t/mender-dm-verity-integration/6452/8 "2025-06-26T07:05:15Z")
Is there any official mender support for this? Thanks & regards. ---
**Author:** ![TheYoctoJester](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/theyoctojester/32/1444_2.png) [@TheYoctoJester](https://hub.mender.io/u/TheYoctoJester)\ **Post date:** [June 27, 2025, 10:59am UTC](https://hub.mender.io/t/mender-dm-verity-integration/6452/9 "2025-06-27T10:59:31Z")
@omarfaruk Unfortunately there is no formal, official support for it yet. I’m happy to collaborate on a community drive approach via `meta-mender-community` which might facilitate using such for a larger user base. Greetz, Josef ---
**Author:** ![Globulo](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/globulo/32/2529_2.png) [@Globulo](https://hub.mender.io/u/Globulo)\ **Post date:** [June 27, 2025, 12:01pm UTC](https://hub.mender.io/t/mender-dm-verity-integration/6452/10 "2025-06-27T12:01:09Z")
Hi @omarfaruk What Toradex version BSP are you using now?. You might be lucky because I’m right now porting mender to the new Toradex BSP. Once I have it booting with a “normal” boot I will focus on secure-boot. ---
**Author:** ![omarfaruk](https://avatars.discourse-cdn.com/v4/letter/o/9d8465/32.png) [@omarfaruk](https://hub.mender.io/u/omarfaruk)\ **Post date:** [June 27, 2025, 3:00pm UTC](https://hub.mender.io/t/mender-dm-verity-integration/6452/11 "2025-06-27T15:00:26Z")
> [@Globulo](#): > > Once I have it booting with a “normal” boot I will focus on secure-boot. Currently, I’m using BSP 6.2.0 and Yocto Kirkstone.