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

["Jan Lübbe" <jlu@pengutronix.de>]

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                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |