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

[Tobias Waldekranz <tobias@waldekranz.com>]

On fre, aug 29, 2025 at 13:24, Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
> Hi Tobias,
>
> On 28.08.25 17:05, Tobias Waldekranz wrote:
>> Start work on adding a device mapper that is compatible with the
>> corresponding subsystem in Linux.
>
> I haven't go through the patches, but I read this far and I am hyped!

Let's hope the code can live up to the hype :)

> Both Richard (Cc'd) and myself held talks[1][2] this week at ELC-E in
> Amsterdam lamenting the current state of vulnerabilities affecting the
> file systems and not having dm-verity in the bootloader stack to
> counteract this.

Interesting, I'll have to catch the videos once they are available.

> It's thus really cool to see you have been working not talking. :D
>
> I will check this out more thoroughly next week.
>
>> This is the foundation of several higher level abstractions, for
>> example:
>> 
>> - LVM: Linux Volume manager. Dynamically allocates logical volumes
>>   from one or more storage devices, manages RAID arrays, etc.
>> 
>> - LUKS: Linux Unified Key Setup. Transparent disk
>>   encryption/decryption.
>> 
>> - dm-verity: Transparent integrity checking of block devices.
>> 
>> This is part of an exploratory project for investigating how we could
>> boot Infix[1] in a more platform-independent way. I.e., my intention
>> is to eventually add support for some of the features mentioned above,
>> assuming we don't hit any major road blocks. The rest of this letter
>> just gives context for how we got here and where we would like to take
>> Barebox. If that is not interesting, feel free to stop reading here :)
>> 
>> Our idea is to relegate U-Boot to serve only as a UEFI firmware on the
>> platforms where we can't escape it, and then do most of our boot logic
>> in Barebox instead. Primarily we want to do this for two reasons:
>> 
>> 1. Being able to ship barebox as an EFI app means we can use the same
>>    boot logic on x86 machines as we to on everything else.
>
> I have for years been working on an EFI loader implementation for barebox.
> It can boot Fedora and Debian (both OS and CDROM installer) fine on ARM64
> and have gotten lost in the weeds doing the same for ARM32. It works there
> with the most recent kernel, but not what's in Debian Trixie and I have yet
> to find out what is the difference.
>
> I hope to resume this work in the coming months. I know this doesn't address
> the issue of barebox not supporting as wide a hardware range as U-Boot, but
> I mention this to explain where the EFI payload support for ARM is coming from:
>
> The x86 EFI payload support in barebox has reliably been used under a number of
> EFI implementation in different products over the years.
>
> The ARM EFI payload support was started by me dog fooding my barebox-on-ARM
> EFI loader work, so it still needs some more work to be usable as bootloader in
> its own right.
>
> My focus so far was more on getting it to run under all of U-Boot, Tianocore and
> of course barebox to inform the way I implement the EFI loader. (Admittedly,
> I went a bit overboard, e.g., implementing directory fds instead of just doing path
> normalization/resolution inside EFI, but it looks really nifty now!)
>
> Fortunately, Anis (Cc'd) is right now working on exactly the use case
> of filling out the missing pieces for using barebox as EFI payload on ARM and has
> already submitted patches bringing this closer to completion.

Thanks for the background. Yeah, once I figured out I needed
CONFIG_COMPILE_TEST to build for aarch64 I got the sense that there was
still work to be done there :) That's alright though, I'm skating to
where the puck will be.

>> 2. Barebox is a much higher quality code base to work in than
>>    U-Boot. I'm sorry, but it just is.
>> 
>> Barebox would thus take the place occupied by systemd-boot in many
>> distro setups. So why not go with systemd-boot?
>
> Sidenote: Something that been irking me for ages is the over-reliance
> on FAT in systemd-boot. Could the FAT on a file system level break
> by inopportune power cuts? We go to great lengths with barebox-state
> and redundant buckets on raw partitions to avoid this and it leaves
> me asking: Was I wrong to mistrust FAT or is a sudden power cut during
> file system write operations not as much a concern for their users?

This has been bothering me too, and AFAIK the UEFI spec does not
describe any way of defining a redundant ESP either?

> I hope someone (maybe me instead of talking) should do fault injection
> in QEMU or using kernel APIs and see how broken it can get.

That would be great. Doing it at the VM layer seems very hard, at least
if you want something deterministic. In the kernel though, it should be
easier to know when a filesystem is in an inconsistent state, and inject
the errors at that point.

>> 1. Infix does not run systemd as PID 1, so reusing their bootloader is
>>    awkward.
>> 
>> 2. Infix ships as a single immutable filesystem image, including
>>    kernel, DTBs, etc. So we want to extract these files from the
>>    filesystem before booting the kernel. This is not supported by
>>    systemd-boot, AFAIK - all boot files must live on the ESP.
>
> I don't want to talk you out of using barebox of course, but I believe

Not happening! ;)

> they also support XBOOTLDR partitions? At least in barebox, you should
> be able to just assign the rootfs partition of the Infix OS the XBOOTLDR
> partition Type UUID to have barebox automatically look for the bootloader
> spec entries there.

They do support that, yes. However, but that would mean that we could
not use the DPS/DDI partition types that would allow for discovery of
verity data/signature etc.

>> 3. We would like to manage our devices' non-volatile storage with LVM,
>>    and not be bound to a fixed partition table. This will give us more
>>    flexibility in growing our image, efficiently having images of
>>    varying sizes installed, etc.
>
> That sounds very useful.
>
>> Therefore, our plan is (roughly):
>> 
>> 1. Add dm-verity support
>> 2. Add dm-verity root-hash-signature verification support
>> 
>> With that, we can securely extract kernel+DTB from our filesystem
>> without having to sign them individually.
>
> Many embedded systems shipping with barebox right now employ the bootloader
> spec based way of booting and switching to a verified boot chain means
> abandoning all of that in favor of a FIT-Image-in-raw-partition model.
>
> dm-verity support in barebox would be most useful to give users
> a good migration path.

This is my plan forward as well. We're using the syslinux-flavor of the
same idea at the moment. I like barebox's relaxation of the standard to
allow for locating boot entries outside of ESP/XBOOTLDR, without which
we would be back at the split-rootfs-and-kernel problem. Have you
thought about making this case to the UAPI group to amend the spec?

> Not to start bikeshedding already while still going through the cover
> letter, but just to write it down: barebox can already fix up root=
> parameters optionally depending on the boot medium and it would make
> sense for barebox to use that to pass the dm-verity root hash along
> as to avoid a mix-and-match attack that shows barebox and the kernel
> different dm-verity rootfs and thereby mix kernels with rootfs that
> were not meant to be used in that combination.
> In this case, barebox would be the only component caring for the
> signed root hash in the image.

Yeah I noticed that, _very_ useful. For Infix, if we end up going with
LVM, I suspect we won't be able to send all of that info along with the
commandline, and will end up needing to figure that out (again) in an
initramfs - but for most cases I think it would work really well!

>> 3. Add basic LVM support, no RAID or anything, just basic (linear)
>>    logical volumes.
>> 
>> This will allow us to install multiple versions of Infix on individual
>> logical volumes, which Barebox can then find and boot from.
>
> Ack.
>
>> 4. Add high-level helpers for working with DPS disks and DDI images.
>> 
>> I really like the Linux Userspace API Group's thinking around
>> Discoverable Partitions Specification (DPS) and Discoverable Disk
>> Images (DDI). I think it would be great if Barebox had knowledge about
>> these patterns, and could automatically set up the dm-verity
>> configuration for a partition when available, for example.
>
> I am not familiar with what they specified with regard to verity and
> will have to read up on that. I know of this PR who is not going
> anywhere right now for veritysetup, but I haven't read through it myself:
> https://gitlab.com/cryptsetup/cryptsetup/-/merge_requests/738
>
> I believe Marco (Cc'd) did, so maybe he has an opinion.
>
> Generally speaking, whether DDI or veritysetup, if there exists a scheme
> to put a signed hash somewhere discoverable and it's adopted by some
> widely used tool, barebox should not unnecessarily reinvent the wheel.

Exactly. From what I understand, systemd already supports automatically
sourcing the signature from a partition with the ID specified in DPS. So
I don't see them switching from that to something else (Poettering
himself seems quite involved with all UAPI specs).

> As Sascha put it, stuff should just work.
>
>> My hope is that this plan sparks some ideas and reflections. If so, I
>> would love to hear them. If not, sorry for the wall of text :)
>
> Thanks for taking the time and the good timing. I was meaning to use
> the time writing this mails to cut down on some of the slides[3] for a second
> talk at the Linux Security Summit today, but now they are getting more.
> At least the talk is right before a break :)

Thanks for the shout-out! :)

> [1]: https://osseu2025.sched.com/event/25VqL
> [2]: https://osseu2025.sched.com/event/25VwO
> [3]: https://lsseu2025.sched.com/event/25GEc
>
> Cheers,
> Ahmad
>
>
>> 
>> 
>> [1]: https://github.com/kernelkit/infix/
>> 
>> Tobias Waldekranz (5):
>>   string: add strtok/strtokv
>>   dm: Add initial device mapper infrastructure
>>   dm: linear: Add linear target
>>   test: self: dm: Add test of linear target
>>   commands: dmsetup: Basic command set for dm device management
>> 
>>  commands/Kconfig             |  14 ++
>>  commands/Makefile            |   1 +
>>  commands/dmsetup.c           | 145 +++++++++++++
>>  drivers/block/Kconfig        |   2 +
>>  drivers/block/Makefile       |   1 +
>>  drivers/block/dm/Kconfig     |  14 ++
>>  drivers/block/dm/Makefile    |   3 +
>>  drivers/block/dm/dm-core.c   | 393 +++++++++++++++++++++++++++++++++++
>>  drivers/block/dm/dm-linear.c | 123 +++++++++++
>>  drivers/block/dm/dm-target.h |  39 ++++
>>  include/dm.h                 |  16 ++
>>  include/string.h             |   2 +
>>  lib/string.c                 |  66 ++++++
>>  test/self/Kconfig            |   7 +
>>  test/self/Makefile           |   1 +
>>  test/self/dm.c               | 159 ++++++++++++++
>>  16 files changed, 986 insertions(+)
>>  create mode 100644 commands/dmsetup.c
>>  create mode 100644 drivers/block/dm/Kconfig
>>  create mode 100644 drivers/block/dm/Makefile
>>  create mode 100644 drivers/block/dm/dm-core.c
>>  create mode 100644 drivers/block/dm/dm-linear.c
>>  create mode 100644 drivers/block/dm/dm-target.h
>>  create mode 100644 include/dm.h
>>  create mode 100644 test/self/dm.c
>> 
>
>
> -- 
> 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 |