From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1jCkr2-00058G-12 for mharc-grub-devel@gnu.org; Fri, 13 Mar 2020 10:00:00 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:41728) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jCkqz-00055Z-Es for grub-devel@gnu.org; Fri, 13 Mar 2020 09:59:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jCkqy-0006XX-3m for grub-devel@gnu.org; Fri, 13 Mar 2020 09:59:57 -0400 Received: from dibed.net-space.pl ([84.10.22.86]:35020) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_3DES_EDE_CBC_SHA1:24) (Exim 4.71) (envelope-from ) id 1jCkqx-0006UD-Na for grub-devel@gnu.org; Fri, 13 Mar 2020 09:59:56 -0400 Received: from router-fw.i.net-space.pl ([192.168.52.1]:46228 "EHLO tomti.i.net-space.pl") by router-fw-old.i.net-space.pl with ESMTP id S168261AbgCMN7s (ORCPT ); Fri, 13 Mar 2020 14:59:48 +0100 X-Comment: RFC 2476 MSA function at dibed.net-space.pl logged sender identity as: dkiper Date: Fri, 13 Mar 2020 14:59:46 +0100 From: Daniel Kiper To: Leif Lindholm Cc: Patrick Steinhardt , grub-devel@gnu.org, agraf@csgraf.de, pjones@redhat.com, mjg59@google.com, phcoder@gmail.com, Milan Broz Subject: Re: [PATCH v3 1/5] efi: Always try to allocate heap size of 1.6GB Message-ID: <20200313135946.cwfyzbmjkw2yy5q4@tomti.i.net-space.pl> References: <20200313125508.GO23627@bivouac.eciton.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200313125508.GO23627@bivouac.eciton.net> User-Agent: NeoMutt/20170113 (1.7.2) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 84.10.22.86 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2020 13:59:59 -0000 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 > > --- > > 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