On Tue, Feb 17, 2026 at 10:25:13PM +0000, Daniel Golle wrote: > On Tue, Feb 17, 2026 at 03:18:53PM -0600, Tom Rini wrote: > > On Tue, Feb 17, 2026 at 09:07:31PM +0000, Daniel Golle wrote: > > > On Tue, Feb 17, 2026 at 01:35:34PM -0600, Tom Rini wrote: > > > > On Tue, Feb 17, 2026 at 07:28:03PM +0000, Daniel Golle wrote: > > > > > On Tue, Feb 17, 2026 at 12:13:58PM -0600, Tom Rini wrote: > > > > > > On Mon, Feb 16, 2026 at 09:21:14PM +0000, Daniel Golle wrote: > > > > > > > Hi all, > > > > > > > > > > > > > > This RFC series adds a new boot method for OpenWrt's "uImage.FIT > > > > > > > with > > > > > > > embedded rootfs" firmware model, along with the underlying > > > > > > > infrastructure > > > > > > > to load FIT images on-demand directly from storage devices > > > > > > > without copying > > > > > > > them entirely to RAM first. > > > > > > > > > > > > > > I would like to discuss the design with U-Boot maintainers and > > > > > > > fellow > > > > > > > OpenWrt developers before submitting a formal patch series. > > > > > > [snip] > > > > > > > Three storage backends: > > > > > > > > > > > > > > - Block device (eMMC, SD, SATA, NVMe, USB mass storage, virtio) > > > > > > > - MTD (SPI-NOR, raw NOR, raw NAND with bad block skipping) > > > > > > > - UBI volume (SPI-NAND, raw NAND) > > > > > > > > > > > > > > The "bootm" command is extended to accept a storage device > > > > > > > specification > > > > > > > instead of a RAM address: > > > > > > > > > > > > > > bootm mmc 0:4 # boot FIT from eMMC partition 4 > > > > > > > bootm mtd recovery # boot FIT from MTD partition "recovery" > > > > > > > bootm ubi recovery # boot FIT from UBI volume "recovery" > > > > > > > > > > > > > > This infrastructure is independently useful beyond the OpenWrt > > > > > > > boot > > > > > > > method. Any board that stores a FIT image directly in a partition > > > > > > > (rather than as a file on a filesystem) can benefit from on-demand > > > > > > > subimage loading. > > > > > > > > > > > > For the user interface portion of this, since this is implementing > > > > > > bootmeths, this should all be handled under bootflow/bootdev/etc > > > > > > commands, and not adding further options to bootm. > > > > > > > > > > I thought it would be useful independently of > > > > > bootmeth/bootflow/bootdev > > > > > for `bootm` to have these options, as it will allow to gradually > > > > > migrate > > > > > a large number of our downstream boards. Many of them at this point > > > > > still require scripts to handle things like extracting MAC addresses > > > > > from flash (in ways the original vendor has decided to store them), > > > > > updating U-Boot or TF-A blobs, ... and migrating all of that to use > > > > > bootmeth/bootflow/... will take time. > > > > > > > > > > In the meantime, already getting rid of (duplicate) scripts "read > > > > > firmware from mmc/ubi/mtd" would be feasible, is less of a burden and > > > > > easy to test for people who got the respective board at hand. > > > > > > > > > > Also, testing loading (partial) images directly from storage outside > > > > > of bootmeth has been very useful during development. > > > > > > > > > > Would it be an option to hide the new bootm cmdline features behind an > > > > > additional Kconfig option maybe? > > > > > > > > I worry that if we add this to bootm upstream, it'll be another > > > > interface that can't ever go away. Building off of another bit of > > > > feedback I sent after this message here, I think the testing side of > > > > this support should be handled with CMD_something.._GENERIC, similar to > > > > CMD_FS_GENERIC. > > > > > > Hm... The tricky part is kinda not the "load from somewhere" as that > > > just ends up calling the .read() op, which usually is more or less > > > identical to what some existing commands are already doing, hence easy > > > to use 'mmc read ...', 'mtd read ...', 'ubi read ...' for testing. > > > > Yes, this part would be more of just an easier syntax, perhps "block > > read type ...". > > > > > Seeing that all the steps in 'bootm' are working, sub-images are > > > correctly loaded (or skipped), verification steps (hashes, signature, > > > ...) are all working was the more difficult part... > > > > Presumably because of the partial read part? That does get back to > > Marek's earlier question about if you can't get that already with > > "mkimage -E" and I didn't see the answer, sorry. > > For partial read to work, using "mkimage -E" is a requirement, everything > else wouldn't make sense. However, that still doesn't magically solve > loading (and validating) on the needed parts from storage to RAM, at this > point (ie. without this series) it is still expected that the whole image > has been loaded to RAM at the point `bootm` is called. > > > > > > > But perhaps not as one other part of this I wanted to ask about is, > > > > does this only support reading FIT images which set their load > > > > address? Or is there a call somewhere to lmb_alloc to grab an arbitrary > > > > hunk of memory somewhere? > > > > > > In order to kinda do the same as was happening previously when first > > > loading the whole image from flash to $loadaddr, I've implemented a > > > trivial allocator for chunks with no defined load address in FIT. > > > In this case, image_loader_map() is called and loads to alloc_ptr, > > > which points to $loadaddr on init, and is then bumped by the > > > size loaded. I can use the lmb allocator instead, it's cleaner than > > > open-coding this. > > > > Oh yes, this cannot be open coded. The lmb framework is how we avoid > > some classes of security issues and just open coding that brings them > > all right back. But this is also something that's solved, today, for FIT > > images of KERNEL_NOLOAD so we shouldn't need anything new here, either. > > +1 > > > > > > In case of known load address (ie. specified for that sub-image in FIT) > > > and compression being IH_COMP_NONE, image_loader_map_to() is called > > > which directly loads that sub-image to the specified target address, no > > > allocation what-so-ever. > > > > Is that with the existing code, or did you write something new here as > > well? > > 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. -- Tom
signature.asc
Description: PGP signature
