u-boot.git/lib/efi_loader, branch v2026.04-rc2

efi_net: add missing EFI_CALL in efi_net

2026-02-06T09:04:30+00:00

The efi_reinstall_protocol_interface() function is a UEFI function;
make sure to call it from within U-Boot using the EFI_CALL() macro.

This fixes the following assertion:

  lib/efi_loader/efi_boottime.c:3752: efi_reinstall_protocol_interface: Assertion `__efi_entry_check()' failed.

To reproduce the issue, define LOG_DEBUG in lib/efi_loader/efi_boottime.c
and build u-boot for your platform. Then, boot the U-Boot helloworld.efi
application over the network. Example commands (adjust the URL and boot
entry number):

  => efidebug boot add -u 0 net http://10.0.2.2:8000/helloworld.efi
  => efidebug boot order 0
  => bootefi bootmgr

Fixes: dd5d82a59995 ("efi_loader: efi_net: Add device path cache")
Signed-off-by: Vincent Stehlé 
Cc: Heinrich Schuchardt 
Cc: Ilias Apalodimas 
Cc: Tom Rini 
Cc: Adriano Cordova 
Reviewed-by: Heinrich Schuchardt

efi_loader: fix efi_debug_image_info_normal allocation

2026-02-06T08:57:00+00:00

When adding a new EFI Debug Image Info entry, we allocate memory for a new
EFI Debug Image Info Normal structure and we add a new entry into the EFI
Debug Image Info Table, which is in fact just a pointer to the allocated
structure.

However, when allocating memory for the new structure we allocate memory
for the wrong type, leading to allocating memory for just a pointer instead
of the desired structure.

Fix the type used during allocation.

Fixes: 146546138af5 ("efi: add EFI_DEBUG_IMAGE_INFO for debug")
Signed-off-by: Vincent Stehlé 
Cc: Heinrich Schuchardt 
Cc: Ilias Apalodimas 
Cc: Tom Rini 
Cc: Ying-Chun Liu (PaulLiu) 
Reviewed-by: Heinrich Schuchardt

efi_loader: Improve EFI variable load message

2026-02-06T08:56:45+00:00

Change the EFI variable load message from log_err() to log_info() with
neutral wording. The previous "Failed to load" message caused customer
confusion as it appeared to indicate an error condition.

The efi_var_from_file() function deliberately returns EFI_SUCCESS in
this case to allow the boot process to continue normally. This is
documented in the function's comment block but was not reflected in
the log message level or content.

The message now uses informational wording to reflect that this is
normal behavior when the ubootefi.var file does not yet exist.

Signed-off-by: Pranav Tilak 
Reviewed-by: Heinrich Schuchardt

efi_loader: fix use after free in efi_exit() with tcg2

2026-02-06T08:32:32+00:00

The efi_exit() function frees the loaded image memory by calling
efi_delete_image(). However, when CONFIG_EFI_TCG2_PROTOCOL is enabled, the
image_obj->image_type structure member is accessed after the memory has
been freed.

Fix this by performing the tcg2 measurement before the image deletion.

Fixes: 8fc4e0b4273a ("efi_loader: add boot variable measurement")
Suggested-by: Ilias Apalodimas 
Signed-off-by: Vincent Stehlé 
Cc: Heinrich Schuchardt 
Cc: Tom Rini 
Cc: Masahisa Kojima 
Acked-by: Masahisa Kojima 
Reviewed-by: Heinrich Schuchardt

kbuild: Bump the build system to 6.1

2026-01-02T16:28:14+00:00

Our last sync with the kernel was 5.1.

We are so out of sync now, that tracking the patches and backporting
them one by one makes little sense and it's going to take ages.

This is an attempt to sync up Makefiles to 6.1.
Unfortunately due to sheer amount of patches this is not easy to review,
but that's what we decided during a community call for the bump to 5.1,
so we are following the same guidelines here.

Signed-off-by: Sughosh Ganu 
Signed-off-by: Ilias Apalodimas a #rebased on -next

efi_loader: Trigger capsule updates with automatically generated boot options

2025-12-24T07:32:35+00:00

The EFI spec in §8.5.5 says
"The directory \EFI\UpdateCapsule is checked for capsules only within
 the EFI system partition on the device specified in the active boot
 option determine by reference to BootNext variable or BootOrder variable
 processing."

Automatically generated boot options don't point to the ESP, they point to
the disk itself and find_handle() won't match when searching for an ESP
during a capsule update.
This happens because find_handle() only matches device paths that are
shorter or equal to the device path passed as an argument.
Since the EFI spec allows it we want to allow capsule updates, when the
boot option points to a disk, but that disk contains an ESP with a
\EFI\UpdateCapsule directory.

So, let's change device_is_present_and_system_part() and check if the
supplied device path contains an ESP. If it does return the handle of
the device. Otherwise, iterate over child devices and return the handle
of the first child that contains an ESP.

The returned handle can then be reused later. Rather than calling
efi_fs_from_path(), we can simply look up the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL
on the discovered handle, avoiding the need to re-parse device paths.

Reported-by: Balaji Selvanathan 
Reported-by: John Toomey 
Signed-off-by: Ilias Apalodimas 
Reviewed-by: Heinrich Schuchardt

Merge tag 'v2026.01-rc4' into next

2025-12-08T19:17:27+00:00

Prepare v2026.01-rc4

efi_loader: Fix a memory leak when retrieving device paths from boot vars

2025-12-06T10:43:28+00:00

get_dp_device() is used to derive the device path from a boot variable.
However, if the last efi_get_variable_int() call fails, we return an
error without freeing 'buf'.

There's no need to call efi_get_variable_int() for variables we don't
know the size since we have the efi_get_var() wrapper.

Replace that in the two instances we use it. The first one will also
fix the memory leak.
A nice sideeffect is that the code size is also reduced, since we are
re-using functions instead of open coding them

$~ bloat-o-meter u-boot u-boot.new
add/remove: 0/0 grow/shrink: 1/2 up/down: 6/-196 (-190)
Function                                     old     new   delta
version_string                                70      76      +6
efi_launch_capsules                         2288    2196     -92
get_dp_device                                244     140    -104
Total: Before=1222331, After=1222141, chg -0.02%

Fixes: c74cd8bd08d1 ("efi_loader: capsule: add capsule_on_disk support")
Signed-off-by: Ilias Apalodimas 
Reviewed-by: Heinrich Schuchardt

tpm2: add sm3 256 hash support

2025-12-04T15:38:58+00:00

add sm3 256 hash support, so TPM2 chips which report
5 pcrs with sm3 hash do not fail with:

  u-boot=> tpm2 autostart
  tpm2_get_pcr_info: too many pcrs: 5
  Error: -90

Signed-off-by: Heiko Schocher

efi_loader: Assure fitImage from capsule is used from 8-byte aligned address

2025-11-15T10:50:42+00:00

The fitImage may be stored in EFI update capsule at address that
is not aligned to 8 bytes. Since fitImage is a DT, new version of
libfdt 1.7.2 rejects such an unaligned DT. Patch the code and copy
the fitImage into aligned buffer in case it is not aligned. This
does increase overhead for unaligned fitImages in EFI capsules, but
tries to keep the overhead low for aligned ones.

Signed-off-by: Marek Vasut 
Reviewed-by: Heinrich Schuchardt