On Wed, Feb 18, 2026 at 11:08:48PM +0000, Daniel Golle wrote: > 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).
It's a question that requires a bit of thought. As part of the thing is that we have to validate the FIT as a whole (excluding external data) before we can move on to working with the contents of the FIT. After that, what is stored in the config nodes and so forth is a separate question, and at-rest security provides its own challenges that also depend on what the hardware can/can't provide for us too. -- Tom
signature.asc
Description: PGP signature
