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 <p...@pks.im> > > --- > > 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.
Oops, yeah. I had the intention to revert this back to use (total_pages >>2) but forgot. > 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. Ah, yeah, that makes a lot of sense to me. Thanks for pointing out! > > (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. That sounds like a worthwhile goal to me, agreed. Thanks for your input! Patrick
signature.asc
Description: PGP signature
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel