kernel/drivers/firmware/efi/libstub/fdt.c, branch linux-6.18.y

efi: libstub: only free priv.runtime_map when allocated

2024-04-29T15:47:32Z

priv.runtime_map is only allocated when efi_novamap is not set. Otherwise, it is an uninitialized value. In the error path, it is freed unconditionally. Avoid passing an uninitialized value to free_pool. Free priv.runtime_map only when it was allocated. This bug was discovered and resolved using Coverity Static Analysis Security Testing (SAST) by Synopsys, Inc. Fixes: f80d26043af9 ("efi: libstub: avoid efi_get_memory_map() for allocating the virt map") Cc: Signed-off-by: Hagar Hemdan Signed-off-by: Ard Biesheuvel

efi: runtime: Don't assume virtual mappings are missing if VA == PA == 0

2022-10-21T09:09:41Z

The generic EFI stub can be instructed to avoid SetVirtualAddressMap(), and simply run with the firmware's 1:1 mapping. In this case, it populates the virtual address fields of the runtime regions in the memory map with the physical address of each region, so that the mapping code has to be none the wiser. Only if SetVirtualAddressMap() fails, the virtual addresses are wiped and the kernel code knows that the regions cannot be mapped. However, wiping amounts to setting it to zero, and if a runtime region happens to live at physical address 0, its valid 1:1 mapped virtual address could be mistaken for a wiped field, resulting on loss of access to the EFI services at runtime. So let's only assume that VA == 0 means 'no runtime services' if the region in question does not live at PA 0x0. Signed-off-by: Ard Biesheuvel

efi: libstub: remove DT dependency from generic stub

2022-09-27T11:22:47Z

Refactor the generic EFI stub entry code so that all the dependencies on device tree are abstracted and hidden behind a generic efi_boot_kernel() routine that can also be implemented in other ways. This allows users of the generic stub to avoid using FDT for passing information to the core kernel. Signed-off-by: Ard Biesheuvel

efi: libstub: unify initrd loading between architectures

2022-09-27T11:21:36Z

Use a EFI configuration table to pass the initrd to the core kernel, instead of per-arch methods. This cleans up the code considerably, and should make it easier for architectures to get rid of their reliance on DT for doing EFI boot in the future. Signed-off-by: Ard Biesheuvel

efi: libstub: simplify efi_get_memory_map() and struct efi_boot_memmap

2022-09-26T20:30:17Z

Currently, struct efi_boot_memmap is a struct that is passed around between callers of efi_get_memory_map() and the users of the resulting data, and which carries pointers to various variables whose values are provided by the EFI GetMemoryMap() boot service. This is overly complex, and it is much easier to carry these values in the struct itself. So turn the struct into one that carries these data items directly, including a flex array for the variable number of EFI memory descriptors that the boot service may return. Signed-off-by: Ard Biesheuvel

efi: libstub: avoid efi_get_memory_map() for allocating the virt map

2022-09-26T20:29:24Z

The virt map is a set of efi_memory_desc_t descriptors that are passed to SetVirtualAddressMap() to inform the firmware about the desired virtual mapping of the regions marked as EFI_MEMORY_RUNTIME. The only reason we currently call the efi_get_memory_map() helper is that it gives us an allocation that is guaranteed to be of sufficient size. However, efi_get_memory_map() has grown some additional complexity over the years, and today, we're actually better off calling the EFI boot service directly with a zero size, which tells us how much memory should be enough for the virt map. While at it, avoid creating the VA map allocation if we will not be using it anyway, i.e., if efi_novamap is true. Signed-off-by: Ard Biesheuvel

efi: libstub: drop pointless get_memory_map() call

2022-09-20T17:34:22Z

Currently, the non-x86 stub code calls get_memory_map() redundantly, given that the data it returns is never used anywhere. So drop the call. Cc: # v4.14+ Fixes: 24d7c494ce46 ("efi/arm-stub: Round up FDT allocation to mapping size") Signed-off-by: Ard Biesheuvel

efi/libstub: Simplify "Exiting bootservices" message

2021-10-05T11:05:58Z

The message "Exiting boot services and installing virtual address map...\n" is even shown if we have efi=novamap on the command line or the firmware does not provide EFI_RT_SUPPORTED_SET_VIRTUAL_ADDRESS_MAP. To avoid confusion just print "Exiting boot services...\n" Signed-off-by: Heinrich Schuchardt Signed-off-by: Ard Biesheuvel

efi: stub: get rid of efi_get_max_fdt_addr()

2020-12-09T07:37:27Z

Now that ARM started following the example of arm64 and RISC-V, and no longer imposes any restrictions on the placement of the FDT in memory at boot, we no longer need per-arch implementations of efi_get_max_fdt_addr() to factor out the differences. So get rid of it. Signed-off-by: Ard Biesheuvel Reviewed-by: Atish Patra Link: https://lore.kernel.org/r/20201029134901.9773-1-ardb@kernel.org

efi/arm64: libstub: Deal gracefully with EFI_RNG_PROTOCOL failure

2020-09-29T13:41:52Z

Currently, on arm64, we abort on any failure from efi_get_random_bytes() other than EFI_NOT_FOUND when it comes to setting the physical seed for KASLR, but ignore such failures when obtaining the seed for virtual KASLR or for early seeding of the kernel's entropy pool via the config table. This is inconsistent, and may lead to unexpected boot failures. So let's permit any failure for the physical seed, and simply report the error code if it does not equal EFI_NOT_FOUND. Cc: # v5.8+ Reported-by: Heinrich Schuchardt Signed-off-by: Ard Biesheuvel