Re: [PATCH v3 1/5] efi: Always try to allocate heap size of 1.6GB

[Daniel Kiper]

On Fri, Mar 13, 2020 at 12:55:08PM +0000, Leif Lindholm wrote:
> 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.

Leif, thanks a lot for the input.

Patrick, please make Argon2 functionality enabled/disabled by the
./configure. By default it have to be disabled. Additionally, please add
to the grub-dev.texi an explanation what is the impact of enabling Argon2.

However, as Leif said, we can back to the discussion about "something
runtime-controllable, like having modules requesting expansion of
available heap space at load time" after the release.

Daniel