All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rasmus Villemoes <ravi@prevas.dk>
To: u-boot@lists.denx.de
Cc: Tom Rini <trini@konsulko.com>, Simon Glass <sjg@chromium.org>,
	Quentin Schulz <quentin.schulz@cherry.de>,
	Rasmus Villemoes <ravi@prevas.dk>
Subject: [PATCH 1/2] image-board.c: exempt gd->fdt_blob from fit_check_format() check
Date: Tue, 12 May 2026 18:16:30 +0200	[thread overview]
Message-ID: <20260512161631.284143-2-ravi@prevas.dk> (raw)
In-Reply-To: <20260512161631.284143-1-ravi@prevas.dk>

Having scripts embedded one way or the other in the U-Boot binary
means they are automatically verified/trusted by whatever mechanism
verifies U-Boot.

Writing those scripts in the built-in environment leads to
backslatitis and missing or wrong quoting and is generally not very
readable or maintainable.

Maintaining scripts in external files allows one
to have both syntax highlighting and to some extent apply shellcheck
on it (though U-Boot's shell is of course not quite POSIX sh, so some
'#shellcheck disable' directives are needed). Getting those into the
U-Boot binary is then a matter of having a suitable .dtsi file such as

/ {
	images {
		default = "boot";
		boot {
			description = "Bootscript";
			data = /incbin/("boot.sh");
			type = "script";
			compression = "none";
		};
		factory-reset {
			description = "Script for performing factory reset";
			data = /incbin/("factory-reset.sh");
			type = "script";
			compression = "none";
		};
	};
};

and making that part of CONFIG_DEVICE_TREE_INCLUDES, so that U-Boot's
control DTB effectively doubles as a FIT image containing a few
"script" entries. At run-time, one's default bootcommand can then
simply be

  source ${fdtcontroladdr}:boot

Except of course that the control DTB is in fact not quite a FIT
image. The lack of timestamp and description properties could
potentially be worked around, but the no-@ check is not possible to
get around. But since the control dtb is by definition trusted, we can
just excempt that particular address from the strict check.

One can of course build an ordinary FIT image with those
scripts. However, that requires extra steps in the boot command for
loading that script from storage, requires one to use "configurations"
for pointing at a single script to run, and signing the FIT image
using the same key used for verifying the kernel. Moreover, in certain
situations, such as bootstrapping/production, there is no place to
load that FIT image from, and it is much simpler to just have the
necessary scripts be part of the U-Boot image itself.

Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
---
 boot/image-board.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/boot/image-board.c b/boot/image-board.c
index 005d60caf5c..6cbc489be01 100644
--- a/boot/image-board.c
+++ b/boot/image-board.c
@@ -1037,7 +1037,7 @@ int image_locate_script(void *buf, int size, const char *fit_uname,
 			goto exit_image_format;
 		} else {
 			fit_hdr = buf;
-			if (fit_check_format(fit_hdr, IMAGE_SIZE_INVAL)) {
+			if (fit_hdr != gd->fdt_blob && fit_check_format(fit_hdr, IMAGE_SIZE_INVAL)) {
 				puts("Bad FIT image format\n");
 				return 1;
 			}
-- 
2.54.0


  reply	other threads:[~2026-05-12 16:16 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-12 16:16 [PATCH 0/2] allow control DTB to double as "FIT image" Rasmus Villemoes
2026-05-12 16:16 ` Rasmus Villemoes [this message]
2026-05-15 13:06   ` [PATCH 1/2] image-board.c: exempt gd->fdt_blob from fit_check_format() check Simon Glass
2026-05-12 16:16 ` [PATCH 2/2] test: hook up test of allowing control DTB to act as FIT image Rasmus Villemoes
2026-05-15 13:06   ` Simon Glass
2026-05-12 16:39 ` [PATCH 0/2] allow control DTB to double as "FIT image" Quentin Schulz
2026-05-13  8:03   ` Rasmus Villemoes
2026-05-15 13:33 ` [0/2] " Simon Glass

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=20260512161631.284143-2-ravi@prevas.dk \
    --to=ravi@prevas.dk \
    --cc=quentin.schulz@cherry.de \
    --cc=sjg@chromium.org \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.