Consolidating A/B with discoverable dm-verity partitions

[a3f]

Background:

dm-verity support was recently contributed¹² to the barebox bootloader with an eye towards leveraging the discoverable partition specification to associate the rootfs partition with verity hash data and signature.

The embeded systems that barebox is deployed on usually have two rootfs partitions (A/B), which barebox chooses between on boot up.

In future configurations with dm-verity, barebox would verify the root hash for the active rootfs partition, boot the kernel image from it and pass along the root hash via the kernel command line.

Problem:

The discoverable partition specification associates a rootfs partition with its verity partition by means of the GPT Partition UUID:

• The root partition UUID is the first 128 bits of the root hash
• The root verity partition (dm-verity superblock followed by hash data) partition UUID is the last 128 bits of the root hash

In A/B update systems, we run into a corner case when the same update has been installed twice back to back:
We then end up with two root partitions with the same partition UUID as well as two verity partition also with the same partition UUID.

This violates the GPT specification as partition UUIDs are meant to be unique and this will result in misbehavior,
e.g., if the bootloader fixes up root=PARTUUID=... into the kernel command line, the kernel may end up locating and mounting a different rootfs partition than the bootloader.
Likewise /dev/disk/by-uuid/ would also run into conflicts.

A/B issues also arise with the verity signature partition: The partition contains the root hash, but no further info to deterministically associate it with the corresponding root and verity partitions.

I would argue that the core issue here is non-unique partition UUIDs and it would be good to have a resolution for this.

Possible approaches:

In order to allow partition UUIDs to be unique/randomized again, we will need an alternative scheme to associate rootfs with verity data and signature (let's call each of these a group). Candidates for defining groups could be:

• Order: The specification could prescribe a scheme where partitions in the group should follow each other in a specific order. GPT allows for on-disk order to differ from table order, so this does not preclude resizing partitions for example.
• Name: For the Type UUIDs defined by the spec, a naming scheme could be prescribed to indicate groups
• Attributes: The spec leaves 13/16 Type-specific attribute bits undefined, which could be used to encode a fixed number of groups. Alternatively, it could also be useful in combination with one of the two approaches above to ensure backwards compatibility.

Interested in hearing your thoughts.

---

Footnotes

1. https://lore.kernel.org/barebox/20250828150637.2222474-1-tobias@waldekranz.com/ ↩

2. https://lore.kernel.org/barebox/20250918074455.891780-1-tobias@waldekranz.com/ ↩

[wkz]

Another possible approach: Nested GPTs

Top:               "A" and "B":
.-------------.    .------------------------------------.
| <GPT>       |    | <GPT>                              |
:-------------:    :------------------------------------:
| "EFI" (esp) |    | "rootfs"            (root-aarch64) |
:-------------:    :------------------------------------:
|   "A" (dps) |    | "verity"     (root-aarch64-verity) |
:-------------:    :------------------------------------:
|   "B" (dps) |    |    "sig" (root-aarch64-verity-sig) |
'-------------'    '------------------------------------'

"Label" (part-uuid)

I.e., you would allocate a new partition UUID (dps in figure) that indicates that there is a nested GPT, following DPS, on this partition. The inner GPT could then use the existing UUIDs without any risks of collisions.

[poettering]

I dont get it? Why would you install the same version of the os twice? That sounds like a bug in your updater. At least systemd-sysupdate refuses to update an os version to itself, and i really dont see any reason to allow that? Hence, why not fix your updater?

And even if things are hosed and you end up in a situation like this, what would it matter which partition set is used, they are by definition the same, as the root hash pins the contents in full. Hence the failure mode here is quite friendly: the ambiguity comes at no cost.

[wkz]

Why would you install the same version of the os twice?

To have a backup in case an unrecoverable error on the underlying media causes one of them to become corrupt.

Yes, other ways of managing this might exist today, like dm-verity+FEC. Traditionally though, the A/B scheme has been the standard in this domain.

[...] what would it matter which partition set is used [...]

I think the idea is that you have some external boot counting mechanism, or similar, that has determined that the A group is not usable. In that scenario, you want to make sure that only data from group B is used.

[poettering]

hmm, a model where A/B is done to work around hw errors was so far not in view for the spec. does GPT even work for that? i mean, it doesn't really give you any freedom an placing the GPT headers so you really are dependent on specific sectors to just work?

i wonder if you want something like this, if it wouldn't be better to just mark the secondary copies as "noauto", and have the boot loader switch over "noauto" as it wants then?

[wkz]

[...] so you really are dependent on specific sectors to just work?

You rely on the blocks holding either the primary or the backup table being usable at any given boot. Assuming some managed FLASH solution, like eMMC, you could then rewrite the corrupt table, which the wear-leveling layer in the controller would then map to another, healthy, block.

i wonder if you want something like this, if it wouldn't be better to just mark the secondary copies as "noauto", and have the boot loader switch over "noauto" as it wants then?

You are talking about the partition attribute, right? I think there are a few problems with that approach:

1. Six partition entries have to be updated (A and B flavors of the filesystem, verity data and signature). I am not sure how you could perform that operation atomically.
2. Ignoring the first problem, while this approach would allow you to discriminate between two groups (effectively bool noauto becomes union { bool noauto; bool ab; }, it does not extend beyond that (yes, A/B/C devices are a thing). While it is unlikely that more than two of those groups hold the same image, it would be preferable to have the group identifier be completely orthogonal to the partition UUID.

Perhaps we could borrow ideas from ChromiumOS, they seem to use a variant of Ahmad's suggestion to create a group ID from partition attributes.