u-boot.git/doc/usage/fit, branch next

tools: fit: sign all config image references

2026-08-25T23:12:40Z

Target-side configuration verification builds the signed-region list from every image-reference property in the selected configuration. Host-side signing still uses either the signature node sign-images property or the legacy kernel/fdt/script default list. This lets mkimage generate configuration signatures which U-Boot cannot verify when the configuration references other image types, such as firmware, loadables or ramdisk entries. It also lets the host and target disagree when sign-images names only a subset of the configuration images. Build the host-side signing list from the configuration properties in the same way as target-side verification. Use one shared property classifier so the host and target cannot drift apart again. This makes signed configurations cover the root node, the configuration node, every referenced image node, and its hash, cipher and dm-verity subnodes, regardless of image type. Warn when a legacy sign-images property is present, since it no longer limits the signed image list. Require every referenced image to have at least one hash subnode. Add sandbox coverage proving that a firmware reference omitted from sign-images is still recorded in hashed-nodes and verified. Update the signed-configuration documentation to describe the same rule and the hash-subnode requirement. Fixes: 2092322b31cc ("boot: Add fit_config_get_hash_list() to build signed node list") Signed-off-by: James Hilliard Reviewed-by: Simon Glass

Merge patch series "boot: fit: authenticate the dm-verity roothash"

2026-08-10T18:37:16Z

Daniel Golle says: A signed FIT configuration can delegate the integrity of a (potentially large) root filesystem image to the kernel's dm-verity instead of having U-Boot hash the whole payload at boot: the FIT carries a "dm-verity" subnode with the roothash, salt and block parameters, U-Boot passes the roothash to Linux through the dm-mod.create bootargs, and dm-verity then validates the filesystem block by block against it. For that to be safe the roothash has to be trusted, and in a signed configuration the only thing that establishes trust is the configuration signature. The roothash was not covered by it. fit_config_add_hash() collected the image node, its hash subnodes and its cipher subnode into the signed region, but not the dm-verity subnode, so the roothash, the sole integrity anchor for the filesystem, was left unsigned. The result is a verified-boot bypass for the root filesystem: an attacker who can rewrite the boot medium can replace the filesystem, recompute a matching dm-verity tree, write the new roothash into the unsigned dm-verity subnode, and the configuration signature still verifies. dm-verity then faithfully validates the malicious filesystem against the attacker's roothash. This series closes the gap. Link: https://lore.kernel.org/r/cover.1785276461.git.daniel@makrotopia.org

boot: fit: cover the dm-verity roothash with the config signature

2026-08-10T18:32:41Z

A dm-verity protected filesystem image is not hashed by U-Boot when it is loaded; its integrity is delegated to the kernel, which validates the filesystem on the fly against the roothash taken from the FIT dm-verity subnode. The roothash is therefore the sole integrity anchor for the filesystem, yet fit_config_add_hash() only adds the image node, its hash subnodes and its cipher subnode to the signed region, leaving the dm-verity subnode (roothash, salt and block parameters) unsigned. An attacker able to rewrite the boot medium could then replace both the filesystem and the roothash, recompute a matching dm-verity tree and keep the configuration signature valid, defeating verified boot for the root filesystem. Add the dm-verity subnode to the list of nodes covered by the configuration signature, both when signing (tools/image-host.c) and when verifying (boot/image-fit-sig.c), so the roothash and salt are authenticated together with the rest of the configuration. Signed-off-by: Daniel Golle Reviewed-by: Tom Rini Reviewed-by: Simon Glass

doc: Switch from setenv to env set

2026-07-27T16:50:27Z

The "env" command is the recommended environment management command, its "set" subcommand is the equivalent replacement for legacy "setenv" command. Update the documentation to use the contemporary "env set" command instead of legacy "setenv" command. Note that the "setenv" command is unlikely to be removed from U-Boot in the near future due to it being integral part of the command line ABI. Implemented using: $ sed -i 's@\@env set@g' $(git grep -li '\' doc/) README Signed-off-by: Marek Vasut

fit: prefer the default configuration on best-match ties

2026-07-24T16:46:16Z

With CONFIG_FIT_BEST_MATCH, fit_conf_find_compat() selects the configuration matching the most specific U-Boot compatible string; on equal matches the first listed configuration wins and the configurations node 'default' property is never consulted. A FIT whose configurations all share the same base devicetree compatible (e.g. one manifest carrying a base tree plus overlay combinations for a single board) therefore always boots the first configuration, silently ignoring the default chosen by the manifest author. Break score ties in favour of the default configuration. A strictly better compatible match still wins over it, and FITs without a default keep the current first-listed behaviour. Reviewed-by: Simon Glass Reviewed-by: Tom Rini Signed-off-by: Carlo Caione

doc: fit: add dm-verity boot parameter documentation

2026-05-27T19:41:33Z

Add documentation for CONFIG_FIT_VERITY which allows U-Boot to construct dm-mod.create= and dm-mod.waitfor= kernel command-line parameters from dm-verity metadata embedded in FIT filesystem sub-images. The new document covers the relationship between FIT loadable indices and the /dev/fitN block devices that the Linux uImage.FIT block driver creates, provides a complete .its example with a dm-verity-protected SquashFS root filesystem, describes all required and optional dm-verity subnode properties and explains how mkimage generates the verity metadata automatically. dm-verity is only supported for external-data FIT images (mkimage -E); mkimage aborts with an error if the flag is omitted. Signed-off-by: Daniel Golle Reviewed-by: Simon Glass

doc: overlay-fdt-boot: .dtbos do not need load addresses

2026-03-27T09:57:08Z

The requirement that .dtbos have load addresses in the FIT image vanished five years ago with 4c531d9f58b ("fit: Load DTO into temporary buffer and ignore load address") Fix the documentation accordingly. Signed-off-by: Rasmus Villemoes Reviewed-by: Marek Vasut

treewide: fix uImage.FIT document paths

2026-03-27T09:50:29Z

Commit 488445cefa1 ("doc: Move FIT into its own directory") moved the documentation in doc/uImage.FIT to doc/usage/fit, subsequently all documents and example sources have been converted to reStructuredText. Fix (almost) all of the remaining occurrences of the old path and filenames across the tree. The exception is doc/uImage.FIT/command_syntax_extensions.txt which apparently has been removed entirely, or at least I was unable to locate where that document is now. Signed-off-by: Daniel Golle

boot: Add fit_config_get_hash_list() to build signed node list

2026-03-09T15:49:50Z

The hashed-nodes property in a FIT signature node lists which FDT paths are included in the signature hash. It is intended as a hint so should not be used for verification. Add a function to build the node list from scratch by iterating the configuration's image references. Skip properties known not to be image references. For each image, collect the path plus all hash and cipher subnodes. Use the new function in fit_config_check_sig() instead of reading 'hashed-nodes'. Update the test_vboot kernel@ test case: fit_check_sign now catches the attack at signature-verification time (the @-suffixed node is hashed instead of the real one, causing a mismatch) rather than at fit_check_format() time. Update the docs to cover this. The FIT spec can be updated separately. Signed-off-by: Simon Glass Closes: https://lore.kernel.org/u-boot/20260302220937.3682128-1-trini@konsulko.com/ Reported-by: Apple Security Engineering and Architecture (SEAR) Tested-by: Tom Rini

ARM: bootm: Add support for starting Linux through OPTEE-OS on ARMv7a

2025-11-06T17:26:18Z

Add support for jumping to Linux kernel through OPTEE-OS on ARMv7a. This is only supported if U-Boot runs in PL1 secure. This change adds two components, one is fitImage OPTEE-OS loadable handler, which makes a note of OPTEE-OS being loaded and stores the load address for later jump to it. The second part is the actual jump to Linux through OPTEE-OS. The jump through OPTEE-OS requires set up of multiple CPU registers, r1 and r2 are passed through, r0 and r3 have to be set to 0, lr is set to Linux kernel entry point. This setup is done by new assembler function boot_jump_linux_via_optee(). The boot_jump_linux_via_optee() also includes STM32MP13xx late TZC configuration write, this cannot be moved easily, hence the ifdef. Signed-off-by: Marek Vasut