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

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