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

[Daniel Golle <daniel@makrotopia.org>]

On Tue, Feb 24, 2026 at 08:24:46AM -0600, Tom Rini wrote:
> On Tue, Feb 24, 2026 at 12:37:19AM +0000, Daniel Golle wrote:
> > 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.
> 
> Can you use https://www.file.io/ perhaps? And split as needed.

Nice, I didn't know that one. Thank you, that's helpful.

https://limewire.com/d/eJwOl#MYQunGl6LF


> 
> > Meanwhile, as the content of the large data blobs probably anyway
> > doesn't matter for this discussion, here is the decompiled FIT structure:
> 
> It doesn't matter but it does help me when poking around. Thanks for the
> dts dump. But please note I had a several other questions still open. I
> tried to not complicate things by sending them as separate replies but
> maybe that made them harder to see? Thanks.

I'll read up on all your questions in patchwork one more time and try
finding what is still unanswered. Expect my replies today ;)