[PATCH 0/5] dm: Initial work on a device mapper

[Tobias Waldekranz]

On tis, sep 02, 2025 at 10:40, Ahmad Fatoum <a.fatoum at pengutronix.de> wrote:
> Hi,
>
> On 8/31/25 9:48 AM, Tobias Waldekranz wrote:
>> On fre, aug 29, 2025 at 10:29, Sascha Hauer <s.hauer at pengutronix.de> wrote:
>> We are sort of in the same boat. We wrap our rootfs in an FIT header,
>> just because that is the only format U-Boot knows how to verify. After
>> verification, we strip off the header, mount it, and then sysboot from
>> it, with the kernel and DTBs in /boot on the squash.
>> 
>> Just shipping the fs with verity data (+ possibly FEC, in the future)
>> and a signature would be _so_ much nicer.
>
> FEC with verity indeed sounds interesting. Apparently, it can go beyond
> fixing occasional bit flips on read to even recover completely lost
> blocks[1].

Yes, this is very exciting!

Today, we use a classic A/B partition scheme for redundancy, but I would
much rather have a setup where you install one or more versions of
Infix, and all versions are always "redundant" in that the image ships
with its own parity data.

For users I think this also makes more sense: rather than configuring a
boot order based on partitions, you specify which versions you want to
boot and in what order.

> For the latter case, someone will need to implement some "blkhealthd"
> that reads regularly and fixes up bit errors in the backing device.
> Would also mesh nicely with retention on the medium itself as it gives
> e.g. the eMMC a chance to correct ECC on infrequently used data before
> it's completely irrecoverable.
>
> [1]:
> https://android-developers.googleblog.com/2016/07/strictly-enforced-verified-boot-with.html
>
>>> Well I am very open for adding DM and dm-verity support to barebox. We
>>> would likely have done it anyway at some point, but that could have
>>> taken some time.
>> 
>> Cool! I did a toy implementation in Python yesterday, just to convince
>> myself I understood how it works, and it was actually very straight
>> forward. So if this series is eventually merged, I hope to follow up
>> with an implementation of dm-verity pretty quickly.
>
> Did you consider porting dm/dm-verity from the kernel instead and
> decided against it?

"Implmentation" was maybe being to generous to myself :)

It was more or less an exercise to figure out which subset of
dm-verity-target.c from the kernel that we need to extract to Barebox.

> I imagine there's a lot that would need to be dropped/adapted, but
> having the same general structure may prove useful in future when adding
> new device mapper targets. I can understand though, that for dm-verity
> it may turn out to be easier to reimplement the functionality (which is ok).

The I/O paths are very different, so the .map() method that targets
implement on the kernel side, based on a struct bio, felt a bit awkward
to replicate in Barebox, so I went for .read()/.write() instead, to map
cleaner to the existing block device interface. In general, the kernel
does lots of performance enhancing tricks with async I/O etc.

Basic device creation, based on a target table as the input, is the
same, with the same format as the kernel.

Target creation from an argument vector is also the same as in the
kernel. I chose to go with .create()/.destroy() over (at least to me
somewhat idiosyncratic) .ctr()/.dtr() - but I am happy to keep this
closer to the original, if you prefer.

Like in the kernel, each target reports its own status. I chose to start
with something simple here, rather than copying the kernel's many
different output variants etc.

> Cheers,
> Ahmad
>
>
>
>> 
>>> Sascha
>>>
>>> -- 
>>> Pengutronix e.K.                           |                             |
>>> Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
>>> 31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
>>> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
>> 
>> 
>
> -- 
> Pengutronix e.K.                  |                             |
> Steuerwalder Str. 21              | http://www.pengutronix.de/  |
> 31137 Hildesheim, Germany         | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686  | Fax:   +49-5121-206917-5555 |