[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v3 1/5] efi: Always try to allocate heap size of 1.6GB
From: |
Leif Lindholm |
Subject: |
Re: [PATCH v3 1/5] efi: Always try to allocate heap size of 1.6GB |
Date: |
Fri, 13 Mar 2020 12:55:08 +0000 |
User-agent: |
Mutt/1.10.1 (2018-07-13) |
On Tue, Mar 10, 2020 at 19:58:28 +0100, Patrick Steinhardt wrote:
> By default, GRUB will allocate a quarter of the pages it got available
> in the EFI subsystem. On many current systems, this will amount to
> roughly 800MB of RAM assuming an address space of 32 bits. This is
> plenty for most use cases, but it doesn't suffice when using full disk
> encryption with a key derival function based on Argon2.
>
> Besides the usual iteration count known from PBKDF2, Argon2 introduces
> two additional parameters "memory" and "parallelism". While the latter
> doesn't really matter to us, the memory parameter is quite interesting.
> If encrypting a partition with LUKS2 using Argon2 as KDF, then
> cryptsetup will default to a memory parameter of 1GB. Meaning we need to
> allocate a buffer of 1GB in size in order to be able to derive the key,
> which definitely won't squeeze into the limit of 800MB.
>
> To prepare for Argon2, this commit reworks the memory allocation
> algorithm for EFI platforms. Instead of trying to allocate a quarter of
> memory available, let's instead introduce a constant target amount of
> bytes that we try to allocate. The target is set to the previous value
> of MAX_HEAP_SIZE, which amounts to 1.6GB and thus sufficiently high to
> accomodate for both Argon2 as well as other functionality. The value is
> then clamped to at most half of available memory but at least 100MB.
Thanks for this, but it doesn't fully resolve my concerns.
Comments below.
> Signed-off-by: Patrick Steinhardt <address@hidden>
> ---
> grub-core/kern/efi/mm.c | 21 +++++++++++----------
> 1 file changed, 11 insertions(+), 10 deletions(-)
>
> diff --git a/grub-core/kern/efi/mm.c b/grub-core/kern/efi/mm.c
> index b02fab1b1..367a726c6 100644
> --- a/grub-core/kern/efi/mm.c
> +++ b/grub-core/kern/efi/mm.c
> @@ -39,8 +39,8 @@
> #define MEMORY_MAP_SIZE 0x3000
>
> /* The minimum and maximum heap size for GRUB itself. */
> -#define MIN_HEAP_SIZE 0x100000
> -#define MAX_HEAP_SIZE (1600 * 0x100000)
> +#define MIN_HEAP_PAGES BYTES_TO_PAGES( 0x100000)
> +#define TARGET_HEAP_PAGES BYTES_TO_PAGES(1600 * 0x100000)
>
> static void *finish_mmap_buf = 0;
> static grub_efi_uintn_t finish_mmap_size = 0;
> @@ -559,7 +559,7 @@ grub_efi_mm_init (void)
> grub_efi_uintn_t map_size;
> grub_efi_uintn_t desc_size;
> grub_efi_uint64_t total_pages;
> - grub_efi_uint64_t required_pages;
> + grub_efi_uint64_t target_heap_pages;
> int mm_status;
>
> /* Prepare a memory region to store two memory maps. */
> @@ -599,14 +599,15 @@ 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 TARGET_HEAP_PAGES pages. If that exceeds half of
> meory
> + * available, clamp it, but request at least MIN_HEAP_PAGES. */
> total_pages = get_total_pages (filtered_memory_map, desc_size,
> filtered_memory_map_end);
> - required_pages = (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))
> - required_pages = BYTES_TO_PAGES (MAX_HEAP_SIZE);
> + target_heap_pages = TARGET_HEAP_PAGES;
> + if (target_heap_pages > (total_pages / 2))
> + target_heap_pages = total_pages / 2;
If we can't get the amount we *need* for the new functionality, we
*still* go ahead and unconditionally reserve 50% of RAM?
I think a change this substantial, that is likely to break some
existing installations, needs to be conditionalised.
My idea was something along the lines of (pseudocode - coding style,
macro use and naming may or may not be suitable):
target_heap_pages = MIN_HEAP_PAGES;
#ifdef GRUB_LUKS2_ARGON2_ENABLED
target_heap_pages += GRUB_LUKS2_ARGON2_PAGES;
#endif
and then
if (target_heap_pages > (total_pages >> 2)
target_heap_pages = total_pages >> 2;
and then possibly
if (target_heap_pages > MAX_HEAP_PAGES)
target_heap_pages = MAX_HEAP_PAGES;
This for something simplistic with low risk, as we're so near release.
(Yes, this may mean we want to increase MIN_HEAP_PAGES, or add
some other intermediate #define as well.)
After 2.06 release I think I would like to look into the possibility
of something runtime-controllable, like having modules requesting
expansion of available heap space at load time.
Regards,
Leif
> + if (target_heap_pages < MIN_HEAP_PAGES)
> + target_heap_pages = MIN_HEAP_PAGES;
>
> /* Sort the filtered descriptors, so that GRUB can allocate pages
> from smaller regions. */
> @@ -614,7 +615,7 @@ grub_efi_mm_init (void)
>
> /* Allocate memory regions for GRUB's memory management. */
> add_memory_regions (filtered_memory_map, desc_size,
> - filtered_memory_map_end, required_pages);
> + filtered_memory_map_end, target_heap_pages);
>
> #if 0
> /* For debug. */
> --
> 2.25.1
>
- [PATCH v3 0/5] Support Argon2 KDF in LUKS2, Patrick Steinhardt, 2020/03/10
- [PATCH v3 2/5] types.h: add UINT-related macros needed for Argon2, Patrick Steinhardt, 2020/03/10
- [PATCH v3 4/5] luks2: Discern Argon2i and Argon2id, Patrick Steinhardt, 2020/03/10
- [PATCH v3 5/5] luks2: Support key derival via Argon2, Patrick Steinhardt, 2020/03/10
- [PATCH v3 3/5] argon2: Import Argon2 from cryptsetup, Patrick Steinhardt, 2020/03/10