u-boot.git/arch, branch main

Merge patch series "vbe: bound FIT external-data reads against the firmware area"

2026-07-16T18:06:40Z

Aristo Chen says: vbe_read_fit() loads a firmware-phase FIT from a fixed firmware area on a block device and then issues a follow-up blk_read() to pull in the image, and optionally an FDT, referenced by the FIT's image node. The source offset on the device and the read length both come from the FIT itself, via data-position or data-offset and data-size. Those properties live on mutable boot media and can be controlled by an attacker with write access to the firmware area. On the TPL or VPL path, and on the bootmeth bootflow path reached via abrec_read_bootflow_fw() and vbe_simple_read_bootflow_fw(), the follow-up blk_read() runs before any signature or hash check on the loaded phase. Patch 1 is a sandbox test-tree preparation. The firmware1 node in arch/sandbox/dts/test.dts declared area-size = 0xe00000 (14 MiB), but the binman fw-update section in sandbox_vpl.dtsi is 32 MiB and the FIT inside it carries ~16 MiB of external data, so the FIT already extended past the declared area. The mismatch was tolerated because no caller bounded the external-data load against area_size. Patch 1 raises area-size to match the binman section size so test_vbe_vpl keeps passing once the bound is enforced. The patches are ordered so the test is never broken in the middle of the series. Patch 2 adds the missing range check, confining the FIT-supplied [load_addr, load_addr + len) window to [addr, addr + area_size] before block numbers and lengths are computed, and applying the same constraint to fdt_load_addr and fdt_size. The check is written in subtraction-only form against the trusted area_size so the comparison cannot itself overflow. Patch 3 adds two sandbox unit tests under test/boot/ that construct synthetic FITs with out-of-range data-position and oversized data-size, write them to mmc1, and confirm vbe_read_fit() returns -E2BIG for each before issuing the follow-up blk_read(). Deferring the external-data blk_read() until after the phase has been signature-verified would be a stronger structural fix and was discussed on the v1 thread. Simon confirmed the bounded read is the right first step and that the verify-then-load change should be a separate series, so this v3 stays scoped to the bound. Link: https://lore.kernel.org/r/20260705034414.2247-1-aristo.chen@canonical.com

sandbox: vbe: size firmware1 area to fit the binman fw-update section

2026-07-16T18:06:14Z

The firmware1 node in test.dts declares area-size = 0xe00000 (14 MiB) but the binman fw-update section in sandbox_vpl.dtsi is 0x2000000 (32 MiB) and the FIT inside it carries ~16 MiB of external data (spl + u-boot subimages). The FIT therefore extends past the declared firmware area, contradicting the documented contract of vbe_read_fit() that the FIT must fit within @area_size. The mismatch was tolerated because no caller actually bounded the external-data load against area_size. Bring the devicetree in line with the binman section size so the FIT extent stays within the trusted firmware area, in preparation for vbe_read_fit() enforcing that bound. state-offset and version-offset are left as-is; they were already inside the FIT data region and are not exercised by test_vbe_vpl. Reviewed-by: Simon Glass Signed-off-by: Aristo Chen

Merge patch series "Add DM firmware reserved memory support"

2026-07-16T18:05:25Z

Paresh Bhagat says: This series adds support for DM firmware reserved memory fixup in device tree for K3 SoCs that use separate DM firmware (K3_DM_FW enabled). The series includes: 1. Fix for phandle corruption in FDT reserved memory fixup 2. Enable OF_SYSTEM_SETUP for AM62D2 to allow device tree fixups 3. Add Kconfig options for DM firmware reserved memory for other K3 SoCs 4. Add DM reserved memory fixup implementation The main issue being addressed is that the current reserved DDR carveout for DM firmware in device tree is insufficient to accommodate the DM firmware binary on AM62A7, and potentially other K3 SoCs in the future. Currently, the size is only modified for AM62A7 SoC. For rest of SocS existing values from device tree is taken. For vendor boards, please verify boot and check for errors if any. This series depends on dts update for effected devices. If "dm" node is not found then the existing mechanism creates a new node with same address, which cause memory overlap issue. Link: https://lore.kernel.org/r/20260701075021.3626094-1-p-bhagat@ti.com

arm: mach-k3: Add DM reserved memory fixup

2026-07-16T18:04:48Z

Add support for fixing up DM firmware reserved memory in the kernel device tree for K3 SoCs that use separate DM firmware. The fixup uses the CONFIG_K3_DM_FW_RESERVED_ADDR and CONFIG_K3_DM_FW_RESERVED_SIZE Kconfig options to update the reserved-memory node with the correct DM firmware carveout. Note that the fixup needs DM reserved memory node is to be renamed in dts. Example memory@9c900000 → dm@9c900000 Signed-off-by: Paresh Bhagat Reviewed-by: Neha Malcom Francis

arm: mack-k3: Kconfig: Add DM firmware reserved memory configs

2026-07-16T18:04:48Z

Add Kconfig options for DM firmware reserved memory for K3 SOCs that support DM firmware (K3_DM_FW enabled) - K3_DM_FW_RESERVED_ADDR: DM firmware address - K3_DM_FW_RESERVED_SIZE: DM firmware reserved size These configs will be used to fixup the kernel device tree's reserved memory node for DM. Currently the fixup is only done for AM62A7 SoC, as K3_DM_FW_RESERVED_SIZE is being used to update DM reserved memory from 0xf0000 to 0x1f0000 as the current reserved carveout is insufficient to accommodate the binary. For other platforms, the addresses and sizes are based on the existing device tree reserved memory. If needed for other SoCs, address and size could be modified in Kconfig. Signed-off-by: Paresh Bhagat

arm: mach-k3: am62ax: Enable OF_SYSTEM_SETUP for AM62D2

2026-07-16T18:04:48Z

Enable OF_SYSTEM_SETUP for AM62D2 to ensure FDT fixups are applied to the dtb before passing to kernel. Signed-off-by: Paresh Bhagat Reviewed-by: Anshul Dalal

arm: mach-k3: Fix phandle corruption in fdt fixup

2026-07-16T18:04:48Z

Fix phandle corruption in fdt_fixup_reserved_memory() The original implementation used a delete/recreate approach: - Find existing reserved memory node (e.g. tfa@80000000) - Delete the entire node with fdt_del_node() - Create new node with fdtdec_add_reserved_memory() This worked fine for ATF and OPTEE nodes because no other device tree nodes reference them via phandles but other nodes example DM are referenced by R5 nodes. If these nodes are deleted and recreated, it will not have any phandle property but the nodes referencing it will still contain the old phandle, causing initialization to fail. Update nodes in-place instead of delete/recreate to update only the "reg" property using fdt_setprop(). Fixes: 8b0fc29de0e3 ("arm: mach-k3: am62: Fixup TF-A/OP-TEE reserved-memory node in FDT") Signed-off-by: Paresh Bhagat Reviewed-by: Neha Malcom Francis Acked-by: Andrew Davis

arm: k3: drop redundant tifsstub runtime filter

2026-07-16T18:03:40Z

With all AM62x family boards (TI EVMs, phytec phycore, toradex verdin) now using per-security-state FIT configurations and selecting the right one via board_fit_config_name_match(), the runtime filter in board_fit_image_post_process() that zero'd out *p_size for the wrong tifsstub variant is no longer reached. Only one tifsstub variant is present in the selected FIT configuration, and it is always the correct one for the current silicon. Drop the filter so board_fit_image_post_process() simply debug-logs the variant name and returns. Acked-by: Neha Malcom Francis Reviewed-by: Anshul Dalal Signed-off-by: Aristo Chen

board: toradex: verdin-am62: select tifsstub via FIT config

2026-07-16T18:03:40Z

Use the k3_fit_config_match_security_state() helper introduced in the earlier "arm: k3: select tifsstub via board_fit_config_name_match" patch to pick the right tifsstub variant on Verdin AM62 and AM62P SoMs at FIT config selection time. The k3-am625-verdin-wifi-dev-binman.dtsi and k3-am62p5-verdin-wifi-dev-binman.dtsi FIT images are split into per-security-state configurations (conf-hs-se, conf-hs-fs), and board_fit_config_name_match() in each verdin board file forwards to the shared K3 helper. The previous implementation returned 0 unconditionally which matched the first listed configuration regardless of the actual silicon, which after the dtsi split would load the wrong tifsstub variant on HS-SE parts. Signed-off-by: Aristo Chen

board: phytec: phycore-am62: select tifsstub via FIT config

2026-07-16T18:03:40Z

Use the k3_fit_config_match_security_state() helper introduced in the earlier "arm: k3: select tifsstub via board_fit_config_name_match" patch to pick the right tifsstub variant on phycore AM62x and AM62Ax SoMs at FIT config selection time. The k3-am625-phycore-som-binman.dtsi and k3-am62a-phycore-som-binman.dtsi FIT images are split into per-security-state configurations (conf-hs-se, conf-hs-fs), and board_fit_config_name_match() in each phycore board file forwards to the shared K3 helper. Signed-off-by: Aristo Chen