summaryrefslogtreecommitdiff
path: root/scripts
diff options
context:
space:
mode:
authorIlias Apalodimas <[email protected]>2025-12-17 11:40:04 +0200
committerHeinrich Schuchardt <[email protected]>2025-12-24 08:32:35 +0100
commit2ca1d6028446c612c55a7c49431d793b28ba2195 (patch)
tree61fbc5fd5f7a6ca99c2c5aa2c106389cde61fada /scripts
parent7ed2098fa9a5d0132c4f37baca8a6247a8ef5548 (diff)
efi_loader: Trigger capsule updates with automatically generated boot options
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 <[email protected]> Reported-by: John Toomey <[email protected]> Signed-off-by: Ilias Apalodimas <[email protected]> Reviewed-by: Heinrich Schuchardt <[email protected]>
Diffstat (limited to 'scripts')
0 files changed, 0 insertions, 0 deletions