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