barebox,state on the EFI payload: boot-disk binding and state.dtb trust

[Ahmad Fatoum]

Hello Raymond,

On 7/28/26 2:45 PM, Raymond | KelvaneOS wrote:
> 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.

Most systems running barebox store the state on some "built-in" storage,
so having a dynamic location was not a common use case.

> 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?

Patches are most certainly welcome, but merely adding aliases won't cut
it as this logic relies on both barebox and Linux using device trees
that unambiguously identify the boot devices.

Do you have a scheme in mind on how to detect the boot medium in x86
Linux without depending on a UUID stored to the medium?

> 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.

Are you going to authenticate the state via HMAC?

We are fuzzing the DT parser because it's used for FIT images, but we
indeed didn't so far we treat the state layout definition as untrusted
input.

> 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?

On device-tree enabled systems, barebox fixed it up into the kernel
device tree. As we only support UEFI boot on x86, we could achieve
something similar via volatile EFI variables with runtime access:

barebox already sets LoaderTimeInitUSec or LoaderFirmwareInfo, so we can
pass the device tree similarly under the barebox GUID.

How about:

- barebox includes an empty device tree by default
- CONFIG_EXTERNAL_DTS_FRAGMENTS can be used to add the state layout
definition from outside the build
- barebox simply passes its internal DT in flattened form via the EFI
variable

> Happy to do the work on either if the direction is agreed.

Sounds great!

Are you going to use UKI profiles? If so, I could collect some thoughts
on how to make this more ergonomic.

Cheers,
Ahmad

> 
> Thanks,
> Raymond Zwarts
> 
> 

-- 
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 |