barebox,state on the EFI payload: boot-disk binding and state.dtb trust
Raymond | KelvaneOS <[email protected]> Tue, 28 Jul 2026 14:45:20 +0200
| Newsgroups | org.infradead.lists.barebox |
|---|---|
| Message-ID | <[email protected]> |
Hi, We are evaluating barebox as the boot selector for an immutable Linux distribution on UEFI x86-64, with A/B generations and barebox,state in a dedicated GPT partition. Two things in the EFI payload I could not settle from the source, and I would rather ask than guess. 1) Binding state to the boot disk We want the state backend to resolve to a partition on the disk barebox was loaded from, without baking a machine-specific PARTUUID into the device tree. barebox,bootsource together with storage-by-alias looks like the intended composition, and state.c already resolves a whole-disk backend to the state partition by GPT type GUID. But bootsource_get_alias_stem() in common/bootsource.c has no case for BOOTSOURCE_HD or BOOTSOURCE_USB, so bootsource_of_node_get() returns NULL on the paths the EFI payload uses. Is there an intended mechanism here that I have missed? If not, would a patch adding those bootsource cases be welcome, or were they left out for a reason? 2) Trusting state.dtb under Secure Boot efi/payload/init.c reads the state description from /boot/EFI/barebox/state.dtb when CONFIG_STATE is enabled and /boot is mounted. That file is not covered by the signature on the barebox EFI binary, so with Secure Boot enabled and our own keys enrolled, the layout and storage association of the state area remain modifiable while the rest of the chain is authenticated. Is there an existing way to require a built-in state description instead, or to authenticate that file? If not, would a Kconfig option to disable the external load path be acceptable? Happy to do the work on either if the direction is agreed. Thanks, Raymond Zwarts