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 05:25:29PM +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.

Thinking about this a bit more I think that it would still be good
to have a way to validate the whole image also within U-Boot, but
add a way to mark the image as "no need to authenticate at boot" using
a new property in ITS, eg. containing the dm-vierty root hash which is
passed on to Linux via cmdline.
This would have the advantage that U-Boot can still authenticate the
whole image because hash-* and sign-* nodes are, eg. when loading it via TFTP and before writing it flash
during firmware recovery.

What do you think?

Do you agree that having 'dm-verity-root-hash = "....."' in addition to
the existing 'hash-*' and/or 'signature-*' properties would be a good
idea, and that then allowing to skip authenticating that specific
subimage at boot (but not in other cases, eg. 'iminfo' should still
always authenticate the whole image).

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