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 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.