From: Ahmad Fatoum <a.fatoum@pengutronix.de>
To: barebox@lists.infradead.org
Cc: Ahmad Fatoum <a.fatoum@barebox.org>
Subject: [PATCH 04/11] Documentation: security: document trust for builtin devicetree
Date: Mon, 28 Sep 2026 13:26:59 +0200 [thread overview]
Message-ID: <20260928112731.1271094-5-a.fatoum@pengutronix.de> (raw)
In-Reply-To: <20260928112731.1271094-1-a.fatoum@pengutronix.de>
From: Ahmad Fatoum <a.fatoum@barebox.org>
barebox-dt-2nd.img exists to allow booting barebox like one would boot a
Linux kernel. This is a convenient way to use barebox without modifying
existent firmware, but it's not suitable for use as part of a boot chain
if the device tree hasn't been verified beforehand.
Spell that out in the documentations and also add the missing help text
for CONFIG_CRYPTO_BUILTIN_KEYS.
Signed-off-by: Ahmad Fatoum <a.fatoum@barebox.org>
---
Documentation/user/security.rst | 17 +++++++++++++++++
crypto/Kconfig | 8 ++++++++
2 files changed, 25 insertions(+)
diff --git a/Documentation/user/security.rst b/Documentation/user/security.rst
index 7160f8f8e3c2..d981d89268c8 100644
--- a/Documentation/user/security.rst
+++ b/Documentation/user/security.rst
@@ -56,6 +56,23 @@ fusing for both HABv4 and AHAB.
touch the subset of fuses relevant to most users. It's up to the integrators
to fuse away unneeded functionality like USB recovery or JTAG as needed.
+Ensuring the barebox devicetree is verified
+-------------------------------------------
+
+Whoever controls the devicetree barebox uses for itself can inject RSA keys
+to be used for FIT verification and control what drivers are probed.
+
+The devicetree must therefore be either:
+
+- verified by the previous boot stage before passing it to barebox
+
+- part of a barebox image and thus verified by the previous boot stage
+
+``barebox-dt-2nd.img`` is bootable like a Linux kernel and takes its
+devicetree from the previous stage. It's thus only suitable for verified
+boot if that stage verified the devicetree as well, e.g. because both are
+part of the same signed FIP image.
+
Loading firmware
----------------
diff --git a/crypto/Kconfig b/crypto/Kconfig
index 528e9a0d2204..977e502e8a14 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -130,6 +130,14 @@ config CRYPTO_BUILTIN_KEYS
bool "builtin keys"
select KEYTOC
select IDR
+ help
+ Compile public keys into barebox. See CRYPTO_PUBLIC_KEYS for how to
+ specify them and their keyrings.
+
+ This also enables reading RSA keys from /signature of the devicetree
+ barebox runs on, like U-Boot does with its control FDT. Such keys
+ always end up in the "fit" keyring. Prefer compiled-in keys. Either
+ way, the devicetree must be verified together with barebox.
config CRYPTO_PUBLIC_KEYS
depends on CRYPTO_BUILTIN_KEYS
--
2.47.3
next prev parent reply other threads:[~2026-09-28 11:33 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-28 11:26 [PATCH 00/11] Documentation: define a barebox threat model Ahmad Fatoum
2026-09-28 11:26 ` [PATCH 02/11] Documentation: security: clarify development key insecurity Ahmad Fatoum
2026-09-28 11:26 ` [PATCH 03/11] Documentation: security: require signature verification to be pinned Ahmad Fatoum
2026-09-28 11:26 ` Ahmad Fatoum [this message]
2026-09-28 11:27 ` [PATCH 05/11] Documentation: security: clarify the environment section Ahmad Fatoum
2026-09-28 11:27 ` [PATCH 06/11] Documentation: security: describe shell and environment as trust boundary Ahmad Fatoum
2026-09-28 11:27 ` [PATCH 07/11] Documentation: security: document the barebox update attack surface Ahmad Fatoum
2026-09-28 11:27 ` [PATCH 08/11] Documentation: security: update for barebox dm-verity support Ahmad Fatoum
2026-09-28 11:27 ` [PATCH 09/11] Documentation: security: add anchors for the different sections Ahmad Fatoum
2026-09-28 11:27 ` [PATCH 10/11] Documentation: define a barebox threat model Ahmad Fatoum
2026-09-28 11:27 ` [PATCH 11/11] README, SECURITY.md: link the threat model and security considerations Ahmad Fatoum
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=20260928112731.1271094-5-a.fatoum@pengutronix.de \
--to=a.fatoum@pengutronix.de \
--cc=a.fatoum@barebox.org \
--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