u-boot.git/test/boot, 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

test: vbe: cover vbe_read_fit() external-data bounds checks

2026-07-16T18:06:15Z

vbe_read_fit() rejects FITs whose external-data window extends past the trusted firmware area on disk by returning -E2BIG. Add two sandbox unit tests that construct synthetic FITs with attacker-controlled data-position and data-size values, write them to mmc1, and assert vbe_read_fit() catches each one before issuing the follow-up blk_read(). vbe_read_fit_oob_position uses a data-position past area_size, which trips the load_addr - addr > area_size clause. vbe_read_fit_oversize_data keeps data-position inside the area but picks a data-size that overruns area_size - (load_addr - addr), tripping the third clause. The two remaining bound clauses stay unreachable from a sandbox test. The load_addr < addr guard trivially holds when addr comes from CONFIG_VAL(TEXT_BASE), which is 0 on sandbox, and the FDT-region bound sits behind a !CONFIG_SANDBOX guard in vbe_read_fit(), so fdt_size stays 0 and that block is skipped in this test environment. The new file follows the existing bootstd VBE test layout and writes the FIT at block 16, past the version and nvdata blocks already used by bootstd_setup_for_tests(). Suggested-by: Simon Glass Reviewed-by: Simon Glass Signed-off-by: Aristo Chen

test: bootdev: scan with a broken high-priority device

2026-07-03T16:14:25Z

Add bootdev_hunt_fallthrough() test to verify that 'bootflow scan -l' falls back to a lower-priority bootdev when a higher-priority hunter fails. Introduce a simple 'sandbox-bootdev' device for the test. The new bootdev can be configured to produce an error at the hunting stage. Introduce new host_set_flags_by_label() API and a flags field to 'host_sb_plat' to simulate a bootdev hunter failure for the test. Adjust boot{dev,flow} tests which depend on bootdev hunters. Signed-off-by: Denis Mukhin Reviewed-by: Simon Glass

Merge patch series "various memory related fixups"

2026-06-15T17:04:48Z

rs@ti.com says: From: Randolph Sapp Nitpicks and fixes from the discovery thread on adding PocketBeagle2 support [1]. This does a lot of general setup required for the device, but these modifications themselves aren't device specific. For those specifically interested in PocketBeagle2 support and don't care about these details, my development branch is public [2]. That first patch may provoke some opinions, but honestly if that warning was still present I wouldn't have spent a week poking holes in both the EFI and LMB allocations systems. Please let me know if there is a specific usecase that it breaks though. [1] https://lore.kernel.org/all/DHHC66BBMD27.YHGIH43C6XBK@ti.com/ [2] https://github.com/StaticRocket/u-boot/tree/feature/pocketbeagle2 Link: https://lore.kernel.org/r/20260604155038.3182-1-rs@ti.com

test: boot: add a fdt reserved region check

2026-06-15T17:04:39Z

Add a image_fdt suite and a check for boot_fdt_add_mem_rsv_regions. This will ensure the user is properly informed of any reservation failures. It will also validate that reservations are cleaned up correctly when switching FDTs. Signed-off-by: Randolph Sapp Reviewed-by: Simon Glass Acked-by: Ilias Apalodimas

test: boot: add runtime unit test for fit_verity_build_cmdline()

2026-05-27T19:41:33Z

Add test/boot/fit_verity.c with four tests that construct FIT blobs in memory and exercise fit_verity_build_cmdline(). Signed-off-by: Daniel Golle Reviewed-by: Simon Glass

test: boot: Add test for bootmeth_rauc

2026-03-06T18:09:17Z

Add a simple unit test for testing the RAUC bootmethod. Provide only the very basic tests for now, running a scan and list, to verify correct detection of the RAUC bootmethod. More advanced boot tests of this bootmethod can be added in a separate patch. This requires another mmc image (mmc10) to contain the following partitions: 1. boot A: contains a dummy boot.scr 2. root A: contains an empty root filesystem 3. boot B: contains a dummy boot.scr 4. root B: contains an empty root filesystem The bootmeth_rauc scans all four partitions for existence and expects a boot script in each boot partition. Also add BOOTMETH_RAUC as a dependency on sandbox so that we can test this with: $ ./test/py/test.py -B sandbox --build -k test_ut # build the mmc10.img $ ./test/py/test.py -B sandbox --build -k bootflow_rauc Signed-off-by: Martin Schwan Reviewed-by: Simon Glass [trini: mmc9 is now in use, switch to mmc10] Signed-off-by: Tom Rini

Merge patch series "Convert extension support to UCLASS and adds its support to boot flows"

2025-11-03T16:12:05Z

Kory Maincent (TI.com) says: This series converts the extension board framework to use UCLASS as requested by Simon Glass, then adds extension support to pxe_utils and bootmeth_efi (not tested) to enable extension boards devicetree load in the standard boot process. I can't test the imx8 extension scan enabled by the imx8mm-cl-iot-gate_defconfig as I don't have this board. I also can't test the efi bootmeth change as I don't have such board. Link: https://lore.kernel.org/r/20251030-feature_sysboot_extension_board-v5-0-cfb77672fc68@bootlin.com

boot: Remove legacy extension board support

2025-11-03T16:02:39Z

Remove the legacy extension board implementation now that all boards have been converted to use the new UCLASS-based framework. This eliminates lines of legacy code while preserving functionality through the modern driver model approach. Update the bootstd tests, due to the removal of extension hunter. Signed-off-by: Kory Maincent (TI.com)

boot: Run the EFI bootmgr just before network devices

2025-10-22T20:16:56Z

At present the EFI bootmgr scans all devices in the system before deciding which one to boot. Ideally it would use the bootstd iterator for this, but in the meantime, give it a lower priority, so it runs just before the network devices. Note that if there are no hunted network devices hunted, then it will run at the end, after all bootdevs are exhausted. In other words, it will always run. Signed-off-by: Simon Glass