Re: [RFC PATCH 00/20] boot: add OpenWrt boot method and on-demand FIT loading

[Daniel Golle <daniel@makrotopia.org>]

On Wed, Feb 18, 2026 at 02:33:14PM -0600, Tom Rini wrote:
> On Wed, Feb 18, 2026 at 05:25:20PM +0000, Daniel Golle wrote:
> > On Wed, Feb 18, 2026 at 09:58:39AM -0600, Tom Rini wrote:
> > > On Tue, Feb 17, 2026 at 10:25:13PM +0000, Daniel Golle wrote:
> > > > [...]
> > > > As the existing code expects the whole image to reside in RAM and only
> > > > take care of validation, decompression and relocation, I had to extend
> > > > image-fit.c to use the image_loader to only load the parts *from
> > > > storage* which are actually needed, and if possible, load them directly
> > > > to where they are supposed to go. Imho, the code is simple enough to
> > > > just look at it:
> > > > 
> > > > https://patchwork.ozlabs.org/project/uboot/patch/ab7837536e4567b90d7cb662984dd7e637ef4361.1771275704.git.daniel@makrotopia.org/
> > > > 
> > > > At this stage (because I first wanted to discuss the general approach)
> > > > the patch still skips some parts of image-fit.c, which is obviously not
> > > > acceptable for upstream inclusion, but good enough to demonstrate the
> > > > idea and also try it in practise.
> > > > 
> > > > Ie. the 'goto storage_loaded' has to go away and all of image-fit.c has
> > > > to be changed to equally work on RAM-backed or storage-backed images.
> > > 
> > > I was talking with Marek to recall some of the details about what we can
> > > and can't (easily..) do today with external data and he remidned me of
> > > something. So one big concern here is that we have to be care to not
> > > re-open things like:
> > > https://nvd.nist.gov/vuln/detail/CVE-2023-39902
> > > or otherwise allow for mix-and-match type attacks by having some sort of
> > > partial reads allowed.
> > > 
> > > So a specialized partial-read of FIT images, in full U-Boot (not just
> > > SPL), is something to figure out, but may also invalidate one of your
> > > design goals because you do have to authenticate the whole image, unless
> > > there's something both secure and clever I'm missing.
> > 
> > The idea here is to have one or more IH_TYPE_FILESYSTEM subimages which
> > do not have hash-* subnodes at all, hence, if there is anyway nothing to
> > validate and they do not need to be loaded to RAM (ie. no load address),
> > they can be skipped entirely, even if listed as 'loadable' (which is how
> > the parser in the kernel currently knows which filesystem image to map;
> > we could introduce a new property different from 'loadables', of course).
> > Everything else which is part of the selected configuration node of
> > course has to be loaded and authenticated.
> > 
> > To compensate for the authentication of IH_TYPE_FILESYSTEM subimages not
> > done by U-Boot before launching Linux, the dm-verity root hash passed to
> > Linux via cmdline should be part of the signed configuration, eg. by
> > including an image of IH_TYPE_SCRIPT modifying 'bootargs', or by coming
> > up with a new image type specifically for that purpose. Or, even better
> > but a bit more involved, include the dm-verity roothash in the ITS spec
> > instead of the hash-* nodes.
> > 
> > In terms of security, anyway only dm-verity makes sense, as there is no
> > point in validating the filesystem subimage if what is validated then
> > isn't also what is used -- one could quickly swap the storage device
> > after U-Boot has launched the kernel and before Linux mounts the rootfs
> > (from storage!) ending up with a different rootfs than what U-Boot had
> > previously validated when authenticating the image.
> 
> Right, OK. What I was thinking about, but Marek corrected me on, is
> about where we may or may not have problems about authentication. So
> long as we start by reading in the whole of the FIT (which excludes
> external data, being external) and start the authentication with that,
> we should be fine.
> 
> I have some other questions / concerns still, but there's also still a
> number of other emails I sent that're outstanding. So, can you please
> link to an itb that would be making use of your proposed feature? Being
> able to examine that would help me be more precise in my own questions,
> thanks.

I don't have any option at hand to host larger binaries anywhere public.

If you know any service which allows to do this for free without
requiring a complicated and personal-data-exposing sign-up procedure,
please let me know, I'll use that.

Meanwhile, as the content of the large data blobs probably anyway
doesn't matter for this discussion, here is the decompiled FIT structure:

/dts-v1/;

/ {
	timestamp = <0x69987422>;
	description = "ARM64 OpenWrt FIT (Flattened Image Tree)";
	#address-cells = <0x01>;

	images {

		kernel-1 {
			data-size = <0x5e4cdb>;
			data-position = <0x4000>;
			description = "ARM64 OpenWrt Linux-6.12.71";
			type = "kernel";
			arch = "arm64";
			os = "linux";
			compression = "gzip";
			load = <0x44000000>;
			entry = <0x44000000>;

			hash-1 {
				value = <0x5e864feb>;
				algo = "crc32";
			};

			hash-2 {
				value = <0x1029dbef 0xda4938de 0x16eda8c5 0x9c0fffc2 0x1a4c458f>;
				algo = "sha1";
			};
		};

		fdt-1 {
			data-size = <0x7d10>;
			data-position = <0x5e9000>;
			description = "ARM64 OpenWrt bananapi_bpi-r3 device tree blob";
			type = "flat_dt";
			load = <0x43f00000>;
			arch = "arm64";
			compression = "none";

			hash-1 {
				value = <0x331fdfaf>;
				algo = "crc32";
			};

			hash-2 {
				value = <0x4930ba36 0xe594a76b 0xcf6ba90b 0xa8c92ae5 0xdc68ed66>;
				algo = "sha1";
			};
		};

		fdt-mt7986a-bananapi-bpi-r3-emmc {
			data-size = <0x405>;
			data-position = <0x5f1000>;
			description = "ARM64 OpenWrt bananapi_bpi-r3 device tree overlay mt7986a-bananapi-bpi-r3-emmc";
			type = "flat_dt";
			arch = "arm64";
			compression = "none";

			hash-1 {
				value = <0x59209fd3>;
				algo = "crc32";
			};

			hash-2 {
				value = <0xb76ad9bb 0x9619b789 0x8e920f02 0x27be0a3a 0x6154b007>;
				algo = "sha1";
			};
		};

		fdt-mt7986a-bananapi-bpi-r3-nand {
			data-size = <0x46c>;
			data-position = "", "_ ";
			description = "ARM64 OpenWrt bananapi_bpi-r3 device tree overlay mt7986a-bananapi-bpi-r3-nand";
			type = "flat_dt";
			arch = "arm64";
			compression = "none";

			hash-1 {
				value = <0xaeedea4c>;
				algo = "crc32";
			};

			hash-2 {
				value = <0xc47f4473 0xcf3eb99a 0x284f63a0 0xb508857d 0xed829f97>;
				algo = "sha1";
			};
		};

		fdt-mt7986a-bananapi-bpi-r3-nor {
			data-size = <0x4be>;
			data-position = "", "_0";
			description = "ARM64 OpenWrt bananapi_bpi-r3 device tree overlay mt7986a-bananapi-bpi-r3-nor";
			type = "flat_dt";
			arch = "arm64";
			compression = "none";

			hash-1 {
				value = <0xa3898f18>;
				algo = "crc32";
			};

			hash-2 {
				value = <0xc45f4ad9 0x30273fbc 0x6721b946 0xa380aca1 0xc9bbd5a4>;
				algo = "sha1";
			};
		};

		fdt-mt7986a-bananapi-bpi-r3-sd {
			data-size = <0x36b>;
			data-position = "", "_@";
			description = "ARM64 OpenWrt bananapi_bpi-r3 device tree overlay mt7986a-bananapi-bpi-r3-sd";
			type = "flat_dt";
			arch = "arm64";
			compression = "none";

			hash-1 {
				value = <0xd0cb47a7>;
				algo = "crc32";
			};

			hash-2 {
				value = <0xb62232a8 0x23113c8a 0xc6973ef9 0x1748f275 0xe6e423fc>;
				algo = "sha1";
			};
		};

		fdt-mt7986a-bananapi-bpi-r3-respeaker-2mics {
			data-size = <0x5b2>;
			data-position = "", "_P";
			description = "ARM64 OpenWrt bananapi_bpi-r3 device tree overlay mt7986a-bananapi-bpi-r3-respeaker-2mics";
			type = "flat_dt";
			arch = "arm64";
			compression = "none";

			hash-1 {
				value = <0xc8d3f33c>;
				algo = "crc32";
			};

			hash-2 {
				value = <0x29e3a558 0x75e9a9d8 0x34d88eaa 0x5c134e78 0xa05deef9>;
				algo = "sha1";
			};
		};

		rootfs-1 {
			data-size = <0x1005000>;
			data-position = "", "_`";
			description = "ARM64 OpenWrt bananapi_bpi-r3 rootfs";
			type = "filesystem";
			arch = "arm64";
			compression = "none";

			hash-1 {
				value = <0xde4b8717>;
				algo = "crc32";
			};

			hash-2 {
				value = <0x13535da6 0x7fa95cda 0x9331dc1 0x1cd01dd 0xaea3701e>;
				algo = "sha1";
			};

			dm-verity {
				block-size = <0x1000>;
				data-blocks = <0xfe3>;
				algo = "sha256";
				root-hash = "61b01a3b94d7e1166ed34bbdf60a65944f49fcebced531d5cdc98b8b65b2a898";
				salt = "73a9020ed5a88a54f8392dd1b141a6def3072461061275db72ef18e6e1851c6c";
			};
		};
	};

	configurations {
		default = "config-mt7986a-bananapi-bpi-r3";

		config-mt7986a-bananapi-bpi-r3 {
			description = "OpenWrt bananapi_bpi-r3";
			kernel = "kernel-1";
			fdt = "fdt-1";
			loadables = "rootfs-1";
		};

		mt7986a-bananapi-bpi-r3-emmc {
			description = "OpenWrt bananapi_bpi-r3 overlay mt7986a-bananapi-bpi-r3-emmc";
			fdt = "fdt-mt7986a-bananapi-bpi-r3-emmc";
		};

		mt7986a-bananapi-bpi-r3-nand {
			description = "OpenWrt bananapi_bpi-r3 overlay mt7986a-bananapi-bpi-r3-nand";
			fdt = "fdt-mt7986a-bananapi-bpi-r3-nand";
		};

		mt7986a-bananapi-bpi-r3-nor {
			description = "OpenWrt bananapi_bpi-r3 overlay mt7986a-bananapi-bpi-r3-nor";
			fdt = "fdt-mt7986a-bananapi-bpi-r3-nor";
		};

		mt7986a-bananapi-bpi-r3-sd {
			description = "OpenWrt bananapi_bpi-r3 overlay mt7986a-bananapi-bpi-r3-sd";
			fdt = "fdt-mt7986a-bananapi-bpi-r3-sd";
		};

		mt7986a-bananapi-bpi-r3-respeaker-2mics {
			description = "OpenWrt bananapi_bpi-r3 overlay mt7986a-bananapi-bpi-r3-respeaker-2mics";
			fdt = "fdt-mt7986a-bananapi-bpi-r3-respeaker-2mics";
		};
	};
};