You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
74 lines
3.5 KiB
74 lines
3.5 KiB
From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001 |
|
From: Peter Jones <pjones@redhat.com> |
|
Date: Fri, 29 Jul 2022 15:57:57 -0400 |
|
Subject: [PATCH] efi: make the default arena most of ram |
|
|
|
Currently when populating the initial memory arena on EFI systems, we |
|
count the available regions below GRUB_EFI_MAX_ALLOCATION_ADDRESS from |
|
the EFI memory map and then allocates one quarter of that for our arena. |
|
|
|
Because many systems come up without IOMMUs, we currently set |
|
GRUB_EFI_MAX_ALLOCATION_ADDRESS to 0x7fffffff, i.e. all addresses |
|
allocated must be below 2G[0]. Due to firmware and other |
|
considerations, this makes the most memory we can possibly have in our |
|
arena 512M. |
|
|
|
Because our EFI loader doesn't get kernel and initrd memory from grub's |
|
allocator, but rather reserves it directly from UEFI and then simply |
|
marks those as allocated if they're within grub's arena, it was |
|
historically possible to have initrds that are larger than 512M, because |
|
we could use any memory region below 4G, without concern for grub's |
|
choice of arena size. |
|
|
|
Unfortunately, when we switched to using the "verifiers" API (and thus |
|
the file_filter_t API) to do measurement of kernel and initrd, this |
|
introduced a pattern that allocates the entire file when we call |
|
grub_file_open(), and buffers it to pass to the filter. This results in |
|
needing to have enough space for the initramfs in the grub arena. |
|
|
|
This is bad. |
|
|
|
Since it's unlikely you're going to do anything *other* than loading a |
|
kernel and initramfs that takes much of the available free memory from |
|
UEFI, this patch introduces a workaround by changing the amount we give |
|
to the arena be three quarters of the available memory, rather than one |
|
quarter, thus changing our theoretical initrd limit to 1.5G. In |
|
practice, it may still be smaller than that depending on allocation |
|
fragmentation, but generally it will be most of it. |
|
|
|
Note that this doesn't fix the underlying flaw, which is that there is |
|
no safe way to do the validation correctly using the "verifiers" system |
|
with the current file API without buffering the whole file before |
|
grub_file_read() is ever called, and thus you can't set an allocation |
|
policy for the initial buffer of the file at all, so unless we raise the |
|
allocation limit to >4G, it can't be allocated in the big region. |
|
|
|
[0] I'm not sure there was a good reason not to pick 4G, but even if we |
|
had, at least one common firmware routes the first 2G of physical |
|
RAM to 0x0, and any additional memory starting at 0x100000000. |
|
|
|
Related: rhbz#2112134 |
|
|
|
Signed-off-by: Peter Jones <pjones@redhat.com> |
|
(cherry picked from commit 005a0aaaad2a00a1fa1e60d94cc4fd5407c22e7d) |
|
--- |
|
grub-core/kern/efi/mm.c | 4 ++-- |
|
1 file changed, 2 insertions(+), 2 deletions(-) |
|
|
|
diff --git a/grub-core/kern/efi/mm.c b/grub-core/kern/efi/mm.c |
|
index 88364d764c..0288eab361 100644 |
|
--- a/grub-core/kern/efi/mm.c |
|
+++ b/grub-core/kern/efi/mm.c |
|
@@ -738,10 +738,10 @@ grub_efi_mm_init (void) |
|
filtered_memory_map_end = filter_memory_map (memory_map, filtered_memory_map, |
|
desc_size, memory_map_end); |
|
|
|
- /* By default, request a quarter of the available memory. */ |
|
+ /* By default, request three quarters of the available memory. */ |
|
total_pages = get_total_pages (filtered_memory_map, desc_size, |
|
filtered_memory_map_end); |
|
- required_pages = (total_pages >> 2); |
|
+ required_pages = (total_pages >> 1) + (total_pages >> 2); |
|
if (required_pages < BYTES_TO_PAGES (MIN_HEAP_SIZE)) |
|
required_pages = BYTES_TO_PAGES (MIN_HEAP_SIZE); |
|
else if (required_pages > BYTES_TO_PAGES (MAX_HEAP_SIZE))
|
|
|