| Age | Commit message (Collapse) | Author |
|---|
|
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]>
|
|
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]
|
|
The chunked decompression loop in gzwrite() treats any inflate()
return value other than Z_OK and Z_STREAM_END as a fatal error. When
the current input chunk happens to be exhausted at exactly the same
time as the write buffer fills up, the inner loop calls inflate()
again with avail_in == 0. No forward progress is possible in that
state, so inflate() returns Z_BUF_ERROR and gzwrite() bails out:
Error: inflate() returned -5
Per the zlib documentation, Z_BUF_ERROR is not fatal and only means
that no progress was possible; the call should be repeated once more
input is available. The reference implementation in zlib
examples/zpipe.c continues in this exact situation.
The failure is data dependent: it needs a stream position where the
consumed input and produced output line up with both the chunk and
the write buffer boundary at once, and the inflate side must have no
buffered output. That is most likely with incompressible input, where
deflate emits stored blocks and inflate holds no lookahead bits. This
is how dm_test_cmd_zip_gzwrite occasionally fails in sandbox64 CI on
random data with gzwrite_chunk = SZ_1M + 1, stopping at a multiple of
the 1 MiB write buffer:
12582912/16777216
Error: inflate() returned -5
Detect this case and let the outer loop refill the input chunk
instead of failing.
On sandbox64, the random data dm_test_cmd_zip_gzwrite test failed
17 out of 2000 runs (about 1 percent) without this fix, every time
with the same signature as the CI flake, and passed 2000 out of 2000
runs with it.
Fixes: 58e523fedf48 ("gunzip: Implement chunked decompression")
Signed-off-by: Aristo Chen <[email protected]>
Reviewed-by: Simon Glass <[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
|
|
On systems with FWU enabled but without the required DT changes the
boottime checks fail. The failures are only reported via log_debug()
which is compiled out by default, so the user has no idea what is going
on.
Use log_err() to make these failures visible.
Signed-off-by: Michal Simek <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
efi_bootmgr_delete_invalid_boot_option(), eficonfig_show_boot_selection(),
and eficonfig_create_change_boot_order_entry() each enumerate all EFI
variables by repeatedly calling efi_next_variable_name() in a loop,
passing the same efi_guid_t as both input and output. GetNextVariableName()
needs the vendor GUID returned by the previous call, together with the
variable name it returned, to know where to resume.
In each of these loops the efi_guid_t was declared inside the loop body,
so a new instance comes into scope on every iteration. Relying on it to
still hold the previous iteration's value depends on the compiler reusing
the same stack slot across iterations, which is undefined behavior. With
a compiler that zero-initializes locals by default (e.g. clang, or gcc
configured with -ftrivial-auto-var-init=zero), the GUID is cleared on
every iteration, so the lookup of the variable name returned by the
previous call fails and efi_init_obj_list() aborts:
Cannot initialize UEFI sub-system
** Booting bootflow ... with efi
Boot failed (err=-22)
Move the efi_guid_t declarations out of the loops so the value written
by the previous efi_next_variable_name() call is preserved across
iterations.
Fixes: 140a8959d48f ("eficonfig: use efi_get_next_variable_name_int()")
Signed-off-by: Scott Moser <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
In case of an error in efi_sigstore_parse_siglist() function
efi_sigstore_free() is called. Currently it fails to free allocated data
because siglist->sig_data_list is not set on the error path.
Always update siglist->sig_data_list when a struct efi_sig_data is
allocated.
Suggested-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Ilias Apalodimas <[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()
|
|
get_dp_device() reads a Boot#### variable and passes its contents to
efi_deserialize_load_option() but ignores the return value. On failure
efi_deserialize_load_option() may return without having initialised the
caller's struct efi_load_option, and even on a malformed device path it
sets lo.file_path before validating it with efi_dp_check_length().
As a result get_dp_device() can proceed to walk lo.file_path with
efi_dp_split_file_path() (via efi_dp_dup()/efi_dp_size()) on a device
path that was never validated, or on an uninitialised pointer when the
variable is too short to be parsed. A device-path node with a length of
zero makes the walk loop forever, and a length below the 4-byte node
header leads to an out-of-bounds read. The Boot#### variable is
attacker-controlled in threat models where writing EFI variables does
not imply the ability to execute firmware code, so this is reachable
during capsule-on-disk processing at boot.
Check the return value and bail out, as every other caller of
efi_deserialize_load_option() already does.
Suggested-by: Hem Parekh <[email protected]>
Cc: Hem Parekh <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
If we use video copy, bit image transfers need to write to the in memory
copy of the physical frame buffer. Damage control will sync the changes
to the physical frame buffer.
Cyclic video copy will catch all changes done by EFI applications directly
accessing the frame buffer copy.
gopobj->mode.fb_base must be a valid pointer to memory and not a virtual
sandbox address.
With this change the block image transfer test works again on the sandbox.
setenv efi_selftest block image transfer
bootefi selftest
Fixes: a75cf70d23ac ("efi: Correct handling of frame buffer")
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
Re-sync the vendored libavb from AOSP external/avb, moving from the ~2019
snapshot (v1.1.0) to v1.3.0. v1.1.0 rejected any vbmeta whose required
libavb minor version was greater than 1 with UNSUPPORTED_VERSION; this
lifts that ceiling and picks up the accumulated upstream fixes.
Synced from commit a1fe228b8654 ("libavb: support chain partition no ab"),
which is where AVB version 1.3.0 was introduced; the vendored files match
this commit verbatim except for the -Wstrict-prototypes fixup noted below.
For more details check [1].
Functionality now parsed by the library:
- AvbVBMetaImageHeader.rollback_index_location (v1.2)
- AvbChainPartitionDescriptor flags / DO_NOT_USE_AB (v1.3)
- AvbHashtreeDescriptor FLAGS_CHECK_AT_MOST_ONCE
- AVB_HASHTREE_ERROR_MODE_PANIC
The AvbOps callback set is unchanged, so the integration layer in
common/avb_verify.c needs no changes.
U-Boot-specific adaptations are preserved rather than pulling upstream's
BoringSSL-oriented crypto restructure (sha/, boringssl/): the U-Boot port
in avb_sysdeps.h / avb_sysdeps_posix.c and the flat avb_sha.h /
avb_sha256.c / avb_sha512.c are kept as-is. The SHA API signatures are
unchanged, so the retained implementation is compatible with the updated
code.
Imported files keep U-Boot's SPDX-License-Identifier header style
and their upstream per-file licenses (avb_rsa.c stays MIT OR
BSD-3-Clause). The unused, Apache-2.0-licensed avb_crc32.c is not
imported.
The import keeps U-Boot's existing local fix from commit fbfcb614e05
("libavb: Fix a warning with clang-15"): avb_new_cmdline_subst_list() is
kept with a (void) parameter list instead of reverting to upstream's
empty () form, which clang rejects under -Werror,-Wstrict-prototypes.
[1] https://android.googlesource.com/platform/external/avb/+/a1fe228b86543a21739c51352f5ce72f134fccfa
Signed-off-by: Igor Opaniuk <[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]
|
|
While this is not likely needed by any "real" driver code, a later
convenience addition to the "config" command will need this. As usual,
the linker will throw it away if nothing actually uses it, so it
should have no size impact when not used.
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Rasmus Villemoes <[email protected]>
|
|
None of these six macros are defined by any architecture. Moreover,
the ifndef guard only exists in either string.h or string.c, making them
completely pointless.
I'm not sure whether we have an explicit coding style discouraging the
"extern" qualifier on function declarations, and string.h has a random
mix of everything, but I can't leave it on strncasecmp() now that it
will be immediately after strcasecmp() which doesn't have it.
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Rasmus Villemoes <[email protected]>
|
|
The last use of this function with rather peculiar semantics[*] vanished
in 2021 with 0a527fda782 ("Fix IDE commands issued, fix endian issues,
fix non MMIO"). It has no tests, and should a need for something
similar ever appear, it is better done with some proper
utf16le/utf16be/utf16 abstractions rather than cluttering code with
'#ifdef __LITTLE_ENDIAN'.
[*] The byte-swapping itself is weird enough. But why is an input string
of odd length ok, while the empty string is not allowed?
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Rasmus Villemoes <[email protected]>
|
|
The len parameter for strnstr() concerns the maximum size of the
haystack to consider, not the length of the needle being searched for.
strstr() obviously has no len parameter, so remove the copy-pasta.
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Rasmus Villemoes <[email protected]>
|
|
Both glibc's (where this originated as a GNU extension) and the
kernel's versions of strchrnul() return "char *", not "const
char *". That also makes it consistent with the standard strchr()
function.
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Rasmus Villemoes <[email protected]>
|
|
is set
PK, KEK, db, dbx etc must always be measured in PCR7.
DeployedMode and AuditMode should be measured in PCR1 if DeployedMode
is set and PCR7 otherwise.
Fix the u16_strcmp to only change the PCR value for those two variables.
Signed-off-by: Ilias Apalodimas <[email protected]>
Acked-by: Heinrich Schuchardt <[email protected]>
|
|
The function defined by the TCG spec looks like:
typedef
EFI_STATUS
(EFIAPI *EFI_TCG2_GET_EVENT_LOG) (
IN EFI_TCG2_PROTOCOL *This,
IN EFI_TCG2_EVENT_LOG_FORMAT EventLogFormat,
OUT EFI_PHYSICAL_ADDRESS *EventLogLocation,
OUT EFI_PHYSICAL_ADDRESS *EventLogLastEntry,
OUT BOOLEAN *EventLogTruncated
);
and the spec mandates that
"If no TPM is present, the function SHALL set the following values and return
EFI_SUCCESS:
EventLogLocation = NULL
EventLogLastEntry = NULL
EventLogTruncated = FALSE"
However, if we set it to NULL the local assignment is discarded when the
function returns. Set it to 0, although on some platforms that's a valid
address.
Signed-off-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
When doing a sha256_update() for the measured DT, the size arguments for
fdt_size_dt_struct() and fdt_size_dt_strings() are inversed.
Signed-off-by: Ilias Apalodimas <[email protected]>
Acked-by: Heinrich Schuchardt <[email protected]>
|
|
In efi_sigstore_parse_siglist() sigdata is allocated. But instead of an
allocation matching the size of sigdata, tainted external data was used
to calculate the allocation size. This may lead to buffer overflows.
* Correct the allocation size.
* Follow the man-page. Use the structure size as second argument for
calloc.
Reviewed-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
Enhance the unit test to verify all Revision fields and all pointers of all
the EFI_BLOCK_IO_PROTOCOL structures.
As the unit test registers its own block io protocol for test purposes,
make sure to initialize its revision properly, as it will be verified as
well.
This can run on the sandbox with the following command:
./u-boot -T -c 'setenv efi_selftest block device; bootefi selftest'
Suggested-by: Heinrich Schuchardt <[email protected]>
Signed-off-by: Vincent Stehlé <[email protected]>
Cc: Ilias Apalodimas <[email protected]>
Cc: Tom Rini <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
In the block device selftest, make the handles pointer global and free it
also in teardown(), to simplify error handling.
We also need to nullify the pointer after freeing it on the normal path,
to avoid freeing it a second time during teardown().
Signed-off-by: Vincent Stehlé <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
Since commit bd3f9ee679b4 ("kbuild: Bump the build system to 6.1")
out-of-tree builds with CONFIG_EFI_VARIABLES_PRESEED=y fail with errors
like:
../lib/efi_loader/efi_var_seed.S:14: Error: file not found:
ubootefi.var
For out-of-tree build we cannot use CONFIG_EFI_VAR_SEED_FILE in the
.incbin statement of file efi_var_seed.S.
* We have to prepend $(srctree) if the path is relative.
* We must not prepend $(srctree) if the path is absolute.
Fixes: bd3f9ee679b4 ("kbuild: Bump the build system to 6.1")
Reported-by: Jon Mason <[email protected]>
Closes: https://lore.kernel.org/u-boot/CAPoiz9zg4OXgHo5J3WtJHKOEuWOdCDrugWfAt6Z+d71j=+q8oA@mail.gmail.com/T/#mffaca10a9e812d03eceafad59999a02e57258b9a
Tested-by: Nora Schiffer <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Tested-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
We are missing a call to EFI_EXIT() when returning from
efi_disconnect_controller(), which we need after having called EFI_ENTRY().
Fix this by jumping to the common error path, which does call EFI_EXIT().
Even though the common error path may try to free child_handle_buffer, this
cannot harm in our case as it always NULL.
This is inspired by a barebox fix. [1]
Link: https://git.pengutronix.de/cgit/barebox/commit/?id=080db65e39a877b000baaf843c997a69821dfe69 [1]
Fixes: 314bed6c854e ("efi_loader: fix DisconnectController() for sole child")
Signed-off-by: Vincent Stehlé <[email protected]>
Cc: Heinrich Schuchardt <[email protected]>
Cc: Ilias Apalodimas <[email protected]>
Cc: Tom Rini <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
PMBus regulators differ in numeric formats and quirks, not in how they
are driven. Share that common behaviour as a regulator-uclass adapter
so chip drivers and the pmbus CLI do not each reimplement the decode
and transport, and add a catch-all driver on compatible = "pmbus" for
compliant chips that have no dedicated driver yet.
Gated by CONFIG_DM_REGULATOR_PMBUS_HELPER and
CONFIG_DM_REGULATOR_PMBUS_GENERIC.
Signed-off-by: Vincent Jardin <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
Add U-Boot's PMBus 1.x layer: the decoder/transport library, the
pmbus CLI command and a generic DT binding.
The subsequent commits provide the UCLASS_REGULATOR adapter and per-chip
drivers.
U-Boot's PMBus support is not a hwmon clone of Linux's
drivers/hwmon/pmbus/. Linux owns the runtime side (polling, sysfs,
alert IRQs, fan loops). U-Boot owns the boot-time side in order to,
- identify the PMBus regulators a board carries: MFR_ID/
MFR_MODEL/MFR_REVISION + sanity checks.
- print telemetry (VIN/VOUT/IIN/IOUT/POUT/TEMP) so an
operator can confirm rail voltages and faults before the kernel
- decode any chip alerts (STATUS_VOUT/STATUS_IOUT/STATUS_INPUT/
STATUS_TEMPERATURE/STATUS_CML) so a boot log shows why the
previous boot failed or the board had been power cycled because
of an outage (typically over temperature or under current).
Out of scope by design: no periodic polling, no sysfs, no fan-speed
control loop, no PMBUS_VIRT_* sensor virtualisation, no caching.
If a use case needs any of those, the answer should be "wait until
Linux comes up". It shall remain a thin layer.
The constants and structural shape (command codes, status bit names,
sensor-class enum, format enum, struct pmbus_driver_info) are
mirrored from Linux drivers/hwmon/pmbus/pmbus.h verbatim. The
decoders/encoders are reimplemented from the PMBus 1.3
specification because the surrounding hwmon context (struct
pmbus_data, sysfs caching, hwmon publication) does not apply.
The main benefits:
- One framework + CLI for any board carrying PMBus regulators:
no per-board PMBus implementation required anymore.
- Boards call pmbus_print_telemetry() / pmbus_print_status_word()
directly from boot init for a snapshot, sharing all decode +
format-dispatch with the CLI.
- Linux-compatible constants and DT binding so porting an existing
drivers/hwmon/pmbus/ chip is mechanical.
- Boot-time AVS/VID rail trim reuses the same decoders and
encoders as the CLI and the regulator path: no duplicate math.
Signed-off-by: Vincent Jardin <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
|
|
In preparation of the migration of the mailman mailing-list currently
hosted on the denx.de infrastructure, migrate the links in the code,
comments and documentation to https://patch.msgid.link to be future proof
and always link to the expected content data and uses the message-id in
the URL which will help find the appropriate e-mail in the future.
Signed-off-by: Neil Armstrong <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
Restyle all Kconfigs for "lib":
Menu entries : no space left
Menu attributes: 1 TAB
Help text : 1 TAB + 2 spaces
Replace '---help---' by 'help'
Signed-off-by: Johan Jonker <[email protected]>
|
|
Currently, the bi_dram[] information is stored in the board info
structure (bd). Because bd is only valid after reserve_board(),
dram_init_banksize() must be called late in the initialization process.
This limitation is problematic, as it forces us to rely on a variety of
bespoke functions to determine board RAM, bank memory sizes, and other
early setup requirements.
By moving bi_dram[] into the global data (gd), we can run it earlier.
This is particularly convenient since boards define their own
dram_init_banksize() routines, which do not always rely on parsing
Device Tree (DT) memory nodes.
Additionally, U-Boot defaults to relocating to the top of the first memory
bank. While boards currently use custom functions to override this
behavior, having the DRAM bank information available earlier in gd makes
relocating to a different bank trivial and standardizes the process.
Reviewed-by: Anshul Dalal <[email protected]>
Tested-by: Michal Simek <[email protected]> # Versal Gen 2 Vek385
Tested-by: Anshul Dalal <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
Tested-by: Christophe Leroy (CS GROUP) <[email protected]>
|
|
Prepare v2026.07-rc5
|
|
When the `memory' efi selftest verifies the Devicetree memory reservation,
it accesses the memory_map buffer after it has been freed with free_pool().
Move the verification earlier to fix this.
Fixes: 34c96659ed57 ("efi_selftest: check fdt is marked as runtime data")
Signed-off-by: Vincent Stehlé <[email protected]>
Cc: Heinrich Schuchardt <[email protected]>
Cc: Ilias Apalodimas <[email protected]>
Cc: Tom Rini <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
The Revision field of the EFI_BLOCK_IO_PROTOCOL structure must be set to
one of the two valid values [1], but this is not initialized in the
efi_loader; fix it.
Link: https://uefi.org/specs/UEFI/2.11/13_Protocols_Media_Access.html#efi-block-io-protocol [1]
Signed-off-by: Vincent Stehlé <[email protected]>
Cc: Heinrich Schuchardt <[email protected]>
Cc: Ilias Apalodimas <[email protected]>
Cc: Tom Rini <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
Barebox has now ported some of the UEFI code. In the process
they found some bugs.
In this case when the variable buffer is too small, efi_var_collect()
returns EFI_BUFFER_TOO_SMALL but doesn't free the allocated 'buf'.
Fixes: 5f7dcf079de8c ("efi_loader: UEFI variable persistence")
Signed-off-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
The `loaded image' efi selftest is comparing protocol GUIDs with the wrong
polarity.
This can be verified on the sandbox, where two protocols GUIDs are
retrieved by the test from the image handle in the following order:
1. Loaded Image Device Path Protocol GUID
2. Loaded Image Protocol GUID
The test matches on the first GUID, while it is in fact looking for the
second one; fix the comparison polarity.
Fixes: efe79a7c0de0 ("efi_selftest: test for loaded image protocol")
Signed-off-by: Vincent Stehlé <[email protected]>
Cc: Heinrich Schuchardt <[email protected]>
Cc: Ilias Apalodimas <[email protected]>
Cc: Tom Rini <[email protected]>
Cc: Alexander Graf <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
Tom Rini <[email protected]> says:
As part of the resync to dtc version v1.7.2-35-g52f07dcca47c from the
Linux Kernel, we missed updating the fdt_check_full function because it
exists in its own file in upstream dtc and the kernel doesn't import it,
as reported by Anton Ivanov. This short series brings in the upstream
fdt_check.c file and then implements our size-saving option, but in the
modern way.
The size-saving portion has been upstreamed.
Link: https://lore.kernel.org/r/[email protected]
|
|
In the upstream project, the function fdt_check_full has been moved from
fdt_ro.c to its own file, fdt_check.c. This file is not included in the
Linux kernel copy and so has not been synced over. As we do need and use
the fdt_check_full function, bring that file over as of the current
upstream we are synced to. Remove our copy of this function from
fdt_ro.c and add fdt_check.o and 1-liner fdt_check.c where needed. Note
that for now, this will increase size in some cases as upstream does not
have a size reduction method here.
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
Loading EFI parts like a Debian-Installer on Rockchip SoCs creates
interesting results, in that on some boards the Grub bootloader can't
find any partitions on a USB-Stick, or loading a kernel from Grub spews
EHCI fail timeout STS_IAA set
messages before failing and on others the loading something like efivars
from an eMMC creates read errors and making the MMC vanish from U-Boot.
This only affected boards with at least 4GB of RAM.
These boards have at least 256MB of memory placed above the actual 4GB
address space (due to the iomem being in between) and while kernel,
initramfs, dt are generally loaded to predefined addresses, additional
EFI parts (efivars, etc) are likely just loaded "somewhere" and it seems
this always landed in that higher up memory part.
Also in the Linux-kernel peripherals like EMMC, USB, etc already run
with a 32bit dma-mask set.
So far, I've seen this on RK3568 and RK3588, but as the same peripherals
are used on most Rockchip SoCs, it makes sense to limit this on all.
So add ARCH_ROCKCHIP to the default-y list of LMB_LIMIT_DMA_BELOW_RAM_TOP.
Signed-off-by: Heiko Stuebner <[email protected]>
Reviewed-by: Jonas Karlman <[email protected]>
Reviewed-by: Peter Robinson <[email protected]>
|
|
[email protected] <[email protected]> says:
From: Randolph Sapp <[email protected]>
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/[email protected]/
[2] https://github.com/StaticRocket/u-boot/tree/feature/pocketbeagle2
Link: https://lore.kernel.org/r/[email protected]
|
|
Add a new global data struct member called initial_relocaddr. This
stores the original value of relocaddr, directly from setup_dest_addr.
This is specifically to avoid any adjustments made by other init
functions.
Reserve the memory from gd->start_addr_sp - CONFIG_STACK_SIZE to
gd->initial_relocaddr instead of gd->ram_top. This allows platform
specific relocation addresses to work without unnecessarily painting
over a large range.
Signed-off-by: Randolph Sapp <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-efi
Pull request efi-2026-07-rc5
CI: https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/30365
Documentation:
* Update urllib3 version for building
* usb: typos 'requird', 'current'
UEFI
* Improve PE-COFF relocation data validation
Devicetree-to-C generator:
* dtoc: test: add missing escape in help text
|
|
Prepare v2026.07-rc4
|
|
smbios_write_type3() uses SYSID_SM_BASEBOARD_ASSET_TAG (Type 2) instead
of SYSID_SM_ENCLOSURE_ASSET_TAG (Type 3) for the enclosure asset tag.
This causes the enclosure's asset tag to be read from the baseboard
sysinfo field rather than the enclosure-specific one.
Fixes: bcf456dd ("smbios: add detailed smbios information")
Signed-off-by: Frank Böwingloh <[email protected]>
Cc: Raymond Mao <[email protected]>
Cc: Tom Rini <[email protected]>
Cc: Ilias Apalodimas <[email protected]>
Reviewed-by: Raymond Mao <[email protected]>
|
|
Rename LMB_LIMIT_DMA_BELOW_4G to LMB_LIMIT_DMA_BELOW_RAM_TOP
to make the Kconfig option more descriptive. No functional
change.
Suggested-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Marek Vasut <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
When applying base relocations from a PE-COFF binary all data must
be treated as untrusted. Add the following checks to
efi_loader_relocate():
* Reject relocation blocks that don't start on a 32-bit aligned
address.
* Reject relocation blocks whose SizeOfBlock is smaller than the
block header, which would cause an unsigned underflow when computing
the entry count.
* A block with SizeOfBlock == 0 is invalid and does not mark the end of
the relocation table.
* Reject relocation blocks that extend beyond the end of the
relocation section.
* Reject individual relocation entries whose target offset, together
with the access width, exceeds the mapped image size, preventing
out-of-bounds writes.
Pass virt_size to efi_loader_relocate() from efi_load_pe() to enable
the per-entry bounds check.
Reported-by: Anas Cherni <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
Some architectures can not DMA above 4 GiB boundary,
limit available memory to memory below 4 GiB boundary.
Signed-off-by: Marek Vasut <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Tested-by: Ilias Apalodimas <[email protected]> #rpi4 8GiB
|
|
Tom Rini <[email protected]> says:
This series does a few small but important cleanups to how we check for,
and initialize a bloblist. The first thing is that the way things are
done today, our HANDOFF code can only work with a fixed bloblist
location, so express that requirement in Kconfig. Next, we demote the
scary message about "Bloblist at ... not found" to a debug because we
most often see that because the bloblist doesn't (and can't) exist yet.
Finally, we remove bloblist_maybe_init and split this in to an exists
and a real init. This results in practically no growth (between 8 bytes
growth to 12 bytes saved, with some outliers saving much more thanks to
knowing it's impossible to have been passed a bloblist yet). This also
cleans up some of the code around checking for / knowing about a
bloblist existing.
Link: https://lore.kernel.org/r/[email protected]
|
