From: Ahmad Fatoum <a.fatoum@pengutronix.de>
To: barebox@lists.infradead.org
Cc: Ahmad Fatoum <a.fatoum@barebox.org>
Subject: [PATCH 01/11] Documentation: security: unnest hardening sections from dm-verity section
Date: Mon, 28 Sep 2026 13:26:56 +0200 [thread overview]
Message-ID: <20260928112731.1271094-2-a.fatoum@pengutronix.de> (raw)
In-Reply-To: <20260928112731.1271094-1-a.fatoum@pengutronix.de>
From: Ahmad Fatoum <a.fatoum@barebox.org>
The sections on disabling the shell, on the non-builtin environment and on
avoiding file systems were meant to be subsections of
"Ensuring the kernel is verified", but this got lost with the addition
of "Prevent the kernel from booting the rootfs in verity boots", which they
have nothing to do with.
Move them around to fix this. No change in content.
Signed-off-by: Ahmad Fatoum <a.fatoum@barebox.org>
---
Documentation/user/security.rst | 54 ++++++++++++++++-----------------
1 file changed, 27 insertions(+), 27 deletions(-)
diff --git a/Documentation/user/security.rst b/Documentation/user/security.rst
index a7b2cc61c9b0..657bcd690b8e 100644
--- a/Documentation/user/security.rst
+++ b/Documentation/user/security.rst
@@ -69,20 +69,6 @@ Firmware) should happen as early as possible, i.e., within the barebox
barebox will run with elevated permission, which greatly increases the attack
surface.
-Ensuring the kernel is verified
--------------------------------
-
-barebox can embed one or more RSA or ECDSA public keys that it will use to
-verify signed FIT images. In a verified boot system, barebox should not
-be allowed to boot any images that have not been signed by the correct key.
-This can be enforced by setting ``CONFIG_BOOTM_FORCE_SIGNED_IMAGES=y``
-and disabling any ways that could be used to override this.
-
-For development convenience ``CONFIG_CRYPTO_BUILTIN_DEVELOPMENT_KEYS``
-can be used to compile well known development keys into the barebox binary.
-The private keys for these keys can be found
-`[here] <https://github.com/pengutronix/ptx-code-signing-dev>`__.
-
Pinning the FIT configuration
-----------------------------
@@ -96,21 +82,19 @@ booted without altering any image. If that matters, ship only one configuration
per FIT, or name the configuration explicitly, e.g.
``bootm /dev/mmc0.kernel@conf-production``.
-Prevent the kernel from booting the rootfs in verity boots
-----------------------------------------------------------
+Ensuring the kernel is verified
+-------------------------------
-In systems, where barebox loads an initramfs that sets up a dm-verity rootfs and
-passes the location of the root file system on the kernel command-line, make
-sure not to use ``root=``!
-``root=`` is also interpreted by the kernel and can lead to the kernel mounting
-the rootfs without dm-verity, if the initramfs failed to load, e.g. due to a
-different compression algorithm.
+barebox can embed one or more RSA or ECDSA public keys that it will use to
+verify signed FIT images. In a verified boot system, barebox should not
+be allowed to boot any images that have not been signed by the correct key.
+This can be enforced by setting ``CONFIG_BOOTM_FORCE_SIGNED_IMAGES=y``
+and disabling any ways that could be used to override this.
-The fail-safe alternative is to use a parameter name understood only by the
-initramfs (e.g. ``verity_root=``) in all bootloader scripts. If the
-``root=$dev`` is fixed up by barebox dynamically, the
-:ref:`global.bootm.root_param <magicvar_global_bootm_root_param>` variable can
-be used to customize the name of the parameter passed to Linux.
+For development convenience ``CONFIG_CRYPTO_BUILTIN_DEVELOPMENT_KEYS``
+can be used to compile well known development keys into the barebox binary.
+The private keys for these keys can be found
+`[here] <https://github.com/pengutronix/ptx-code-signing-dev>`__.
Disabling the shell
^^^^^^^^^^^^^^^^^^^
@@ -154,6 +138,22 @@ Especially, :ref:`bootloader spec files <bootloader_spec>` should not be used
in verified boot setups and signed FIT images **must** be located outside
a file system and directly in a raw partition.
+Prevent the kernel from booting the rootfs in verity boots
+----------------------------------------------------------
+
+In systems, where barebox loads an initramfs that sets up a dm-verity rootfs and
+passes the location of the root file system on the kernel command-line, make
+sure not to use ``root=``!
+``root=`` is also interpreted by the kernel and can lead to the kernel mounting
+the rootfs without dm-verity, if the initramfs failed to load, e.g. due to a
+different compression algorithm.
+
+The fail-safe alternative is to use a parameter name understood only by the
+initramfs (e.g. ``verity_root=``) in all bootloader scripts. If the
+``root=$dev`` is fixed up by barebox dynamically, the
+:ref:`global.bootm.root_param <magicvar_global_bootm_root_param>` variable can
+be used to customize the name of the parameter passed to Linux.
+
Configuring barebox
-------------------
--
2.47.3
next prev parent reply other threads:[~2026-09-28 12:43 UTC|newest]
Thread overview: 12+ 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 ` Ahmad Fatoum [this message]
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 ` [PATCH 04/11] Documentation: security: document trust for builtin devicetree Ahmad Fatoum
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-2-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