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

[Tobias Waldekranz <tobias@waldekranz.com>]

On tis, sep 02, 2025 at 11:03, Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
> On 8/31/25 9:48 AM, Tobias Waldekranz wrote:
>> On fre, aug 29, 2025 at 13:24, Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
>>> On 28.08.25 17:05, Tobias Waldekranz wrote:
>>> 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.
>
> Great. I think it shapes up quite nicely right now.
>
>>> 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?
>
> Not really, but depending on the tools you use, there are workarounds:
>
> - barebox skips partitions with the DPS_TYPE_FLAG_NO_AUTO flag.
> Currently only for blspec, but in future also when searching for ESP
>
> - RAUC supports a "boot-gpt-switch"[1] that "[changes] the GPT to switch
> the first GPT partition entry between the first and second halves of a
> region configured for that purpose"
>
> [1]:
> https://rauc.readthedocs.io/en/latest/advanced.html#update-bootloader-partition-in-gpt

Neat! We use RAUC in Infix, so I will definitely look into that.

>>> 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.
>
> Ack.
>
>>> 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.
>
> I haven't read the spec in full, but after a discussion with Jan (Cc'd),
> we had an unanswered question about the root verity partition:
>
> "Contains dm-verity integrity hash data for the matching root partition.
> If this feature is used the partition UUID of the root partition should
> be the first 128 bits of the root hash of the dm-verity hash data, and
> the partition UUID of this dm-verity partition should be the final 128
> bits of it, so that the root partition and its Verity partition can be
> discovered easily, simply by specifying the root hash."
>
> Now a UUID is only 128 bits and the partition UUID is supposed to be
> unique, so splitting a 256 bit hash over two partitions UUIDs means that
> in an A/B setup, we can end up with duplicate partition UUIDs if the
> same update bundle is installed twice.
>
>   - A and B root partition are identical
>   - A and B verity super block are identical
>
> When updating this may prove to be problematic: The system will start up
> normally (partitions are identical), but when flashing the update, how
> would the updater easily find out which is the inactive partition that
> it should write to..?

That was a question I had as well. My conclusion, given how they think
about blspec entries only existing on ESP/XBOOTLDR with split
rootfs/kernel etc., is that they are not designing for the kinds of
systems that you and I typically target.

>> 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?
>
> I tried to get linux-appendroot upstreamed as first step, but haven't
> been too successful so far:
> https://github.com/uapi-group/specifications/pull/136

Oh wow, the x86 is strong in this one.

Unfortunately I think this is in line with my hunch about the gamut of
systems on their radar not including our domain (embedded+immutable).

>> 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!
>
> Ah, didn't think of LVM. If mix-and-match is no problem for you, then
> doing it in the initramfs is a workable solution of course.

I definitely want to avoid mix-and-matching between kernel and
rootfs. My idea was that barebox could still pass the partition UUID and
the root hash to the kernel, then the (very small) initramfs would just:

1. Run some LVM probing to find and setup the volume with that UUID
2. Run verity setup on the it with the (already signature-checked) root
   hash
3. pivot_root

Maybe this is more trouble than its worth, still not sure.

I just seems strange to me that this is fairly common on setups with raw
flash (via UBI volumes), but for some reason it is never used (at least
to my knowledge) on systems with managed flash.

>>> 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).
>
> Ack.
>
>>> 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! :)
>
> You had me dig out WordArt just for this special announcement ;)

I k-n-o-w - instantly felt the urge to put on my old roller blades and
blast some eurodisco on my Walkman!

> Cheers,
> Ahmad
>
>> 
>>> [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 |
>> 
>
> -- 
> 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 |