kernel/drivers/firmware/efi/libstub/randomalloc.c, branch linux-6.9.y

efi/libstub: Cast away type warning in use of max()

2024-03-28T15:18:57Z

Avoid a type mismatch warning in max() by switching to max_t() and providing the type explicitly. Fixes: 3cb4a4827596abc82e ("efi/libstub: fix efi_random_alloc() ...") Signed-off-by: Ard Biesheuvel

efi/libstub: fix efi_random_alloc() to allocate memory at alloc_min or higher address

2024-03-22T13:08:42Z

Following warning is sometimes observed while booting my servers: [ 3.594838] DMA: preallocated 4096 KiB GFP_KERNEL pool for atomic allocations [ 3.602918] swapper/0: page allocation failure: order:10, mode:0xcc1(GFP_KERNEL|GFP_DMA), nodemask=(null),cpuset=/,mems_allowed=0-1 ... [ 3.851862] DMA: preallocated 1024 KiB GFP_KERNEL|GFP_DMA pool for atomic allocation If 'nokaslr' boot option is set, the warning always happens. On x86, ZONE_DMA is small zone at the first 16MB of physical address space. When this problem happens, most of that space seems to be used by decompressed kernel. Thereby, there is not enough space at DMA_ZONE to meet the request of DMA pool allocation. The commit 2f77465b05b1 ("x86/efistub: Avoid placing the kernel below LOAD_PHYSICAL_ADDR") tried to fix this problem by introducing lower bound of allocation. But the fix is not complete. efi_random_alloc() allocates pages by following steps. 1. Count total available slots ('total_slots') 2. Select a slot ('target_slot') to allocate randomly 3. Calculate a starting address ('target') to be included target_slot 4. Allocate pages, which starting address is 'target' In step 1, 'alloc_min' is used to offset the starting address of memory chunk. But in step 3 'alloc_min' is not considered at all. As the result, 'target' can be miscalculated and become lower than 'alloc_min'. When KASLR is disabled, 'target_slot' is always 0 and the problem happens everytime if the EFI memory map of the system meets the condition. Fix this problem by calculating 'target' considering 'alloc_min'. Cc: linux-efi@vger.kernel.org Cc: Tom Englund Cc: linux-kernel@vger.kernel.org Fixes: 2f77465b05b1 ("x86/efistub: Avoid placing the kernel below LOAD_PHYSICAL_ADDR") Signed-off-by: Kazuma Kondo Signed-off-by: Ard Biesheuvel

x86/efistub: Avoid placing the kernel below LOAD_PHYSICAL_ADDR

2024-01-30T20:44:21Z

The EFI stub's kernel placement logic randomizes the physical placement of the kernel by taking all available memory into account, and picking a region at random, based on a random seed. When KASLR is disabled, this seed is set to 0x0, and this results in the lowest available region of memory to be selected for loading the kernel, even if this is below LOAD_PHYSICAL_ADDR. Some of this memory is typically reserved for the GFP_DMA region, to accommodate masters that can only access the first 16 MiB of system memory. Even if such devices are rare these days, we may still end up with a warning in the kernel log, as reported by Tom: swapper/0: page allocation failure: order:10, mode:0xcc1(GFP_KERNEL|GFP_DMA), nodemask=(null),cpuset=/,mems_allowed=0 Fix this by tweaking the random allocation logic to accept a low bound on the placement, and set it to LOAD_PHYSICAL_ADDR. Fixes: a1b87d54f4e4 ("x86/efistub: Avoid legacy decompressor when doing EFI boot") Reported-by: Tom Englund Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218404 Signed-off-by: Ard Biesheuvel

efi/libstub: Add limit argument to efi_random_alloc()

2023-08-07T19:01:46Z

x86 will need to limit the kernel memory allocation to the lowest 512 MiB of memory, to match the behavior of the existing bare metal KASLR physical randomization logic. So in preparation for that, add a limit parameter to efi_random_alloc() and wire it up. Signed-off-by: Ard Biesheuvel Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/r/20230807162720.545787-22-ardb@kernel.org

efi/libstub: randomalloc: Return EFI_OUT_OF_RESOURCES on failure

2023-03-23T14:15:45Z

The logic in efi_random_alloc() will iterate over the memory map twice, once to count the number of candidate slots, and another time to locate the chosen slot after randomization. If there is insufficient memory to do the allocation, the second loop will run to completion without actually having located a slot, but we currently return EFI_SUCCESS in this case, as we fail to initialize status to the appropriate error value of EFI_OUT_OF_RESOURCES. Signed-off-by: Ard Biesheuvel

arm64: efi: Limit allocations to 48-bit addressable physical region

2022-12-07T18:50:44Z

The UEFI spec does not mention or reason about the configured size of the virtual address space at all, but it does mention that all memory should be identity mapped using a page size of 4 KiB. This means that a LPA2 capable system that has any system memory outside of the 48-bit addressable physical range and follows the spec to the letter may serve page allocation requests from regions of memory that the kernel cannot access unless it was built with LPA2 support and enables it at runtime. So let's ensure that all page allocations are limited to the 48-bit range. Signed-off-by: Ard Biesheuvel

efi: libstub: use EFI_LOADER_CODE region when moving the kernel in memory

2022-11-18T08:14:08Z

The EFI spec is not very clear about which permissions are being given when allocating pages of a certain type. However, it is quite obvious that EFI_LOADER_CODE is more likely to permit execution than EFI_LOADER_DATA, which becomes relevant once we permit booting the kernel proper with the firmware's 1:1 mapping still active. Ostensibly, recent systems such as the Surface Pro X grant executable permissions to EFI_LOADER_CODE regions but not EFI_LOADER_DATA regions. Signed-off-by: Ard Biesheuvel

efi: libstub: install boot-time memory map as config table

2022-09-27T11:22:49Z

Expose the EFI boot time memory map to the kernel via a configuration table. This is arch agnostic and enables future changes that remove the dependency on DT on architectures that don't otherwise rely on it. 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: stub: prefer mirrored memory for randomized allocations

2022-05-06T07:51:22Z

If the system exposes memory regions with the EFI_MORE_RELIABLE attribute, it is implied that it is intended to be used for allocations that are relatively important, such as the kernel's static image. Since efi_random_alloc() is mostly (only) used for allocating space for the kernel image, let's update it to take this into account, and disregard all memory without the EFI_MORE_RELIABLE attribute if there is sufficient memory available that does have this attribute. Note that this change only affects booting with randomization enabled. In other cases, the EFI stub runs the kernel image in place unless its placement is unsuitable for some reason (i.e., misaligned, or its BSS overlaps with another allocation), and it is left to the bootloader to ensure that the kernel was loaded into EFI_MORE_RELIABLE memory if this is desired. Signed-off-by: Ard Biesheuvel Reviewed-by: Kefeng Wang