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 <michal.simek@amd.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
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: 140a8959d4 ("eficonfig: use efi_get_next_variable_name_int()")
Signed-off-by: Scott Moser <smoser@brickies.net>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
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 <ilias.apalodimas@linaro.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
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 <hemparekh1596@gmail.com>
Cc: Hem Parekh <hemparekh1596@gmail.com>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
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: a75cf70d23 ("efi: Correct handling of frame buffer")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
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 fbfcb614e0
("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 <igor.opaniuk@gmail.com>
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 <james.hilliard1@gmail.com>
[Jerome Forissier: remove trailing ':' after SPDX tag]
Signed-off-by: Jerome Forissier <jerome.forissier@arm.com>
Reviewed-by: Jerome Forissier <jerome.forissier@arm.com>
Rasmus Villemoes <rv@rasmusvillemoes.dk> 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/20260708203711.849489-1-rv@rasmusvillemoes.dk
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 <sjg@chromium.org>
Signed-off-by: Rasmus Villemoes <rv@rasmusvillemoes.dk>
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 <sjg@chromium.org>
Signed-off-by: Rasmus Villemoes <rv@rasmusvillemoes.dk>
The last use of this function with rather peculiar semantics[*] vanished
in 2021 with 0a527fda78 ("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 <sjg@chromium.org>
Signed-off-by: Rasmus Villemoes <rv@rasmusvillemoes.dk>
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 <sjg@chromium.org>
Signed-off-by: Rasmus Villemoes <rv@rasmusvillemoes.dk>
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 <sjg@chromium.org>
Signed-off-by: Rasmus Villemoes <rv@rasmusvillemoes.dk>
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 <ilias.apalodimas@linaro.org>
Acked-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
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 <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
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 <ilias.apalodimas@linaro.org>
Acked-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
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 <ilias.apalodimas@linaro.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
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 <xypron.glpk@gmx.de>
Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Tom Rini <trini@konsulko.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
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é <vincent.stehle@arm.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
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 <vjardin@free.fr>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
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 <vjardin@free.fr>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
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 <neil.armstrong@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
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 <jbx6244@gmail.com>
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 <anshuld@ti.com>
Tested-by: Michal Simek <michal.simek@amd.com> # Versal Gen 2 Vek385
Tested-by: Anshul Dalal <anshuld@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Tested-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
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: 34c96659ed ("efi_selftest: check fdt is marked as runtime data")
Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Tom Rini <trini@konsulko.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
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: 5f7dcf079d ("efi_loader: UEFI variable persistence")
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
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: efe79a7c0d ("efi_selftest: test for loaded image protocol")
Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Alexander Graf <agraf@csgraf.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Tom Rini <trini@konsulko.com> 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/20260526202218.4004070-1-trini@konsulko.com
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 <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
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 <heiko@sntech.de>
Reviewed-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
rs@ti.com <rs@ti.com> says:
From: Randolph Sapp <rs@ti.com>
Nitpicks and fixes from the discovery thread on adding PocketBeagle2 support
[1]. This does a lot of general setup required for the device, but these
modifications themselves aren't device specific. For those specifically
interested in PocketBeagle2 support and don't care about these details, my
development branch is public [2].
That first patch may provoke some opinions, but honestly if that warning was
still present I wouldn't have spent a week poking holes in both the EFI and LMB
allocations systems. Please let me know if there is a specific usecase that it
breaks though.
[1] https://lore.kernel.org/all/DHHC66BBMD27.YHGIH43C6XBK@ti.com/
[2] https://github.com/StaticRocket/u-boot/tree/feature/pocketbeagle2
Link: https://lore.kernel.org/r/20260604155038.3182-1-rs@ti.com
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 <rs@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
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
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 <f.boewingloh@beckhoff.com>
Cc: Raymond Mao <raymondmaoca@gmail.com>
Cc: Tom Rini <trini@konsulko.com>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Raymond Mao <raymondmaoca@gmail.com>
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 <anas@calif.io>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Tom Rini <trini@konsulko.com> 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/20260519162225.770071-1-trini@konsulko.com
With bloblist, we need to both see if one already exists as well as
create one if it does not. However, the current implementation leads to
odd cases where we attempt to create a bloblist before this is possible
and have things be overly complicated when we are given one to work
with.
This reworks things to instead have a bloblist_exists function, which as
the name implies checks for an existing bloblist. This is used in
the case of booting, to see if we have one and in turn if we have a
device tree there as well as in the bloblist_init function to see if we
need to do anything.
In practical details, we move the logic from bloblist_init that was
checking for a bloblist to the new bloblist_exists function and then can
clarify the logic as it is much easier to state when we know we do not
have one rather than all the ways we might have one. Then we have the
locations that set gd->bloblist now also set the GD_FLG_BLOBLIST_READY
flag.
Reviewed-by: Raymond Mao <raymondmaoca@gmail.com>
Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
The HII database test for keyboard layouts register two package lists with
two keyboard layouts each, but the test verifies only the GUID of the first
keyboard layout.
This does not catch the bugs happening with the keyboard layouts after the
first one in a package.
Verify all the keyboard layout GUIDs in the unit test to prevent this.
Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Tom Rini <trini@konsulko.com>
The EFI_HII_KEYBOARD_LAYOUT field `layout_length' is expressed in bytes,
but we add it to the `layout' pointer with (scaled) pointer arithmetic.
When adding an HII keyboard package with multiple keyboard layouts, this
results in only the first layout being added correctly; fix it.
Fixes: 8d3b77e36e ("efi: hii: add keyboard layout package support")
Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: AKASHI Takahiro <akashi.tkhro@gmail.com>
