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

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

[Raymond | KelvaneOS]

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

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

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

[Raymond | KelvaneOS]

Hello Ahmad,

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

You are right; adding alias stems alone does not establish a shared
device identity. Sorry, that suggestion was incomplete.

I was also imprecise about UUIDs: the requirement is to avoid a
per-installation PARTUUID in the build input, not to avoid runtime GPT
identifiers.

The patch I have in mind would resolve
efi_loaded_image->device_handle to the corresponding whole-disk cdev,
enumerate state-type partitions on that disk, require exactly one, and
fix the selected partition's runtime identity into the internal DT
exported through the EFI variable you propose below.

A non-block-backed/GPT origin or a match count other than one is an
error. The resolver would not scan other disks or select the first
match; KelvaneOS would treat the error as fatal rather than continue
with default state.

Linux would consume the fixed-up description and would not need to
reconstruct the EFI device hierarchy.

> Are you going to authenticate the state via HMAC?

Yes. HMAC itself is not an x86 issue. The unresolved part is provisioning
a protected shared secret to both barebox and the Linux writer.

The dt-utils provider I found is tied to CAAM/blob_gen. A key file on
the medium would work functionally but would not meet the offline
tampering threat model. Is a new secret-provider abstraction in
dt-utils the preferred direction for x86?

This is separate from trusting state.dtb: that description selects the
backend, layout and algo, so it can redirect the state or remove HMAC
before the state is authenticated.

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

My concern is the valid-input case: a well-formed replacement can still
change those semantics.

> 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

Yes, that addresses the layout issue cleanly. I had missed
CONFIG_EXTERNAL_DTS_FRAGMENTS as the built-in source; thanks.

For the Secure Boot configuration, the external ESP state.dtb must not
remain an alternative source when a built-in state description is
present. Would you prefer the built-in state node to suppress that path
automatically, or a separate Kconfig guard?

I would keep the HMAC key-provider work separate from the EFI disk
binding and DT handoff.

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

We will use signed UKIs. Profiles are under evaluation; the A/B
generations themselves will remain separate UKIs. Your thoughts would
be very welcome.

Thanks,
Raymond Zwarts