EFI U-Boot Custodian Tree issueshttps://source.denx.de/u-boot/custodians/u-boot-efi/-/issues2024-01-19T22:50:59Zhttps://source.denx.de/u-boot/custodians/u-boot-efi/-/issues/16RISC-V: Separate text and data sections in EFI binaries2024-01-19T22:50:59ZHeinrich Schuchardtxypron.glpk@gmx.deRISC-V: Separate text and data sections in EFI binariesEFI binaries should not have sections that are both writable and executable.
We already corrected this for arm64.EFI binaries should not have sections that are both writable and executable.
We already corrected this for arm64.Heinrich Schuchardtxypron.glpk@gmx.deHeinrich Schuchardtxypron.glpk@gmx.dehttps://source.denx.de/u-boot/custodians/u-boot-efi/-/issues/15tcg2_measure_smbios() should check if the table is SMBIOS 2.1 or SMBiOS 32024-01-19T22:51:34ZHeinrich Schuchardtxypron.glpk@gmx.detcg2_measure_smbios() should check if the table is SMBIOS 2.1 or SMBiOS 3Two different versions of the SMBIOS entry point exist with different positions of the table length field.Two different versions of the SMBIOS entry point exist with different positions of the table length field.Ilias ApalodimasIlias Apalodimashttps://source.denx.de/u-boot/custodians/u-boot-efi/-/issues/14ConnectController() expects DriverImageHandle to be a pointer to a NULL termi...2023-11-28T18:01:25ZHeinrich Schuchardtxypron.glpk@gmx.deConnectController() expects DriverImageHandle to be a pointer to a NULL terminated list of handles.Our implementation treats parameter DriverImageHandle as a single handle. According to the UEFI specification it is a pointer to a NULL terminated list of handles.Our implementation treats parameter DriverImageHandle as a single handle. According to the UEFI specification it is a pointer to a NULL terminated list of handles.Ilias ApalodimasIlias Apalodimashttps://source.denx.de/u-boot/custodians/u-boot-efi/-/issues/13Auto-generated boot options2023-10-17T20:13:25ZHeinrich Schuchardtxypron.glpk@gmx.deAuto-generated boot optionsThe code for auto-generated boot options has some issues:
- boot options should be created for devices not for partitions
- auto-generation of boot options is only mandated if a boot options with short-form File Path Media Device Path is...The code for auto-generated boot options has some issues:
- boot options should be created for devices not for partitions
- auto-generation of boot options is only mandated if a boot options with short-form File Path Media Device Path is hit.
- removable media should be enumerated before non-removable media. This probably needs to be observed for the default File Path Media Device Paths (e.g. "EFI\BOOT\BOOTRISCV64.EFI"), too.
See this sentence in the UEFI specification:
"When the boot manager attempts to
boot a short-form File Path Media Device Path, it will enumerate all removable media devices, followed
by all fixed media devices, creating boot options for each device."Ilias ApalodimasIlias Apalodimashttps://source.denx.de/u-boot/custodians/u-boot-efi/-/issues/12efi_set_virtual_address_map(): system table not updated2023-10-03T00:41:03ZHeinrich Schuchardtxypron.glpk@gmx.deefi_set_virtual_address_map(): system table not updatedAccording to the EFI specification the fields FirmwareVendor, RuntimeServices, and ConfigurationTable of the system table must be updated.According to the EFI specification the fields FirmwareVendor, RuntimeServices, and ConfigurationTable of the system table must be updated.https://source.denx.de/u-boot/custodians/u-boot-efi/-/issues/11Duplicate definitions for EFI capsules: tools/eficapsule.h, include/efi_api.h2023-07-09T08:23:17ZHeinrich Schuchardtxypron.glpk@gmx.deDuplicate definitions for EFI capsules: tools/eficapsule.h, include/efi_api.hStructures for EFI capsules should be defined in a single location. This will avoid type conflicts.Structures for EFI capsules should be defined in a single location. This will avoid type conflicts.https://source.denx.de/u-boot/custodians/u-boot-efi/-/issues/10Implement EFI_SECURITY_ARCH_PROTOCOL, EFI_SECURITY2_ARCH_PROTOCOL2023-06-28T20:36:29ZHeinrich Schuchardtxypron.glpk@gmx.deImplement EFI_SECURITY_ARCH_PROTOCOL, EFI_SECURITY2_ARCH_PROTOCOLSystemd boot overrides EFI_SECURITY_ARCH_PROTOCOL, EFI_SECURITY2_ARCH_PROTOCOL for verifying images loaded via LoadImage() and thereby avoids reimplementing LoadImage(), https://github.com/systemd/systemd/blob/main/src/boot/efi/secure-bo...Systemd boot overrides EFI_SECURITY_ARCH_PROTOCOL, EFI_SECURITY2_ARCH_PROTOCOL for verifying images loaded via LoadImage() and thereby avoids reimplementing LoadImage(), https://github.com/systemd/systemd/blob/main/src/boot/efi/secure-boot.c#L181C1-L219C1.
We should wrap efi_image_authenticate() as EFI_SECURITY2_ARCH_PROTOCOL.FileAuthentication().Ilias ApalodimasIlias Apalodimashttps://source.denx.de/u-boot/custodians/u-boot-efi/-/issues/9Eliminate struct efi_disk_obj2023-06-28T20:37:10ZHeinrich Schuchardtxypron.glpk@gmx.deEliminate struct efi_disk_objCurrently we use `struct efi_disk_obj` to keep information about block devices and partitions.
As the handle already has a field with the udevice this seem not be necessary anymore. We should target to eliminate `struct efi_disk_obj` an...Currently we use `struct efi_disk_obj` to keep information about block devices and partitions.
As the handle already has a field with the udevice this seem not be necessary anymore. We should target to eliminate `struct efi_disk_obj` and use an `struct efi_obj` for the handle.https://source.denx.de/u-boot/custodians/u-boot-efi/-/issues/8efi_delete_handle must delete handle from events2023-08-30T07:16:47ZHeinrich Schuchardtxypron.glpk@gmx.deefi_delete_handle must delete handle from eventsWhen a protocol interface is installed a reference to the handle is added to events that have been registered with RegisterProtocolNotify(). The same handle may be referenced multiple times in an event and in multiple events.
Before del...When a protocol interface is installed a reference to the handle is added to events that have been registered with RegisterProtocolNotify(). The same handle may be referenced multiple times in an event and in multiple events.
Before deleting a handle in efi_delete_handle() we must remove all handle references in events.Heinrich Schuchardtxypron.glpk@gmx.deHeinrich Schuchardtxypron.glpk@gmx.dehttps://source.denx.de/u-boot/custodians/u-boot-efi/-/issues/7efi_check_allocated() only checks start address2022-11-06T00:11:39ZHeinrich Schuchardtxypron.glpk@gmx.deefi_check_allocated() only checks start addressAllocatePages() and FreePages() call efi_check_allocated() to check if a memory address is allocated or not.
The function should consider the number of pages in the request and either check if the full range is deallocated or the full r...AllocatePages() and FreePages() call efi_check_allocated() to check if a memory address is allocated or not.
The function should consider the number of pages in the request and either check if the full range is deallocated or the full range is allocated.https://source.denx.de/u-boot/custodians/u-boot-efi/-/issues/6Agent handle used by LocateHandle()2023-05-27T22:50:27ZHeinrich Schuchardtxypron.glpk@gmx.deAgent handle used by LocateHandle()The UEFI specification 2.10 suggests to implement EFI_BOOT_SERVICES.HandleProtocol() using agent handle EfiCoreImageHandle when calling OpenProtocol(). This would imply generating an open protocol information. CloseProtocol() would have ...The UEFI specification 2.10 suggests to implement EFI_BOOT_SERVICES.HandleProtocol() using agent handle EfiCoreImageHandle when calling OpenProtocol(). This would imply generating an open protocol information. CloseProtocol() would have to be called with the same agent handle to delete the open protocol information. This would only make a difference when uninstalling protocols on the EfiCoreImageHandle.
Task:
Investigate the implications.Ilias ApalodimasIlias Apalodimashttps://source.denx.de/u-boot/custodians/u-boot-efi/-/issues/5efi_dp_part_node() does not check return value of dp_alloc()2022-12-29T09:58:33ZHeinrich Schuchardtxypron.glpk@gmx.deefi_dp_part_node() does not check return value of dp_alloc()dp_alloc() may return NULL. This needs to be caught.dp_alloc() may return NULL. This needs to be caught.v2023.01Heinrich Schuchardtxypron.glpk@gmx.deHeinrich Schuchardtxypron.glpk@gmx.dehttps://source.denx.de/u-boot/custodians/u-boot-efi/-/issues/4dp_part_node() does not check the return value of part_get_info()2023-06-07T14:20:04ZHeinrich Schuchardtxypron.glpk@gmx.dedp_part_node() does not check the return value of part_get_info()part_get_info() may return an error code. This should be caught in dp_part_node().
Coverity CID 184067part_get_info() may return an error code. This should be caught in dp_part_node().
Coverity CID 184067Heinrich Schuchardtxypron.glpk@gmx.deHeinrich Schuchardtxypron.glpk@gmx.dehttps://source.denx.de/u-boot/custodians/u-boot-efi/-/issues/3ESRT table incomplete if one FMP protocol fails2023-06-28T20:38:43ZHeinrich Schuchardtxypron.glpk@gmx.deESRT table incomplete if one FMP protocol failsFunction efi_esrt_populate() is used to populate the ESRT table.
If one of the FMP protocols malfunctions when calling GetImageInfo(), e.g because the dfu environment variables are not set, we should still add all other FMP protocols to...Function efi_esrt_populate() is used to populate the ESRT table.
If one of the FMP protocols malfunctions when calling GetImageInfo(), e.g because the dfu environment variables are not set, we should still add all other FMP protocols to the ESRT table, e.g the one added in the ESRT unit test.
The sequence of operation in efi_esrt_populate() should be changed:
1. get the number of FMP protocols from LocateHandleBuffer
2. initialize ESRT table
a. allocate an ESRT that is big enough
b. set FwResourceCountMax.
3. iterate over the FMP protocols, for each valid FMP protocol:
a. increase FwResourceCount
b. add the info block.Ilias ApalodimasIlias Apalodimashttps://source.denx.de/u-boot/custodians/u-boot-efi/-/issues/2Integration of UEFI and LMB memory2023-12-04T23:57:25ZHeinrich Schuchardtxypron.glpk@gmx.deIntegration of UEFI and LMB memoryMemory may be reserved via the logical block memory sub-system (LMB) or the UEFI sub-system. As these are not integrated memory conflicts may occur.Memory may be reserved via the logical block memory sub-system (LMB) or the UEFI sub-system. As these are not integrated memory conflicts may occur.https://source.denx.de/u-boot/custodians/u-boot-efi/-/issues/1Concept for handling caches not managed via CP15 on ARM 32bit2022-01-14T20:53:36ZHeinrich Schuchardtxypron.glpk@gmx.deConcept for handling caches not managed via CP15 on ARM 32bitThe UEFI specification requires that data and instruction caches are enabled. But on ARM 32bit architecturally defined caches should not be enabled. These are those caches not managed via CP15. All architectures that reference CONFIG_SYS...The UEFI specification requires that data and instruction caches are enabled. But on ARM 32bit architecturally defined caches should not be enabled. These are those caches not managed via CP15. All architectures that reference CONFIG_SYS_L2CACHE_OFF have architecturally defined caches. There are yet others. E.g.
arch/arm/mach-kirkwood/cache.c:11:void l2_cache_disable()
GRUB version below 2.04 requires all caches to be disabled on ARM 32bit.
Heinrich Schuchardtxypron.glpk@gmx.deHeinrich Schuchardtxypron.glpk@gmx.de