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

[Ahmad Fatoum <a.fatoum@pengutronix.de>]

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

>> 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..?

> 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

> 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.

>> 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 ;)

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 |