barebox,state on the EFI payload: boot-disk binding and state.dtb trust
Raymond | KelvaneOS
raymond at kelvaneos.eu
Tue Jul 28 05:45:20 PDT 2026
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
More information about the barebox
mailing list