Re: [PATCH 0/5] dm: Initial work on a device mapper
On Wed, 2025-09-03 at 22:19 +0200, Tobias Waldekranz wrote:
> On ons, sep 03, 2025 at 08:50, Jan Lübbe wrote:
> > On Tue, 2025-09-02 at 23:34 +0200, Tobias Waldekranz wrote:
> > > On tis, sep 02, 2025 at 16:46, Jan Lübbe wrote:
> > > > On Tue, 2025-09-02 at 11:03 +0200, Ahmad Fatoum wrote:
> > > > > > 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.
> > > >
> > > > If you are thinking about LVM, you may want to take a look at how
> > > > Android is
> > > > using dm-linear for "dynamic partitions":
> > > > https://source.android.com/docs/core/ota/dynamic_partitions/ab_launch
> > > > https://source.android.com/docs/core/ota/dynamic_partitions/implement
> > > >
> > > > This is also related to virtual A/B:
> > > > https://source.android.com/docs/core/ota/virtual_ab
> > > >
> > > > The components are "snapuserd" and "dm-user" (which was not merged):
> > > > https://lpc.events/event/11/contributions/1049/attachments/826/1562/2021%20LPC_%20dm-snapshot%20in%20user%20space.pdf
> > > > https://lwn.net/Articles/838986/
> > > >
> > > > I'm not sure what they use at the moment...
> > >
> > > Very interesting, thank you!
> > >
> > > I get why they want something like that for Android, but it does feel
> > > quite daunting to deploy for the systems I typically work on.
> > >
> > > If one was to ignore the business of background-merging of COW data
> > > etc. and was just looking to have a way of allocating volumes from
> > > persistent storage, do you see any advantages with Android's metadata
> > > format and/or tooling over that provided by the LVM2 project?
> >
> > LVM2 in general is quite complex.
>
> Oh yes, full LVM support would be mind-bendingly complicated in a
> bootloader. I am aiming for an extremely small subset:
>
> Being able to parse a VG made up of a single PV, containing LV's made up
> of only linear segments.
OK, I've never tried to figure out how much work such a subset would be.
> > Some people don't like that it's not easily
> > possible to know (in udev/systemd) when all volumes are found and set-up,
> > making
> > boot time dependencies difficult.
>
> I see. Is that because, in contrast to most other devices, userspace
> needs to initiate device creation? Are Android dynamic partitions better
> behaved in this respect?
The complication arises because one VG can have multiple PVs. So you have a
userspace component which scans new block devices to see if they are PVs and
assembles them into VGs. As "new" block devices can come in late on discoverable
busses, you're not sure if some more might appear of if an incomplete VG will
never be done.
For our embedded case, you can limit yourself to a strict nesting: one physical
partition can contain multiple dynamic partitions. So you when that specific
physical partition shows up, you can synchronously setup all dynamic partitions
(or fail due to an error). So there's no waiting and scanning of block devs
appearing at runtime.
Perhaps there's a way to do LVM probing synchronously as well, but if so, I'm
not aware that that's supported.
> > The Android metadata (or something similar)
> > seems to be simple enough to implement in a bootloader. So, as we only need
> > a
> > small subset of the full LVM functionality on embedded devices, perhaps
> > there's
> > space for a lightweight alternative? :)
>
> Agreed, I am not exactly thrilled about needing a parser for the LVM
> ASCII metadata format in Barebox :)
>
> Android dynamic partitions undoubtedly seem much better from that
> perspective.
>
> Here is my concern with it: wouldn't going this route mean that you have
> to either (a) build your own tooling for working with Android dynamic
> partitions, or (b) have some semi-automated way of extracting the
> existing tooling from the Android source tree? In contrast, the LVM2
> package is just a config option away in both Buildroot, PTXdist, and
> Yocto.
Yes, it would mean custom tooling. Building Android tools externally seems a lot
of pain (just look at what's needed to build fastboot and adb).
My idea is probably more of a long-term plan or wish. ;) One neat trick of the
android partitioning ("virtual A/B") is that they can temporarily use space from
the data partition to hold the newly installed system until it's confirmed good.
Doing that with LVM would mean using the thin provisioning device mappers.
Regards
Jan
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137
Re: [PATCH 0/5] dm: Initial work on a device mapper
On ons, sep 03, 2025 at 08:50, Jan Lübbe wrote: > On Tue, 2025-09-02 at 23:34 +0200, Tobias Waldekranz wrote: >> On tis, sep 02, 2025 at 16:46, Jan Lübbe wrote: >> > On Tue, 2025-09-02 at 11:03 +0200, Ahmad Fatoum wrote: >> > > > 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. >> > >> > If you are thinking about LVM, you may want to take a look at how Android >> > is >> > using dm-linear for "dynamic partitions": >> > https://source.android.com/docs/core/ota/dynamic_partitions/ab_launch >> > https://source.android.com/docs/core/ota/dynamic_partitions/implement >> > >> > This is also related to virtual A/B: >> > https://source.android.com/docs/core/ota/virtual_ab >> > >> > The components are "snapuserd" and "dm-user" (which was not merged): >> > https://lpc.events/event/11/contributions/1049/attachments/826/1562/2021%20LPC_%20dm-snapshot%20in%20user%20space.pdf >> > https://lwn.net/Articles/838986/ >> > >> > I'm not sure what they use at the moment... >> >> Very interesting, thank you! >> >> I get why they want something like that for Android, but it does feel >> quite daunting to deploy for the systems I typically work on. >> >> If one was to ignore the business of background-merging of COW data >> etc. and was just looking to have a way of allocating volumes from >> persistent storage, do you see any advantages with Android's metadata >> format and/or tooling over that provided by the LVM2 project? > > LVM2 in general is quite complex. Oh yes, full LVM support would be mind-bendingly complicated in a bootloader. I am aiming for an extremely small subset: Being able to parse a VG made up of a single PV, containing LV's made up of only linear segments. > Some people don't like that it's not easily > possible to know (in udev/systemd) when all volumes are found and set-up, > making > boot time dependencies difficult. I see. Is that because, in contrast to most other devices, userspace needs to initiate device creation? Are Android dynamic partitions better behaved in this respect? > The Android metadata (or something similar) > seems to be simple enough to implement in a bootloader. So, as we only need a > small subset of the full LVM functionality on embedded devices, perhaps > there's > space for a lightweight alternative? :) Agreed, I am not exactly thrilled about needing a parser for the LVM ASCII metadata format in Barebox :) Android dynamic partitions undoubtedly seem much better from that perspective. Here is my concern with it: wouldn't going this route mean that you have to either (a) build your own tooling for working with Android dynamic partitions, or (b) have some semi-automated way of extracting the existing tooling from the Android source tree? In contrast, the LVM2 package is just a config option away in both Buildroot, PTXdist, and Yocto. > Jan > -- > 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- |
Re: [PATCH 0/5] dm: Initial work on a device mapper
On Tue, 2025-09-02 at 11:03 +0200, Ahmad Fatoum wrote: > > 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. If you are thinking about LVM, you may want to take a look at how Android is using dm-linear for "dynamic partitions": https://source.android.com/docs/core/ota/dynamic_partitions/ab_launch https://source.android.com/docs/core/ota/dynamic_partitions/implement This is also related to virtual A/B: https://source.android.com/docs/core/ota/virtual_ab The components are "snapuserd" and "dm-user" (which was not merged): https://lpc.events/event/11/contributions/1049/attachments/826/1562/2021%20LPC_%20dm-snapshot%20in%20user%20space.pdf https://lwn.net/Articles/838986/ I'm not sure what they use at the moment... Regards, Jan -- 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- |
Re: [PATCH 0/5] dm: Initial work on a device mapper
On tis, sep 02, 2025 at 10:40, Ahmad Fatoum wrote: > Hi, > > On 8/31/25 9:48 AM, Tobias Waldekranz wrote: >> On fre, aug 29, 2025 at 10:29, Sascha Hauer 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- | >> >> > > -- > 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- |
Re: [PATCH 0/5] dm: Initial work on a device mapper
On Tue, 2025-09-02 at 15:01 +0200, Tobias Waldekranz wrote: > > > > 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). Image-based/immutable systems are very much in their focus: https://uapi-group.org/docs/ There is a strong preference for UEFI, though, as they see it as the only viable path to a standardized interface between bootloader and kernel. That create some tension in areas where some parts of their specs are also very useful for vertically integrated systems like the ones we build (and with often don't use UEFI). > > > 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. With A/B partitions I find it simpler and less error prone to avoid scanning and just pass the fixed device names already known to the bootloader. Jan -- Pengutronix e.K. | | Steuerwalder Str. 21 |
Re: [PATCH 0/5] dm: Initial work on a device mapper
On Tue, 2025-09-02 at 23:34 +0200, Tobias Waldekranz wrote: > On tis, sep 02, 2025 at 16:46, Jan Lübbe wrote: > > On Tue, 2025-09-02 at 11:03 +0200, Ahmad Fatoum wrote: > > > > 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. > > > > If you are thinking about LVM, you may want to take a look at how Android is > > using dm-linear for "dynamic partitions": > > https://source.android.com/docs/core/ota/dynamic_partitions/ab_launch > > https://source.android.com/docs/core/ota/dynamic_partitions/implement > > > > This is also related to virtual A/B: > > https://source.android.com/docs/core/ota/virtual_ab > > > > The components are "snapuserd" and "dm-user" (which was not merged): > > https://lpc.events/event/11/contributions/1049/attachments/826/1562/2021%20LPC_%20dm-snapshot%20in%20user%20space.pdf > > https://lwn.net/Articles/838986/ > > > > I'm not sure what they use at the moment... > > Very interesting, thank you! > > I get why they want something like that for Android, but it does feel > quite daunting to deploy for the systems I typically work on. > > If one was to ignore the business of background-merging of COW data > etc. and was just looking to have a way of allocating volumes from > persistent storage, do you see any advantages with Android's metadata > format and/or tooling over that provided by the LVM2 project? LVM2 in general is quite complex. Some people don't like that it's not easily possible to know (in udev/systemd) when all volumes are found and set-up, making boot time dependencies difficult. The Android metadata (or something similar) seems to be simple enough to implement in a bootloader. So, as we only need a small subset of the full LVM functionality on embedded devices, perhaps there's space for a lightweight alternative? :) Jan -- 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- |
Re: [PATCH 0/5] dm: Initial work on a device mapper
On tis, sep 02, 2025 at 16:46, Jan Lübbe wrote: > On Tue, 2025-09-02 at 11:03 +0200, Ahmad Fatoum wrote: >> > 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. > > If you are thinking about LVM, you may want to take a look at how Android is > using dm-linear for "dynamic partitions": > https://source.android.com/docs/core/ota/dynamic_partitions/ab_launch > https://source.android.com/docs/core/ota/dynamic_partitions/implement > > This is also related to virtual A/B: > https://source.android.com/docs/core/ota/virtual_ab > > The components are "snapuserd" and "dm-user" (which was not merged): > https://lpc.events/event/11/contributions/1049/attachments/826/1562/2021%20LPC_%20dm-snapshot%20in%20user%20space.pdf > https://lwn.net/Articles/838986/ > > I'm not sure what they use at the moment... Very interesting, thank you! I get why they want something like that for Android, but it does feel quite daunting to deploy for the systems I typically work on. If one was to ignore the business of background-merging of COW data etc. and was just looking to have a way of allocating volumes from persistent storage, do you see any advantages with Android's metadata format and/or tooling over that provided by the LVM2 project? > Regards, > Jan > > -- > 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- |
Re: [PATCH 0/5] dm: Initial work on a device mapper
On Fri, 2025-08-29 at 13:24 +0200, Ahmad Fatoum wrote: > > 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? > > 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. For the kernel, there is: https://docs.kernel.org/admin-guide/device-mapper/log-writes.html https://github.com/josefbacik/log-writes Perhaps this could be used via the sandbox build or even QEMU to produce such a log. Then, you could use the userspace tool to reproduce all intermediate states and check that they are consistent. Doing this has been on my wishlist for ages, but I've never gotten around to it. Also in this area, I've wondered for some time if an alternative implementation of FAT would be possible which does a strictly ordered commit of a new meta-data tree on unmount. As there are two copies of the top-level FAT, it might be possible to do that atomically by using a careful ordering of writes. By now, FAT is basically only used as a boot partition, so trading performance for reliability might be a good idea. :) Regards, Jan -- 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- |
Re: [PATCH 0/5] dm: Initial work on a device mapper
On tis, sep 02, 2025 at 11:03, Ahmad Fatoum wrote: > On 8/31/25 9:48 AM, Tobias Waldekranz wrote: >> On fre, aug 29, 2025 at 13:24, Ahmad Fatoum 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
Re: [PATCH 0/5] dm: Initial work on a device mapper
On 8/31/25 9:48 AM, Tobias Waldekranz wrote: > On fre, aug 29, 2025 at 13:24, Ahmad Fatoum 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
Re: [PATCH 0/5] dm: Initial work on a device mapper
Hi, On 8/31/25 9:48 AM, Tobias Waldekranz wrote: > On fre, aug 29, 2025 at 10:29, Sascha Hauer 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]. 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? 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). 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- | > > -- 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- |
Re: [PATCH 0/5] dm: Initial work on a device mapper
On fre, aug 29, 2025 at 13:24, Ahmad Fatoum 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
Re: [PATCH 0/5] dm: Initial work on a device mapper
On fre, aug 29, 2025 at 10:29, Sascha Hauer wrote: > Hi Tobias, > > On Thu, Aug 28, 2025 at 05:05:25PM +0200, Tobias Waldekranz wrote: >> Start work on adding a device mapper that is compatible with the >> corresponding subsystem in Linux. >> >> 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. > > That's great stuff. We are also interested especially in dm-verity as > that would allow us to get rid of separate partitions for the Kernel > image and maybe even the FIT image format we currently use whenever we > need signed Kernel images. 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. >> >> 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. >> >> 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? >> >> 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. >> >> 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. >> >> 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. > > Ok, it seems we have the same goals ;) Very glad to hear it! :) >> >> 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. >> >> 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 haven't looked into this yet, but it sounds good. It's a good thing > when barebox can just do the right thing without much configuration. > >> >> 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 :) > > 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. > 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- |
Re: [PATCH 0/5] dm: Initial work on a device mapper
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! 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. 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. > 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? 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. > 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 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. > 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
Re: [PATCH 0/5] dm: Initial work on a device mapper
Hi Tobias, On Thu, Aug 28, 2025 at 05:05:25PM +0200, Tobias Waldekranz wrote: > Start work on adding a device mapper that is compatible with the > corresponding subsystem in Linux. > > 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. That's great stuff. We are also interested especially in dm-verity as that would allow us to get rid of separate partitions for the Kernel image and maybe even the FIT image format we currently use whenever we need signed Kernel images. > > 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. > > 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? > > 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. > > 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. > > 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. Ok, it seems we have the same goals ;) > > 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. > > 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 haven't looked into this yet, but it sounds good. It's a good thing when barebox can just do the right thing without much configuration. > > 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 :) 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. 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- |
[PATCH 0/5] dm: Initial work on a device mapper
Start work on adding a device mapper that is compatible with the corresponding subsystem in Linux. 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. 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? 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. 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. 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. 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. 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. 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 :) [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 -- 2.43.0
