grub-devel
[Top][All Lists]
Advanced

[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
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]