| Age | Commit message (Collapse) | Author |
|---|
|
https://git.u-boot-project.org/u-boot/custodians/u-boot-rockchip into next
- Fixed possible SPI hangs when only PICO is routed (TX-only),
- Added support for ROC-RK3399-PC-PLUS (via roc-pc-rk3399_defconfig)
|
|
Add tests for nand commands to test various NAND flash operations such
as erase, write and read. Use the current test/py APIs (ubman fixture
and utils helpers) and refactor the pre-command helper to return a
dictionary.
Also add the test_nand.py test to the generated documentation. See
commit 8f8f0f0ed9d0 ("doc: pytest: Document the test_net_boot test")
for the kinds of changes required for the docstring to be rendered
correctly.
Signed-off-by: Love Kumar <[email protected]>
|
|
Shahriyar Jalayeri <[email protected]> says:
This fixes an out-of-bounds write in the RLE8 BMP decoder and adds a
regression test.
video_display_rle8_bitmap() lets the framebuffer cursor drift below the
start of the framebuffer via repeated End-Of-Line escapes, so a crafted
image displayed from the splash-screen or PXE-menu path (loaded from
removable media or over TFTP) writes before the framebuffer. Patch 1
bounds each run and rejects such an image with -EINVAL; patch 2 adds a DM
test for it.
Link: https://lore.kernel.org/r/[email protected]
|
|
Add a DM test that displays a crafted RLE8 bitmap whose decode cursor
is driven below the framebuffer. Without the preceding fix
video_bmp_display() writes out of bounds and returns success; with it
the image is rejected with -EINVAL.
Signed-off-by: Shahriyar Jalayeri <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
|
|
Make lmb_free() return -EFAULT when the requested memory region is not
allocated, instead of the generic -1 error value.
Document the updated error code in the public API comment and change the
LMB unit test to check for the new -EFAULT errno value.
Signed-off-by: Jonas Karlman <[email protected]>
Reviewed-by: Randolph Sapp <[email protected]>
|
|
lmb_alloc_addr() is documented to return -EINVAL when the requested
memory region is not part of the LMB memory map. However, -EINVAL is
also used to e.g. indicate that a NULL pointer is passed as the addr
parameter or when the requested memory region partially overlaps an
existing region.
Change lmb_alloc_addr() to return -EFAULT when the requested memory
region is not part of the LMB memory map to make the type of error known
to callers. Also extend unit tests to validate that the return code has
stay the same when the requested memory region partially overlaps.
No caller of lmb_alloc_addr() is checking what type of error code is
returned, so this change has no intended behavior change.
Signed-off-by: Jonas Karlman <[email protected]>
Reviewed-by: Randolph Sapp <[email protected]>
|
|
The spi-peripheral-props binding shipped in dts/upstream allows a bus
width of 0, meaning no RX or TX is possible on this device. The
switches in spi_slave_of_to_plat() only handle 1/2/4/8, so a width of
0 falls through to the default case and warns "spi-rx-bus-width 0 not
supported" on every boot, even though the devicetree is valid per the
binding. The fact that the wire is missing is then dropped from
plat->mode.
Map 0 to new SPI_NO_TX/SPI_NO_RX mode bits, as Linux has done since
v5.12 ("spi: Add SPI_NO_TX/RX support", mainline d962608ce218).
Bits 16 and 17 are the first free mode bits.
Mapping the bits is not enough on its own, as Quentin pointed out:
nothing would stop a caller from asking for a transfer in a direction
that has no wire, and every controller driver would need its own
guard. Validate centrally in dm_spi_xfer() instead, matching Linux's
__spi_validate(): a din on a SPI_NO_RX device or a dout on a SPI_NO_TX
device fails with -EINVAL before it reaches the driver. A new sandbox
test covers both rejections.
This comes up on devices with no MISO line at all, such as a
write-only SPI display described with spi-rx-bus-width = <0>.
Signed-off-by: Cole Munz <[email protected]>
Acked-by: Quentin Schulz <[email protected]>
Link: https://patch.msgid.link/ae6a85d6f985b63c8f5a3fe8deeab89d79757b14.1787309754.git.Munzzyy1@proton.me
Signed-off-by: Quentin Schulz <[email protected]>
|
|
There is no test for the bootd command. Add one to the cmd suite that
covers the documented behaviour: bootd and its "boot" alias run the
command held in the bootcmd environment variable, and the return value of
bootd is the one of that command. Also assert the recursion guard in
cmd_process(), which is part of the code bootd carries.
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Mehmet Fide <[email protected]>
|
|
bootflow_scan_first()/bootflow_scan_next() try each candidate
(bootdev, method, partition) in turn. When a candidate fails and is
not returned to the caller (no BOOTFLOWIF_ALL), the bootflow is simply
abandoned: the next candidate's bootflow_init() memsets the struct,
orphaning everything the failed attempt allocated, starting with the
name allocated in bootdev_find_in_blk().
Each failed candidate therefore leaks its allocations on every scan.
A single failing 'bootflow scan' on a sandbox MMC with a RAUC A/B
layout leaks about 1 KB across ~30 abandoned candidates, and scans can
be retried indefinitely from the U-Boot prompt.
Free the bootflow when it failed and is not passed back to the caller.
Add a check to the bootflow_rauc test that repeating a failing scan
does not change the number of allocated bytes. Together with the
previous RAUC fixes this makes the failed-scan path leak-free.
Fixes: a8f5be178db5 ("bootstd: Add support for bootflows")
Signed-off-by: Aristo Chen <[email protected]>
|
|
distro_rauc_read_bootflow() stores priv in bflow->bootmeth_priv before
calling distro_rauc_scan_parts(). If the scan fails, the error path
frees priv via distro_rauc_priv_free() but leaves bflow->bootmeth_priv
pointing at the freed memory.
With 'bootflow scan -a', failed bootflows are stored in the bootstd
list, so the stale pointer is kept. The next scan (or any other
bootflow removal) calls bootflow_free(), which frees bootmeth_priv
again. On sandbox, dlmalloc catches the double free:
common/dlmalloc.c:816: do_check_inuse_chunk: Assertion `inuse(p)' failed.
The scan can fail this way whenever no slot has a valid filesystem, or
when BOOT_ORDER names an unknown slot.
Clear bflow->bootmeth_priv after freeing, as bootmeth_android already
does. Extend the bootflow_rauc test to run a failing scan with -a and
then rescan.
Fixes: 284855320282 ("bootstd: rauc: Free memory during error handling")
Signed-off-by: Aristo Chen <[email protected]>
|
|
priv->slots is a NULL-terminated array of pointers, but get_slot()
tests priv->slots[i]->name in its loop condition, dereferencing each
entry before checking it against NULL. When slot_name does not match
any configured slot, the loop reaches the terminator and dereferences
a NULL pointer.
This is reachable from the BOOT_ORDER environment variable: an entry
naming a slot that is not listed in CONFIG_BOOTMETH_RAUC_PARTITIONS
crashes U-Boot in distro_rauc_scan_parts() or distro_rauc_boot().
Since BOOT_ORDER is typically stored in a disk-resident environment
written by the OS, a stray or corrupted value must not crash the
bootloader.
Test the array entry itself before using its name, as
distro_rauc_priv_free() already does. Both callers already handle a
NULL return.
Extend the bootflow_rauc test to scan with a BOOT_ORDER naming an
unconfigured slot. Without this fix the test crashes with SIGSEGV.
Fixes: 7e5c2c782fb9 ("bootstd: Add implementation for bootmeth rauc")
Signed-off-by: Aristo Chen <[email protected]>
|
|
hash_algo_digest_size() returns -EINVAL for an invalid algorithm. The
test success provider passes that result directly to memset(), where it
is converted to a large size_t.
Return the error before touching the output buffer, and exercise the
invalid-algorithm path in the provider-selection test. This addresses
Coverity CIDs 652907 and 652908.
Fixes: 94b349bd902d ("crypto: hash: use DM providers from hash command")
Signed-off-by: James Hilliard <[email protected]>
|
|
decompression"
Aristo Chen <[email protected]> says:
The dm_test_cmd_zip_gzwrite sandbox test occasionally fails in CI
with:
12582912/16777216
Error: inflate() returned -5
The chunked decompression loop added in commit 58e523fedf48 ("gunzip:
Implement chunked decompression") treats Z_BUF_ERROR from inflate()
as fatal. When an input chunk is exhausted at exactly the same time
as the write buffer fills up, the next inflate() call is made with
avail_in == 0, cannot make progress, and returns Z_BUF_ERROR. Per the
zlib documentation this only means "no progress was possible" and the
call should be repeated with more input, which is what the reference
implementation in zlib examples/zpipe.c does.
The failure needs the consumed/produced byte counts to line up with
both the chunk size and the write buffer size at once, with no
buffered output on the inflate side, which is why only certain random
payloads trigger it. Note that the failure offset above is a multiple
of the 1 MiB write buffer while gzwrite_chunk was SZ_1M + 1.
Patch 1 makes gzwrite() refill the input chunk in this situation.
Patch 2 adds a deterministic regression test which builds a gzip file
from two stored deflate blocks by hand and aligns the chunk boundary
with the write buffer boundary exactly, failing reliably without
patch 1.
Verified on sandbox and sandbox64:
- dm_test_cmd_gzwrite_chunk_boundary fails with -5 in 20 out of 20
runs before the fix, passes 100 out of 100 runs after
- dm_test_cmd_zip_gzwrite fails 17 out of 2000 runs (about 1%)
before the fix, every time with the same signature as the CI
flake, and passes 2000 out of 2000 runs after
- dm_test_cmd_zip_unzip keeps passing
Link: https://lore.kernel.org/r/[email protected]
|
|
Add a deterministic regression test for the gzwrite() case where a
decompression input chunk is exhausted at exactly the same time as
the write buffer fills up. Build a gzip file by hand from two 1 KiB
stored deflate blocks and pick a chunk size that covers exactly the
first block header plus its payload, so that with a 1 KiB write
buffer the first input chunk runs out precisely when the write buffer
is full.
Unlike the existing random data test, which only hits this corner
case for rare byte patterns (about 1 percent of runs on sandbox64),
this test fails 20 out of 20 runs without the preceding gunzip fix:
Error: inflate() returned -5
and passed 100 out of 100 runs with it.
Signed-off-by: Aristo Chen <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
gpio-delay had no sandbox coverage, which is how two bugs in it went
unnoticed: gpio_delay_xlate() never propagated the requested index
into the descriptor offset, so every consumer past the first silently
collided with the first consumer's already-claimed offset 0; and the
claimed/name tracking arrays were sized and bounds-checked against a
hardcoded 32 instead of the driver's actual GPIO count. Both are fixed
by a companion series that is a dependency of this patch: applied
without it, this test fails outright, since it directly exercises
both fixes.
Add a test requesting both consumers wired up by gpio-delay-test in
test.dts (gpio_a 9 and 18): a third consumer colliding with an
already-claimed offset must fail with -EBUSY, each consumer's write
must land on its own wrapped GPIO line, and a request past the
wrapped GPIO count must fail with -EINVAL rather than succeed against
a hardcoded bound of 32.
Gated on CONFIG_GPIO_DELAY, since not every sandbox variant that
builds test/dm/gpio.c enables it (sandbox_vpl, sandbox_spl,
sandbox_noinst, sandbox_flattree).
Signed-off-by: Pranav Sanwal <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
dm_test_gpio_requestf() requests a GPIO via gpio_requestf() but never
frees it, unlike every other test in this file. Free it before
returning.
Signed-off-by: Pranav Sanwal <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Aristo Chen <[email protected]>m says:
This series brings back the FIT load address overlap detection that
was applied to next in September 2025 and reverted a day later in
commit e482fdbbca93 ("Revert "Merge patch series "mkimage: Detect FIT
image load address overlaps and fix related test/DTS issues""").
The v2 revert had two causes. On TI AM62x family boards the tispl FIT
image references the mutually exclusive tifsstub variants at a single
shared load address, and v2 tried to satisfy the checker by moving the
variants 64 KiB apart. Neha had warned in the v1 review that this
address is fixed by the platform and that moving the images would
break tifsstub selection, and that feedback was regrettably still
unaddressed when the series was applied. Nishanth then hit exactly
this class of failure in the K3 upstream boot build with real firmware
binaries, where am62px_evm, a board v2 had not even touched, failed
the new check on tifsstub-hs and tifsstub-fs sharing 0x9ca00000.
Separately, E Shattow reported an overlap on the StarFive VisionFive
2, which we later narrowed down to OpenSBI fw_payload.bin having been
passed to the build instead of the documented fw_dynamic.bin. With
fw_dynamic.bin the board has no overlap, as confirmed on the list in
January 2026.
Since then the structural fix for the tifsstub case has landed. The
series merged as commit 4e7a9bb0885e ("Merge patch series "arm: k3:
replace tifsstub runtime filter with per-state FIT configurations"")
gives each K3 security state its own FIT configuration referencing
only the matching tifsstub variant, so a per configuration overlap
check sees no conflict while the variants keep their required common
load address. That series was written precisely to unblock this one.
The underlying semantics, that overlap is a property of a single
configuration and that images referenced by different configurations
never coexist in memory, were discussed with the FIT spec folks in
flat-image-tree issue #32 [1].
The check itself is unchanged in spirit: for every configuration,
collect the load regions of all referenced images that have both a
load address and data, and fail the build if any two regions within
that configuration intersect. Images referenced only by different
configurations may freely share addresses.
Verification done for this version:
Running the new mkimage in reprocess mode over every FIT produced by
current master builds of am62x_evm, verdin-am62 and phycore_am62x
(A53 and R5 each) flags exactly one problem: the phycore u-boot FIT,
where the four SPL devicetree overlays are loaded simultaneously from
one configuration but are spaced only 4 KiB apart while each packaged
image measures 5.9 to 6.1 KiB including its ti-secure certificate.
That is a real overlap shipping today and patch 4 widens the spacing.
All tispl FITs with the per-state tifsstub configurations pass.
buildman with binman missing blob handling, matching CI, builds all of
phycore_am62x, phycore_am62ax, phycore_am64x, am62x_evm, am62ax_evm,
am62px_evm, am64x_evm, verdin-am62, verdin-am62p and am62x_beagleplay
(A53 and R5 each) plus starfive_visionfive2 with the check active,
since binman invokes the freshly built mkimage during these builds.
starfive_visionfive2 was additionally built with a real OpenSBI 1.7
fw_dynamic.bin passed via OPENSBI and completes cleanly.
The binman functional test suite shows no new failures compared to
master in the same environment. The nine tests whose fixtures are
touched by patches 1 to 3, including the OpenSSL engine and PKCS11
signing tests that only run when softhsm2 and opensc are available,
all pass. The mkimage validation pytests, including the two new
ones, pass against a sandbox build.
[1] https://github.com/open-source-firmware/flat-image-tree/issues/32
Link: https://lore.kernel.org/r/[email protected]
|
|
Add a test that mkimage rejects a FIT image whose configuration
references a kernel and an FDT with the same load address, and that
the error message names the offending configuration and images.
Also add a companion test for the intended escape hatch: two images
may use the same load address as long as no single configuration
references both of them. Only one configuration is selected at
runtime, so such images never coexist in memory. This mirrors the TI
K3 tispl layout after commit c85bf61b14f9 ("arm: k3: select tifsstub
via board_fit_config_name_match"), where each security state has its
own configuration and all tifsstub variants share one load address.
Signed-off-by: Aristo Chen <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
With 'pattern_lab_mode' at index 1, every bad-pattern index is off by
one, so the wrong id is reported and a match on the final bad pattern
indexes past the end of 'bad_pattern_ids'.
Ensure out of bound access to 'bad_pattern_ids' is handled correctly
while processing test console output.
Also, uniform accesses to 'bad_pattern_ids' throughout the module.
Fixes: 8308a5eed6e6 ("test: Introduce lab mode")
Signed-off-by: Denis Mukhin <[email protected]>
|
|
https://git.u-boot-project.org/u-boot/custodians/u-boot-net
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
|
|
Anshul Dalal <[email protected]> says:
This patch series fixes the negation on modern hush shell and adds a
sandbox test for the same.
Link: https://lore.kernel.org/r/[email protected]
|
|
This unit test verifies negation in modern hush shell. To test on
sandbox, run the following commands with CONFIG_HUSH_MODERN_PARSER
enabled.
=> cli set modern
=> ut hush
Test: negation: modern.c
Signed-off-by: Anshul Dalal <[email protected]>
|
|
https://git.u-boot-project.org/u-boot/custodians/u-boot-snapdragon into next
* Support for building mbn files during the build with the new mkmbn
tool.
* Remove UCLASS_SMEM and the old smem driver (Qualcomm was the only
user of both), replace it with a port of the Linux SMEM driver.
* Refactor memory map parsing and support reading the memory layout from
the SMEM database.
* Set the serial# from SMEM.
* Introduce initial support for SPL in mach-snapdragon.
* Add a defconfig for sm8650 with U-Boot as the primary bootloader.
* Workaround an MMC issue by limiting the transfer size.
* Add support for SM7125/SC7180 (clock/pinctrl drivers and UFS phy).
* Add support for the QCS6490 powered Rubik Pi 3 board and document it.
|
|
In case MULTI_DTB_FIT_GZIP is enabled, fdtdec_setup() does uncompress
the compressed DTs in uncompress_blob() using gunzip(), which invokes
malloc() internally. The early simple malloc is initialized in board_f
initf_malloc() call, which sets up the early simple malloc limit and
offset pointer in global data. Currently, the initf_malloc() is called
after fdtdec_setup(), which leads to malloc failure in fdtdec_setup()
during the gzip decompression, because the early simple malloc is not
initialized yet.
Call initf_malloc() before fdtdec_setup() to assure fdtdec_setup() can
use malloc() during gzip decompression of the DTs.
The impact of this change on boot time is negligible, because the
initf_malloc() only assigns two fields in global data.
Signed-off-by: Marek Vasut <[email protected]>
Fixes: 95f4bbd581cf ("lib: fdt: Allow LZO and GZIP DT compression in U-Boot")
Reviewed-by: Simon Glass <[email protected]>
[trini: Update test/py/tests/test_trace.py]
Signed-off-by: Tom Rini <[email protected]>
|
|
Daniel Golle <[email protected]> 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/[email protected]
|
|
A dm-verity protected filesystem image is not hashed by U-Boot; its
integrity is delegated to the kernel, which trusts the roothash taken
from the FIT dm-verity subnode. For that chain of trust to hold, the
roothash (and salt) must be part of the region covered by the
configuration signature, otherwise an attacker can replace both the
filesystem and the roothash while keeping the signature valid.
Add two independent checks of this property:
- test/py/tests/test_fit_verity_sign.py signs a configuration that
references a filesystem image carrying a dm-verity subnode, then
confirms that tampering the roothash or the salt is rejected by
fit_check_sign. A control that tampers a byte known to be signed
proves the check can fail. A matching page is added under
doc/develop/pytest/ so the module documentation is rendered with
the rest of the generated docs.
- test/boot/fit_verity.c gains a runtime unit test that builds the
exact node list the configuration signature is computed over,
turns it into hashed regions and checks both that the roothash
bytes fall inside a signed region and that tampering them changes
the hash. It needs no private key, so it also runs on real devices
and uses the same hash path a device would.
To let the unit test build the signed-region node list, rename the
config node-list helper to fit_config_get_signed_nodes(), make it
non-static and declare it in image.h.
Signed-off-by: Daniel Golle <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
This reverts commit 20e7705764c4e5ea924f1ea54bb36ebbbeffffe7.
Reviewed-by: Sumit Garg <[email protected]>
Reviewed-by: Neil Armstrong <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Tested-by: Sumit Garg <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Casey Connolly <[email protected]>
|
|
Add a DM test that feeds __net_defragment() a single crafted fragment
whose trailing hole descriptor lands just past pkt_buff. Without the
preceding fix the 8-byte hole write goes out of bounds; with it the
fragment is dropped and no datagram is delivered.
Signed-off-by: Shahriyar Jalayeri <[email protected]>
Acked-by: Jerome Forissier <[email protected]>
|
|
The hash command currently always uses the software implementation for
the selected algorithm, even when driver-model hash providers are
available.
Add a hash_digest_wd_lookup() helper which probes UCLASS_HASH devices in
order and uses the first provider supporting the requested algorithm.
Continue past unavailable providers and unsupported operations, but
propagate a hard digest failure once a provider accepts the operation.
Remember probe failures so they are not silently hidden by software
fallback when no later provider succeeds.
Use the helper from the hash command and retain its software fallback
when no usable provider is present. Add sandbox tests covering provider
fallback and hard-error propagation.
Signed-off-by: James Hilliard <[email protected]>
|
|
https://git.u-boot-project.org/u-boot/custodians/u-boot-efi
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()
|
|
fstypes"
Vincent Jardin <[email protected]> says:
3 commits providing documentation of impacts and testing the dispatch
for null_dev_desc_ok fstypes (semihosting, ubifs, sandbox) in the
generic `load <iface> ...` 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/[email protected]
|
|
The name to GUID mapping that "env set -e" applies when no -guid
option is given was not covered by any test, which is how the wrong
default GUID for "dbr" went unnoticed until the previous commit.
Add a test case that enrolls each of db, dbx, dbt and dbr in setup
mode without an explicit -guid option and checks that every variable
is created under the image security database GUID and not under the
global variable GUID. Then enroll PK and KEK, also without -guid, and
check that both are created under the global variable GUID and not
under the image security database GUID. This is also the first
coverage of dbt and dbr anywhere under test/.
The signature database enrollment happens in setup mode because once
secure boot is enabled, efi_variable_authenticate() only accepts
writes to PK, KEK, db and dbx; PK and KEK are enrolled last because
installing PK leaves setup mode.
Signed-off-by: Aristo Chen <[email protected]>
|
|
Some pytest modules exercising the dispatch added by
fs: dispatch null_dev_desc_ok filesystems before lookup
test_load_semihosting.py:
"load semihosting - <addr> <file>" and the optional
[bytes] [pos] variant. Runs on qemu_arm64 with
CONFIG_SEMIHOSTING=y; reuses test_hostfs.py's host-staged
fixture.
test_load_sandbox.py:
"load sandbox - <addr> <file>" and the optional [bytes] [pos]
variant. Runs on sandbox (boardspec('sandbox')); the sandbox
fstype is registered with name="sandbox" and
null_dev_desc_ok=true,
so the same fs_lookup_null_dev_info() helper that
routes semihosting also routes the "sandbox".
A "load ubifs - <addr> <file>" test is intentionally not provided.
UBIFS is built on UBI on MTD, which requires some additional works
that are not available with qemu/sandbox-ing.
Signed-off-by: Vincent Jardin <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
Signed-off-by: Carlo Caione <[email protected]>
|
|
Aristo Chen <[email protected]> says:
fit_import_data() in tools/fit_image.c declares the data pointer and
the name of the external data property outside its loop over the
/images subnodes, so both values leak from one image into the next. An
image node that carries data-size but neither data-offset nor
data-position then reuses the pointer left behind by the previously
imported image: the previous image's data is written into the node,
after which the import aborts trying to delete an external data
property the node never had. Since that abort path only prints a
debug() message, a regular mkimage build fails with nothing but the
generic usage text. The failure mode also depends on the order of the
image nodes: when no externally stored image precedes the malformed
node, the pointer is still NULL, the node is skipped, and the hashing
stage reports a proper error instead.
A FIT authored from a .its cannot hit this, because dtc-authored
images carry inline data. It takes re-processing an external-data FIT
in which an image has lost its data-offset, for example one edited
with fdtput -d or produced by another tool:
mkimage -E -f demo.its demo.itb
fdtput -d demo.itb /images/kernel-2 data-offset
mkimage -F demo.itb
There is no silent-success path, because the failing property delete
always aborts the run before the file is written back, but the user is
left without any indication of what is wrong.
Patch 1 moves the declarations into the loop so that each image starts
from a clean state. A node without an external data reference is now
skipped consistently regardless of node order, and the later
processing stages report the malformed node with a proper error
message (Can't get image data/size).
Patch 2 adds a regression test that builds an external-data FIT,
deletes the data-offset property of the second image and re-processes
the result with mkimage -F. It asserts that mkimage fails and that the
diagnostic is present on stderr; the unfixed tool fails the second
assertion since it prints nothing beyond the usage text.
Link: https://lore.kernel.org/r/[email protected]
|
|
Build an external-data FIT, remove the data-offset property from the
second image so that only its data-size remains, and re-process the
result with mkimage -F. mkimage must reject the malformed FIT with a
clear diagnostic from the hashing stage. Previously the stale per-image
state in fit_import_data() made the import copy the first image's data
into the second image and abort without printing anything.
Signed-off-by: Aristo Chen <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
The legacy network stack supports tftpsrv, which listens for an
incoming TFTP write request and receives the first file into memory.
Despite the old command help wording, the command returns after
receiving the file and does not boot it automatically.
The lwIP stack already builds the lwIP TFTP application, but only wires
it up for client-side tftpboot. Add a lwIP tftpsrv command and
implement the server path with tftp_init_server(). Reuse the existing
lwIP TFTP write callback and memory copy path so LMB checks, progress
output, filesize/fileaddr updates and EFI bootdev handling stay
consistent with tftpboot.
Track receive timeout and write-failure state around the lwIP callbacks
so a stalled or rejected receive is not reported as a successful close.
Move CMD_TFTPSRV out of the legacy-only Kconfig block so it can be
enabled with either network stack. Update the command help text and add
usage documentation for the receive-only behavior.
Add pytest coverage for tftpsrv using a generated host file and curl's
TFTP upload support. Enable the command in qemu_arm64_lwip_defconfig so
the test can be run with the existing lwIP QEMU build when the boardenv
provides env__net_tftpsrv_file.
Signed-off-by: James Hilliard <[email protected]>
[Jerome Forissier: remove trailing ':' after SPDX tag]
Signed-off-by: Jerome Forissier <[email protected]>
Reviewed-by: Jerome Forissier <[email protected]>
|
|
Rasmus Villemoes <[email protected]> says:
This started by me wanting something like what patch 8 does. That
wasn't too hard, except we had no strcasestr(), and also our regex
engine (which I didn't really want to pull into the mix anyway)
doesn't have a flag that requests case-insensitive matching. So I
wanted to add strcasestr(), but then I stumbled on a bunch of stuff
that should be cleaned up in str-land.
Link: https://lore.kernel.org/r/[email protected]
|
|
Add some test cases for the 'config' command, including the ability to
filter the output.
Signed-off-by: Rasmus Villemoes <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Change the existing strstr() test a little so that the substring not
found is "bits", i.e. one that is actually found when doing case
insensitive search.
Then copy all of lib_strstr(), adapt the expectation for the
strcasestr(s1, s3) result, and add another "not found" case.
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Rasmus Villemoes <[email protected]>
|
|
Add a regression test that builds a FIT with external data, inflates
the data-size property far beyond the image and any plausible load
region, and confirms that spl_load_simple_fit() returns -EFBIG instead
of reading the declared size off the device. Without the bounds check
in load_simple_fit() this test overruns memory and crashes; with it the
load is rejected cleanly.
Signed-off-by: Aristo Chen <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
area"
Aristo Chen <[email protected]> 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/[email protected]
|
|
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 <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Aristo Chen <[email protected]>
|
|
https://git.u-boot-project.org/u-boot/custodians/u-boot-mmc
CI: https://git.u-boot-project.org/u-boot/custodians/u-boot-mmc/-/pipelines/614
- Add PMBUS regulator, thermal and test
- Add regulator helper to set voltage within an acceptable range
- Update dw_mmc to use in-spec voltage range for vqmmc
- Fix regulator_enable/disable() macros
- Clear LPUART OR STAT in tstc to avoid hang
- Add MAINTAINERS entry for SDHCI
|
|
Coverity reports an INTEGER_OVERFLOW issue because ut_asserteq() compares
an unsigned int (mmc_dev_num) with ret, which can hold a negative error
code.
Addresses-Coverity-ID: CID 646439: Integer handling issues (INTEGER_OVERFLOW)
Signed-off-by: Dario Binacchi <[email protected]>
Reviewed-by: Quentin Schulz <[email protected]>
|
|
Add dm unit tests that drive every pmbus subcommand handler against
the sandbox PMBus chip emulator:
dev (select by bus:addr and by regulator-name), list, info,
telemetry, status, dump, read, write, clear, vout, scan and help.
Tested using:
./u-boot -T -c "ut dm pmbus*"
Signed-off-by: Vincent Jardin <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
Add a sandbox LDO3 with a configurable 1.8V to 3.3V range and use it
to test regulator_set_value_clamp().
Test in-range requests, clamping against the regulator limits, invalid
ranges outside the regulator limits and a min value higher than max.
Signed-off-by: Jonas Karlman <[email protected]>
Reviewed-by: Peng Fan <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
|
