u-boot.git/boot/image-fit.c, branch main

Merge patch series "Fixes, cleanup and a test for the SPL FIT "full" loader"

2026-06-17T20:25:13Z

Francesco Valla says: This patch set contains a collection of small fixes and cleanups for the "full" FIT loader that can be used for the SPL. The main beneficiary is the falcon boot flow, but the same loader can be used also for U-Boot proper. Patch 1 was part of another set, but I decided to put it here for a better separation between plumbing (here) and new features (there). I kept the Reviewed-by tag collected from Simon in that occasion. Patch 6 introduces a new unit test covering most of the code that is being cleaned up. The set was tested on a i.MX93 FRDM, both with and without signature and to boot both U-Boot proper and the Linux kernel directly (i.e., falcon boot). Link: https://lore.kernel.org/r/20260604-spl_fit_full_cleanup-v1-0-ec036b5872e2@valla.it

boot: fit: fix FIT verification in SPL

2026-06-17T20:16:41Z

Align the behavior of fit_image_verify() called in SPL to the one in full U-Boot. In particular, this function is called when both CONFIG_SPL_LOAD_FIT_FULL and CONFIG_SPL_FIT_SIGNATURE are set (which can happen e.g. in case of secure falcon boot). Reviewed-by: Simon Glass Signed-off-by: Francesco Valla

image-fit: Validate external data offset and size

2026-06-12T21:38:27Z

fit_image_get_data() uses the data-position, data-offset, and data-size FIT properties without bounds checking. A crafted FIT image can specify values that cause out-of-bounds read during signature verification of an untrusted FIT. Validate that the external data offset and size are non-negative, and that the data region fits within the FIT image bounds. Signed-off-by: Anton Ivanov Reviewed-by: Simon Glass

image-fit: Limit recursion depth in fdt_check_no_at()

2026-06-12T21:35:58Z

fdt_check_no_at() recurses into every subnode without a depth limit. A deeply nested FIT image can exhaust the stack and crash U-Boot during signature verification of an untrusted FIT. Add a depth check using FDT_MAX_DEPTH to bound the recursion. Signed-off-by: Anton Ivanov

Merge patch series "allow control DTB to double as "FIT image""

2026-06-11T13:56:52Z

Rasmus Villemoes says: The commit message for patch 1 explains what it is I'd like to be able to do, but here's some more background: For a long time, we've embedded the boot script in the U-Boot binary by building a bootscript.itb, and using a .dtsi like / { config { bootscript = /incbin/("/path/to/bootscript.itb"); }; }; which in turn is mentioned in CONFIG_DEVICE_TREE_INCLUDES, that bootscript.itb FIT image has been embedded in U-Boot's control dtb. Running that was then a matter of doing fdt addr ${fdtcontroladdr} && fdt get addr bsaddr /config bootscript && source ${bsaddr} There are a couple of advantage of having the bootscript (and other script logic) embedded in the U-Boot binary. First, there's no need to figure out some separate partition to store the script in, and making sure that gets updated whenever the bootloader itself does. Second, one doesn't need to worry about verifying the script; whatever steps one needs to take to implement secure boot for U-Boot itself will by necessity also cover the control dtb (if nothing else then because that's where the public key for the kernel verification lives). And third, the boot script is automatically updated together with U-Boot itself; and if U-Boot is stored in an eMMC boot partition, that update is guaranteed to be atomic. Now with the stricter requirements of libfdt starting from v2026.04, the above command no longer worked, or only half the time, because the embedded FIT image may not land on an 8-byte aligned address. So that line had to be changed a little (line breaks added) fdt addr ${fdtcontroladdr} && fdt get addr bsaddr /config bootscript && fdt get size bssize /config bootscript && cp.b ${bsaddr} ${loadaddr} ${bssize} && source ${loadaddr} which is getting quite unwieldy. Then it struck me that one could perhaps simplify all of this quite a lot: Cut out the intermediate bootscript.itb, just create a .dtsi which directly puts a /images node inside the control dtb / { images { default = "bootscript"; bootscript { description = "Boot script"; data = /incbin/("/path/to/bootscript.sh"); type = "script"; compression = "none"; }; }; }; and treat the control dtb itself as a FIT image; so the command to put in $bootcmd becomes simply source ${fdtcontroladdr}:bootscript and embedding other pieces of callable scripts is quite trivial. And that almost works out-of-the-box, except for the fit_check_format() sanity check. Introduce a CONFIG_ knob that allows one to opt out of those sanity checks, for the special case of the address being checked being identical to gd->fdt_blob. Link: https://lore.kernel.org/r/20260602213013.558064-1-rv@rasmusvillemoes.dk

image-fit.c: introduce CONTROL_DTB_AS_FIT config knob

2026-06-11T13:56:45Z

Having scripts embedded one way or the other in the U-Boot binary means they are automatically verified/trusted by whatever mechanism verifies U-Boot. Writing those scripts in the built-in environment leads to backslatitis and missing or wrong quoting and is generally not very readable or maintainable. Maintaining scripts in external files allows one to have both syntax highlighting and to some extent apply shellcheck on it (though U-Boot's shell is of course not quite POSIX sh, so some '#shellcheck disable' directives are needed). Getting those into the U-Boot binary is then a matter of having a suitable .dtsi file such as / { images { default = "boot"; boot { description = "Bootscript"; data = /incbin/("boot.sh"); type = "script"; compression = "none"; }; factory-reset { description = "Script for performing factory reset"; data = /incbin/("factory-reset.sh"); type = "script"; compression = "none"; }; }; }; and making that part of CONFIG_DEVICE_TREE_INCLUDES, so that U-Boot's control DTB effectively doubles as a FIT image containing a few "script" entries. At run-time, one's default bootcommand can then simply be source ${fdtcontroladdr}:boot Except of course that the control DTB is in fact not quite a FIT image. The lack of timestamp and description properties could potentially be worked around (by just adding those via that same .dtsi), but the no-@ check is not possible to get around. But since the control dtb is by definition trusted, we can make an exception for that particular address, if the new CONTROL_DTB_AS_FIT config option is enabled. One can of course build an ordinary FIT image with those scripts. However, that requires extra steps in the boot command for loading that script from storage, requires one to use "configurations" for pointing at a single script to run, and signing the FIT image using the same key used for verifying the kernel. Moreover, in certain situations, such as bootstrapping/production, there is no place to load that FIT image from, and it is much simpler to just have the necessary scripts be part of the U-Boot image itself. Reviewed-by: Simon Glass Signed-off-by: Rasmus Villemoes

Merge patch series "fit: dm-verity support"

2026-05-27T19:44:20Z

Daniel Golle says: This series adds dm-verity support to U-Boot's FIT image infrastructure. It is the first logical subset of the larger OpenWrt boot method series posted as an RFC in February 2026 [1], extracted here for independent review and merging. OpenWrt's firmware model embeds a read-only squashfs or erofs root filesystem directly inside a uImage.FIT container as a FILESYSTEM-type loadable FIT image. At boot the kernel maps this sub-image directly from the underlying block device via the fitblk driver (/dev/fit0, /dev/fit1, ...), the goal is that the bootloader never even copies it to RAM. dm-verity enables the kernel to verify the integrity of those mapped filesystems at read time, with a Merkle hash tree stored contiguously in the same sub-image just after the data. Two kernel command-line parameters are required: dm-mod.create= -- the device-mapper target table for the verity device dm-mod.waitfor= -- a comma-separated list of block devices to wait for before dm-init sets up the targets (needed when fitblk probes late, e.g. because it depends on NVMEM calibration data) The FIT dm-verity node schema was upstreamed into the flat-image-tree specification [2], which this implementation tries to follow exactly. The runtime feature is guarded behind CONFIG_FIT_VERITY. If not enabled the resulting binary size remains unchanged. If enabled the binary size increases by about 3kB. [1] previous submissions: RFC: https://www.mail-archive.com/u-boot@lists.denx.de/msg565945.html v1: https://www.mail-archive.com/u-boot@lists.denx.de/msg569472.html v2: https://www.mail-archive.com/u-boot@lists.denx.de/msg570599.html v3: https://www.mail-archive.com/u-boot@lists.denx.de/msg573223.html v4: https://www.mail-archive.com/u-boot@lists.denx.de/msg574000.html [2] flat-image-tree dm-verity node spec: https://github.com/open-source-firmware/flat-image-tree/commit/795fd5fd7f0121d0cb03efb1900aafc61c704771 Link: https://lore.kernel.org/r/cover.1778887196.git.daniel@makrotopia.org

boot: fit: support generating DM verity cmdline parameters

2026-05-27T19:41:33Z

Add fit_verity_build_cmdline(): when a FILESYSTEM loadable carries a dm-verity subnode, construct the dm-mod.create= kernel cmdline parameter from the verity metadata (block-size, data-blocks, algo, root-hash, salt) and append it to bootargs. Also add dm-mod.waitfor=/dev/fit0[,/dev/fitN] for each dm-verity device so the kernel waits for the underlying FIT block device to appear before setting up device-mapper targets. This is needed when the block driver probes late, e.g. because it depends on NVMEM calibration data. The dm-verity target references /dev/fitN where N is the loadable's index in the configuration -- matching the order Linux's FIT block driver assigns block devices. hash-start-block is read directly from the FIT dm-verity node; mkimage ensures its value equals num-data-blocks by invoking veritysetup with --no-superblock. Signed-off-by: Daniel Golle Reviewed-by: Simon Glass

Merge patch series "boot/fit: use fdt_for_each_subnode() in image-fit.c"

2026-05-25T19:44:28Z

Aristo Chen says: This series ends with replacing the verbose fdt_next_node() + ndepth idiom in boot/image-fit.c with fdt_for_each_subnode(), bringing the file in line with boot/image-fit-sig.c. Six of the seven sites in image-fit.c predate the macro by 2-6 years; the seventh was copy-pasted from a neighbour in 2015 just after the macro landed. The old idiom is legacy, not a deliberate technical choice. Converting straight to the macro turned out to need a prerequisite, which is patch 1. fit_print_contents() reads the default-config property using the loop variable left over after iterating /images children. With /images defined first in the source (the conventional layout) libfdt's walker happens to leave that variable pointing at /configurations and the read works. With /configurations defined first the read returns NULL and the "Default Configuration" line is silently omitted. fdt_for_each_subnode()'s post-loop value is unconditionally a negative error code, so a naive conversion would have made the missing line the unconditional behaviour. Patch 1 reads the property from confs_noffset directly and removes the layout dependency. Patch 2 adds a regression test for the configs-before-images layout, which had no coverage. Patch 3 is the mechanical conversion at all seven sites, equivalence-preserving as described in the per-patch message. Link: https://lore.kernel.org/r/20260508213217.3807786-1-aristo.chen@canonical.com

boot/fit: use fdt_for_each_subnode() in image-fit.c

2026-05-25T19:44:11Z

Replace the verbose fdt_next_node() + ndepth pattern with the fdt_for_each_subnode() macro at all seven sites in boot/image-fit.c where the loop only ever processes direct children. The macro is already defined in and used in boot/image-fit-sig.c, so this brings image-fit.c in line with the rest of the FIT code. The conversions are equivalence-preserving: - fit_get_subimage_count(): the depth-1 filter and the macro are both restricted to direct children. - fit_conf_print(): the parameter is named noffset, so the loop now uses sub_noffset to keep the parent reference stable. - fit_print_contents(): the count reset that lived inside the for initialiser is moved out as an explicit assignment before each loop, so the second loop still starts from zero. - fit_image_print(): straightforward replacement. - fit_all_image_verify(): same shape as the print loops, with the count reset moved out as an explicit assignment before the loop. - fit_conf_find_compat(): the body's "if (ndepth > 1) continue" guard is redundant once the macro is in use, and is dropped. No behaviour changes outside of these mechanical reductions. Local ndepth declarations that are no longer referenced are removed. Signed-off-by: Aristo Chen Reviewed-by: Simon Glass