If noffset is negative, do not pass it to fit_get_name() and then further to
libfdt, this will crash sandbox with SIGSEGV because libfdt can not handle
negative node offsets without full tree check, which U-Boot inhibits to keep
size lower.
Instead, always check noffset before use, and if the return value indicates
failure, exit right away.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Acked-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
With the changes in commit 8fbcc0e0e839 ("boot: Assure FDT is always at
8-byte aligned address") to call memalign(...) we now always call
memalign(...) rather than malloc(...) when allocating a buffer that may
contain a device tree. However, memalign(...) is not portable among all
of the host OSes we support. The C11 standard does require that
aligned_alloc(...) exist and it takes the same parameters as
memalign(...) does. Change this file to call aligned_alloc rather than
memalign, and for the non-USE_HOSTCC case define that function back to
memalign.
Fixes: 8fbcc0e0e839 ("boot: Assure FDT is always at 8-byte aligned address")
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Tom Rini <trini@konsulko.com>
Heiko Schocher <hs@nabladev.com> says:
Add SM3 secure hash, as specified by OSCCA GM/T 0004-2012 SM3 and described
at https://datatracker.ietf.org/doc/html/draft-sca-cfrg-sm3-02
TPMv2 defines hash algo sm3_256, which is currently
not supported and prevented TPMv2 chip with newer
firmware to work with U-Boot. Seen this on a ST33TPHF2XI2C
u-boot=> tpm2 init
u-boot=> tpm2 autostart
tpm2_get_pcr_info: too many pcrs: 5
Error: -90
u-boot=>
Implement sm3 hash, so we can fix this problem.
Link: https://lore.kernel.org/r/20251118043042.27726-1-hs@nabladev.com
The fitImage may contain FDT at 4-byte aligned address, because alignment
of DT tags is 4 bytes. However, libfdt and also Linux expects DT to be at
8-byte aligned address. Make sure that the DTs embedded in fitImages are
always used from 8-byte aligned addresses. In case the DT is decompressed,
make sure the target buffer is 8-byte aligned. In case the DT is only
loaded, make sure the target buffer is 8-byte aligned too.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Fix two memory allocation bugs in label_boot_extension():
1. When label->fdtdir is not set, overlay_dir was used without any
memory allocation.
2. When label->fdtdir is set, the allocation size was incorrect,
using 'len' (just the fdtdir length) instead of 'dir_len' (which
includes the trailing slash and null terminator).
Resolve both issues by moving the memory allocation and string
formatting outside the conditional block, resulting in clearer code
flow and correct sizing in all cases.
Closes: https://lists.denx.de/pipermail/u-boot/2025-November/602892.html
Addresses-Coverity-ID: 638558 Memory - illegal accesses (UNINIT)
Fixes: 935109cd9e97 ("boot: pxe_utils: Add extension board devicetree overlay support")
Signed-off-by: Kory Maincent (TI.com) <kory.maincent@bootlin.com>
Tested-by: Surkov Kirill <fanra3.tk@gmail.com>
Size of array buf was incorrect due to sizeof returning the
size of an integer (typically 32 bits) instead of a u64 type
(64 bits). Hence, buf array was shorter than expected.
Signed-off-by: Francois Berder <fberder@outlook.fr>
Reviewed-by: Simon Glass <sjg@chromium.org>
Quentin Schulz <foss+uboot@0leil.net> says:
While historically signature verification is mostly done for FIT such
FIT_SIGNATURE dependency for signature algorithm makes sense, it isn't
the only kind of file we can verify signatures of. It can also be done
manually with rsa_verify_hash() with an embedded public key.
Considering the impacted code is guarded by RSA_VERIFY, let's make the
symbol depend on that otherwise selecting it without RSA_VERIFY won't do
anything. The FIT_SIGNATURE dependency wasn't also enough before as it
only implied RSA_VERIFY.
Then, simply relocate the RSA SSA PSS padding with the other RSA symbols
in lib/rsa instead of in boot/ and rename it to remove the mention to
FIT.
Finally, add the PSS padding wherever PKCS1.5 padding is specified as
one or the other can be used.
Link: https://lore.kernel.org/r/20251031-rsa-pss-always-v2-0-a29184ea064d@cherry.de
This renames FIT_RSASSA_PSS symbols to drop the FIT_ prefix to avoid
potential confusion since there's nothing FIT specific to those symbols.
It also isn't really related to booting, so boot/Kconfig is an odd place
for them to live. Since they make sense only in relation with RSA,
simply move them to lib/rsa where it makes more sense for them to
reside.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
It's defined a bit later in the same file, so let's remove the
duplicated entry.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
This padding has nothing to do with FIT except that we can make use of
it when verifying the FIT signatures.
This padding can also be used to verify the signature "manually" e.g. by
calling rsa_verify_hash() directly with an embedded public key.
Additionally, this padding is only useful if RSA (and specifically
RSA_VERIFY) is enabled otherwise it's not used.
The only other place it's used is in rsa-sign.c which is only built for
the host tools and handled by TOOLS_FIT_RSASSA_PSS symbol instead, so no
need to care for that one.
Finally, the FIT_SIGNATURE dependency also wasn't enough because it only
implies RSA_VERIFY, meaning it can be disabled and still have
FIT_RSASSA_PSS enabled.
So add a dependency on RSA_VERIFY and reword the input prompt.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
SPL_FIT_FULL_CHECK currently shares its description and help text with
FIT_FULL_CHECK which is quite confusing, so let's specify this applies
to SPL.
Fixes: 6f3c2d8aa5e6 ("image: Add an option to do a full check of the FIT")
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
When previously using script based bootflows, the U-Boot
environment variable bootargs was used to customize the kernel
commandline at boot time.
In order to get the same behaviour, concatenate the bootflow
commandline with the contents the bootargs environment variable.
Signed-off-by: Nicolas Belin (TI.com) <nbelin@baylibre.com>
Signed-off-by: Guillaume La Roque (TI.com) <glaroque@baylibre.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Link: https://lore.kernel.org/r/20251024-botargsappend-v1-1-0b78f05f9132@baylibre.com
Signed-off-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Anshul Dalal <anshuld@ti.com> says:
Hi all,
We currently make use of CMD_BOOTI and CMD_BOOTZ in the SPL boot flow in
falcon mode, this isn't correct since all CMD_* configs are only meant
for U-Boot proper and not the SPL.
Therefore this patch set adds new LIB_BOOT[IMZ] configs that allow for
more granular selection of their respective compilation targets.
Additionally, this also allows us to more easily disable support for
raw images from secure falcon mode (SPL_OS_BOOT_SECURE) by doing the
following:
config LIB_SPL_BOOTI
...
depends on SPL_OS_BOOT && !SPL_OS_BOOT_SECURE
...
Link: https://lore.kernel.org/r/20251027-fix_cmd_bootx-v10-0-10487e907710@ti.com
Using CMD_* configs from spl doesn't make logical sense. Therefore
this patch replaces the checks for CMD_BOOTx with newly added library
symbols LIB_BOOT[IMZ] and SPL_LIB_BOOT[IMZ] which are enabled by their
respective CMD_* or SPL_* counterparts.
On platforms with non-secure falcon mode, SPL_BOOTZ is enabled by
default for 32-bit ARM systems and SPL_BOOTI is enabled by default for
64-bit ARM and RISCV.
The respective C files (image.c/zimage.c) are compiled based on library
symbols $(PHASE_)LIB_BOOTx instead which are in turn selected by both
CMD_BOOTx and SPL_BOOTx as required.
Signed-off-by: Anshul Dalal <anshuld@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Kory Maincent (TI.com) <kory.maincent@bootlin.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
Add support for scanning and applying extension board devicetree
overlays during EFI boot. After loading the main board devicetree,
the system now scans for available extension boards and applies their
overlays automatically.
Signed-off-by: Kory Maincent (TI.com) <kory.maincent@bootlin.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Simplify the return path in distro_efi_try_bootflow_files() to prepare
for adding extension board support in a subsequent commit.
Signed-off-by: Kory Maincent (TI.com) <kory.maincent@bootlin.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add support for scanning and applying extension board devicetree
overlays during PXE boot. After loading the main board devicetree,
the system now scans for available extension boards and applies their
overlays automatically.
This enables dynamic hardware configuration for systems with extension
boards during boot scenarios which are using pxe_utils.
Signed-off-by: Kory Maincent (TI.com) <kory.maincent@bootlin.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The extension_overlay_cmd environment variable approach is specific to
the U-Boot extension_board command, while other boot flows (pxe_utils,
bootstd) handle overlay loading differently.
Move the extension_overlay_cmd execution out of the core extension
framework to the command level. This decouples the framework from
command-specific behavior and prepares for future extension support
in other boot flows.
Signed-off-by: Kory Maincent (TI.com) <kory.maincent@bootlin.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
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) <kory.maincent@bootlin.com>
Introduce UCLASS-based extension board support to enable more
standardized and automatic loading of extension board device tree
overlays in preparation for integration with bootstd and pxe_utils.
Several #if CONFIG_IS_ENABLED are used in cmd/extension_board.c to ease the
development but don't worry they are removed later in the series.
Signed-off-by: Kory Maincent (TI.com) <kory.maincent@bootlin.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Relocate extension board support from cmd/ to boot/ directory in
preparation for converting the extension framework to use UCLASS.
Also improve code style by applying reverse xmas tree ordering.
Signed-off-by: Kory Maincent (TI.com) <kory.maincent@bootlin.com>
Add the option to load the bootscript with the tftp command (static IP)
instead of the dhcp command (dynamic IP). For this a new function
tftpb_run similar to dhcp_run, is needed. The selection of which command
to use can be done with the ip_dyn environment variable, which can be
set to yes or no. The ip_dyn variable was chosen as it is already in use
on the imx platforms.
Also edit the bootstd doc.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Benjamin Hahn <B.Hahn@phytec.de>
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 <sjg@chromium.org>
When there are no more bootdevs we should still go through the global
bootmeths, since some may not have yet been used, if their priority has
not yet come up.
Add a final check for this at the end of the iterator.
Update the documentation to match the new behaviour of global bootmeths.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present before scanning global bootmeths, the iterator sets the
method count to the index of the first global bootmeth. Now that we
support scanning the global bootmeths multiple times, we must leave this
count alone.
Check against have_global and first_glob_method instead.
Signed-off-by: Simon Glass <sjg@chromium.org>
Allow bootmeths to select when they want to run, using the bootdev
priority. Provide a new bootmeth_glob_allowed() function which checks if
a bootmeth is ready to use.
Fix a comment in bootflow_system() which is a test for global bootmeths.
Signed-off-by: Simon Glass <sjg@chromium.org>
Use the methods_done flags to make sure that each global bootmeth is
only used once. For now this has no effect, since they are all processed
at the start.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add the logic to scan through the global bootmeths for every new
bootdev, in preparation for allowing global bootmeths to select where in
the hunter ordering they go.
Use a new bootmeth_glob_allowed() function to check if a bootmeth is
allowed, ensuring that each can run at most once.
For now this has no actual effect, since the global bootmeths are
unconditionally processed at the start, with iter->methods_done being
updated to include all of them. Therefore when scanning again, no
unprocessed global bootmeths will be found.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a bitfield which tracks when bootmeths have been used. This will be
needed when global bootmeths can be used later in the iteration.
Fix a missing bootflow_free() while here.
Signed-off-by: Simon Glass <sjg@chromium.org>
The current 'doing_global' refers to being in the state of processing
global bootmeths. Since global bootmeths are currently used once at the
start, it becomes false once the last global bootmeth has been used.
In preparation for allowing bootmeths to run at other points in the
bootstd interation, add a new 'have_global' flag which tracks whether
there are any global bootmeths in the method_order[] list. It is set up
when iteration starts. Unlike doing_global which resets back to false
after the global bootmeths have been handled, once have_global is set to
true, it remains true for the entire iteration process. This provides a
quick check as to whether global-bootmeth processing is needed.
Signed-off-by: Simon Glass <sjg@chromium.org>
For now we only support dropping non-global bootmeths from the
iteration. Update first_glob_method in that case and add a few checks
that things are correct.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present, normally when one bootmeth fails on a partition, we move on
and try the next bootmeth. However, this was not the case for the final
partition due to a bug. Rework the logic so that all partitions are
treated the same.
Signed-off-by: Simon Glass <sjg@chromium.org>
We will want to use this same logic in another place within iter_inc(),
so split it out into its own function.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Add a few comments about global bootmeths and first_glob_method
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>
Today, only a few platforms enable SPL_LOAD_FIT_FULL, and all enable
SPL_LOAD_FIT. As can be seen in usage, the FULL symbol is a superset of
the first symbol, not an alternative. Update Kconfig entries based on
this and simplify the only code which checks for either being set.
Signed-off-by: Tom Rini <trini@konsulko.com>
If there is no more active slot found in find_active_slot(), like when
all slots in BOOT_ORDER have a count of 0, the counters are reset to their
default value CONFIG_BOOTMETH_RAUC_DEFAULT_TRIES. The BOOT_ORDER is _not_
changed, which is logically correct (especially for the case when there is
only one (active) slot set, e.g. BOOT_ORDER only contains 'B', probably due
to RAUC option prevent-late-fallback being set). Resetting the counters of
inactive slots also does not harm here, and is fine as a generic solution.
But the log_info statement in this scenario
INFO: Resetting boot order and all slot tries
is incorrect. Change this to
INFO: Resetting all slot tries to 3
with the 3 being inserted by CONFIG_BOOTMETH_RAUC_DEFAULT_TRIES.
Signed-off-by: Andreas Pretzsch <apr@cn-eng.de>
Reviewed-by: Martin Schwan <m.schwan@phytec.de>
Only PowerPC and LS1021A platforms can make use of RAMBOOT_PBL. Add the
dependencies to the symbol.
Signed-off-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
We have a large number of library symbols that should not be prompted
for by the user really but rather selected by the platform (or SoC) as
needed. To start with however, make these depend on !COMPILE_TEST.
Signed-off-by: Tom Rini <trini@konsulko.com>
This reverts commit 9fe2e4b46458f9c4ec6b8115ebf18b4b26fe6127.
Commit 9fe2e4b46458 ("fdt: Make sure there is no stale initrd left")
introduces a regression in case when U-Boot transfers control to an EFI
app which acts as a subsequent bootloading program. Such an app might
try to set "linux,initrd-start" and "linux,initrd-end" fdt properties,
but by that time those properties are already removed by the code added
in the mentioned commit.
Particularly, the issue was observed on the E850-96 board where GBL EFI
app [1] can't run Android successfully anymore. More specifically, the
kernel can't see the ramdisk and panics with next messages:
/dev/root: Can't open blockdev
VFS: Cannot open root device "" or unknown-block(0,0): error -6
Please append a correct "root=" boot option; ...
Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(0,0)
fdt_initrd() function (where initrd dts properties are removed) is
called two times:
1. First it's called by EFI boot manager (e.g. as a part of U-Boot
Standard Boot mechanism) when it's installing FDT:
fdt_initrd
image_setup_libfdt
efi_install_fdt
efi_bootmgr_run
efi_mgr_boot
It's already enough for EFI app to malfunction. But then it's also
called second time:
2. From the EFI app, via EFI DT fixup protocol:
fdt_initrd
image_setup_libfdt
efi_dt_fixup
struct efi_dt_fixup_protocol efi_dt_fixup_prot = {
.fixup = efi_dt_fixup
};
See [2] for specific GBL code which sets those fdt properties and then
runs DT fixup protocol callback.
This issue was discussed [3], but no action was taken since then. Revert
this patch for now, until a proper solution can be found.
[1] https://source.android.com/docs/core/architecture/bootloader/generic-bootloader/gbl-dev
[2] https://android.googlesource.com/platform/bootable/libbootloader/+/refs/heads/gbl-mainline/gbl/libgbl/src/android_boot/mod.rs#208
[3] https://lists.denx.de/pipermail/u-boot/2025-July/593879.html
Fixes: 9fe2e4b46458 ("fdt: Make sure there is no stale initrd left")
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
The android boot header is page aligned but the current code made the
assumption that the header was always smaller than the current header
format.
When the page_size is defined as 2048, as this is the case with the
cuttlefish target, the current code sets the end of the header in the
middle of it as the v3 and v4 headers are respectively 2112 and 2128
bytes long.
Fix that by aligning to page_size
Fixes: 1115027d2f75 ("android: boot: update android_image_get_data to support v3, v4")
Signed-off-by: Guillaume Ranquet <ranquet.guillaume@gmail.com>
The ARM64 kernel Image size with LOCKDEP enabled is now around 80 MiB, which
makes it unbootable due to "Image too large: increase CONFIG_SYS_BOOTM_LEN".
Increase the image size limit to 128 MiB to future proof the limit.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
