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.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. > > > > > > 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. > 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. -- Tom
signature.asc
Description: PGP signature
