mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Raymond | KelvaneOS <raymond@kelvaneos.eu>
To: barebox@lists.infradead.org
Subject: barebox,state on the EFI payload: boot-disk binding and state.dtb trust
Date: Tue, 28 Jul 2026 14:45:20 +0200	[thread overview]
Message-ID: <146164AA-62BF-40AC-A83B-83F9D36CF356@kelvaneos.eu> (raw)

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



                 reply	other threads:[~2026-07-28 12:47 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=146164AA-62BF-40AC-A83B-83F9D36CF356@kelvaneos.eu \
    --to=raymond@kelvaneos.eu \
    --cc=barebox@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox