U-Boot EFI Handoff: Refresh the Memory Map Key Before ExitBootServices

A UEFI loader can receive EFI_INVALID_PARAMETER from
U-Boot’s ExitBootServices() even though its memory-map
buffer was valid when filled. The map key identifies the map state
observed by that successful query. Work performed afterward can make the
key stale before the handoff.

In U-Boot v2025.01, the exit function compares the supplied key with
the current key before its main boot-services teardown. Diagnose that
comparison before blaming the kernel entry point or assuming that an
earlier successful map query remains authoritative.

Treat the map and key
as one observation

The UEFI
2.10 boot-services specification requires the current map key at
exit and describes obtaining it with GetMemoryMap(). It
recommends placing that query immediately before the exit attempt. A
stale key requires obtaining the map again and retrying the handoff
under the protocol’s restrictions.

Keep the returned descriptor size and version with the map. The
descriptor stride is an interface value, not something a portable loader
should replace with its own guessed structure size. The buffer’s
existence alone is insufficient: the query must have succeeded and
returned the map associated with the key being submitted.

These are loader responsibilities, not a recommendation to bypass a
rejected key or change firmware’s comparison. The rejection prevents a
loader from taking ownership using an outdated description of
memory.

Follow U-Boot’s return path

The v2025.01
boot-services implementation checks
map_key != efi_memory_map_key at the start of
efi_exit_boot_services(). A mismatch sets
EFI_INVALID_PARAMETER and goes to the exit path.

The main successful path later signals exit-related events, disables
timer activity, performs platform cleanup and removes the boot-services
pointers from the system table. The key comparison precedes that
sequence. This ordering helps localize a rejection, but does not justify
a universal claim that every failed exit has no observable effects;
optional failure notification also exists.

After a successful handoff, the loader must not continue using
boot-services interfaces as if it were still an ordinary EFI
application. A console print added during diagnosis can itself violate
the intended lifecycle if placed after the transition.

Do not
infer key stability from allocation success alone

The memory
implementation returns the current key after successfully copying
the map. Its map-add helper increments that key before allocating the
new internal descriptor. A failure in that later allocation can
therefore still leave the earlier key obsolete.

This is a specific ordering observation in
efi_add_memory_map_pg(), not a claim that every failed
allocation changes the map. It does show why “the intervening allocation
failed” is insufficient proof that a previously captured key remains
usable.

Likewise, allocating a larger destination for the map is preparatory
work, not the final map observation. After arranging adequate storage,
obtain the successful map result that will actually accompany the exit
attempt. Keep unrelated allocation, file access and diagnostics outside
the final query-to-exit interval.

Make
retry behavior observable without reopening the whole workflow

A proposed loader fixture should record the key returned by each
successful query, the key submitted to each exit attempt and the
returned status. Introduce one controlled intervening allocation before
the first attempt, then verify that retry uses a newly acquired map
rather than resubmitting the stale key.

UEFI permits firmware to begin partial shutdown on the first exit
attempt and restricts subsequent boot-service use to memory-allocation
services. Design the retry path accordingly; do not restart arbitrary
device discovery or logging through boot-service protocols after a
failed attempt.

No EFI application or handoff was executed here. The acceptance
question is whether the loader submits a current map observation at the
ownership transition, with a bounded, protocol-compatible recovery path
when that observation becomes stale.