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

Hello Ahmad,

> What's a runtime identity? The disk's UUID?

Yes, the containing disk's GPT DiskGUID. "Runtime identity" was
imprecise; I did not mean the partition's PARTUUID.

> We would need to either derive some secret that can be exported to
> userspace or to use AF_ALG with a key in the kernel keyring.

Linux 6.12's AF_ALG supports ALG_SET_KEY_BY_KEY_SERIAL for keyed hashes
and accepts trusted keys. That gives us a Linux-side path to evaluate,
but dt-utils does not implement that provider. AF_ALG is now deprecated
upstream, so it should remain an implementation detail rather than the
provider interface.

> It's not a built-in source per se, but the files specified there are
> included after barebox' own built-in DT.
>
> built-in state should always take precedence over the external.
> We can add a Kconfig option to control this later should a need arise.

Understood. That precedence is sufficient for KelvaneOS; we do not need
another Kconfig option now.

> Analogous to global.linux.bootargs.*, I think we should probably add
> global.efi.bootargs.* [...]
>
> That way you can have barebox select a profile (@1/@2 at the start of
> the load options).

That fits. A/B generations will remain separate UKIs; if we use
profiles, the proposed EFI bootargs can carry the profile selector.

Thanks,
Raymond Zwarts

> On 5 Aug 2026, at 21:24, Raymond | KelvaneOS <[email protected]> wrote:
> 
> 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