u-boot.git/doc/usage, 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 tag 'net-20260813' of https://git.u-boot-project.org/u-boot/custodians/u-boot-net

2026-08-13T14:58:29Z

Pull request net-20260813. net: - phy: dp83867: enable extended read / write for driver - phy: fix duplicate eth_phy binding - Drop unnecessary device_set_name - dwc_eth_xgmac: Return -ENODEV when phy_connect() fails - nfs: clean up bounds checks in nfs_readlink_reply() - rtl8169: add support for RTL8126A and RTL8127A - srand_mac(): fix -ENODEV crash with CONFIG_DM_RNG net-legacy: - Fix out-of-bounds write in IP fragment reassembly - test: net: add regression test for IP reassembly overflow net-lwip: - Add tftpsrv command - Handle chained pbufs in transmit path - sntp: fix netif leak when ntpserverip is unset - wget: free mbedtls x509 cert context to avoid memory leak - Fix DHCP fine timer interval

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: cmd: gpt: Reinstate gpt setenv

2026-07-31T09:05:31Z

Commit dc3765ede5a4 ("doc: Switch from setenv to env set") was too eager to switch "setenv" to "env set" and also incorrectly rewrote "gpt setenv" to "gpt env set". Undo this error. Fixes: dc3765ede5a4 ("doc: Switch from setenv to env set") Signed-off-by: Marek Vasut Reviewed-by: Simon Glass

efi: Print ISA-specific and unknown memory attributes

2026-07-31T07:22:40Z

The attribute mnemonic table did not cover EFI_MEMORY_ISA_VALID and the EFI_MEMORY_ISA_MASK field, and attribute bits without a mnemonic were silently dropped, so a memory map carrying ISA-specific, invalid or not yet known attributes displayed incomplete information without any hint that something was missing. Add a mnemonic for EFI_MEMORY_ISA_VALID and print the ISA-specific field as ISA= when it is valid, instead of decoding bits whose meaning U-Boot cannot know. Any remaining bits that match neither the mnemonic table nor the ISA field are printed as a hexadecimal value. Suggested-by: Heinrich Schuchardt Signed-off-by: Aristo Chen

efi: Unify the memory map output of 'efi mem' and 'efidebug memmap'

2026-07-31T07:21:02Z

The efi and efidebug commands each carried their own code for printing the EFI memory map, with separate tables of memory type and attribute names. The copies had drifted: efidebug knew EFI_PERSISTENT_MEMORY_TYPE while 'efi mem' printed it as '', neither table knew EFI_UNACCEPTED_MEMORY_TYPE, and the 'efi mem' printer had misaligned column headers, a broken '' line and a superfluous Virtual column: the map is identity mapped before SetVirtualAddressMap() is called, so the field carries no information at the time the command can run. Move the printing loop of 'efidebug memmap' into efi_common.c as efi_show_memmap(), which is linked into both commands, and use it from both. The second copy in 'efi mem' is deleted together with efi_print_mem_table() and the private sorting and merging code, including the 'all' argument. The memory type names follow the UEFI specification with the leading 'Efi' and the trailing 'Type' stripped, for example ConventionalMemory for EfiConventionalMemory, and the missing name for unaccepted memory is added. The type column is widened to fit the longest name, MemoryMappedIOPortSpace. The shared function iterates the map with the descriptor size reported by the firmware instead of assuming sizeof(struct efi_mem_desc). This matters for 'efi mem' under EDK II based firmware, which reports a descriptor size of 0x30. The memory map key, which was printed uninitialized on the payload path, is now initialized. The command documentation is updated with output captured from the app running under OVMF, and documents why virtual addresses are not shown. Suggested-by: Heinrich Schuchardt Signed-off-by: Aristo Chen

Merge tag 'efi-2026-01-rc2' of https://git.u-boot-project.org/u-boot/custodians/u-boot-efi

2026-07-28T13:52:13Z

Pull request efi-2026-01-rc2 CI: https://git.u-boot-project.org/u-boot/custodians/u-boot-efi/-/pipelines/753 Documentation: * sandbox: fix enum host_platform_flags description * switch from setenv to env set and from printenv to env print * document Renesas R-Car Gen5 RSIP Cortex-R52 start * thead: lpi4a: detail how to enable fastboot UEFI: * unify and correct GUID selection for security database variables * test: check default GUID selection of security database variables * set correct frame buffer address * check efi_deserialize_load_option() in get_dp_device()

Merge patch series "fs: regression-safe load for null_dev_desc_ok fstypes"

2026-07-27T16:52:25Z

Vincent Jardin says: 3 commits providing documentation of impacts and testing the dispatch for null_dev_desc_ok fstypes (semihosting, ubifs, sandbox) in the generic `load ...` command. The test does not cover ubifs, I could not make it work with qemu. Since the code logic is there and testing with semihost is done, it should cover the needed cases. Link: https://lore.kernel.org/r/20260715165735.3207801-1-vjardin@free.fr

doc: Switch from printenv to env print

2026-07-27T16:50:28Z

The "env" command is the recommended environment management command, its "print" subcommand is the equivalent replacement for legacy "printenv" command. Update the documentation to use the contemporary "env print" command instead of legacy "printenv" command. Note that the "printenv" 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 print@g' $(git grep -li '\' doc/) README Signed-off-by: Marek Vasut