From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1jDQIM-0001WF-8d for mharc-grub-devel@gnu.org; Sun, 15 Mar 2020 06:14:58 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:46235) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jDQIJ-0001W9-8q for grub-devel@gnu.org; Sun, 15 Mar 2020 06:14:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jDQIH-0004aJ-Ms for grub-devel@gnu.org; Sun, 15 Mar 2020 06:14:55 -0400 Received: from wout2-smtp.messagingengine.com ([64.147.123.25]:46401) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1jDQIG-0004J2-P2 for grub-devel@gnu.org; Sun, 15 Mar 2020 06:14:53 -0400 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id DE76651A; Sun, 15 Mar 2020 06:14:48 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Sun, 15 Mar 2020 06:14:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pks.im; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm3; bh=2eTEFmoOKEI3LppoxnSb3kyK6Fd 19h8ker0l0x04Q4k=; b=Sg6LxmsHJZ+Ac+ywiR9SZYXDQiYSo9w8SzOHV/VOW1F EKZ7JTet/0mSClJIY3aZxPQbThKvns0G0otxWSYcEJ0BubTX8Qi7KLHM+rKMZC04 ugLldmIs88nQj6jC19u4oEG4QeUFroaCX+O3yOzzTwX+pW7yDTGdH4rKct+ZL1zu q4F0GDOxDUehIcmUB/CCVpq8fZJm5vjbXQoifudpVkz3Q4MptjB/CMkRc4CNIVap JSSZHsF946Xk7L6XEDvz2QjEV2/FrjT7rsL0G4Abj/mIxOrJ0EkoL6gdgTQhjpkD XYB4+ry9+IZDXistrJiKFEUaxRjlQdQpKb6Qz2Xge5g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=2eTEFm oOKEI3LppoxnSb3kyK6Fd19h8ker0l0x04Q4k=; b=W5Y1nCQCdTwMBPSjaa+M4P ryyh3Qj+o0OD317HfL++pAB495ivVUHrmVlw+0Vv8NpEgVg8B5VgUaU0x0AFSE3l 3yCSO7r+4xG4OMLRhAD5Vy1xWwZNVZIo0sGvXcvYpAOoqGUVVnp94PImKZgVs50x t+c/bgpg81hOSj7Y4Sanhk9QfoM0UExRNf86hFPne2Ur5OwXaGH63BRNJQXu1/cm HQHTa/pZ6KlMT2iVOuuG1beUUls0Jkmi6IP/d68HYIiQYoNC3e11THTL3T9Gbb+5 xOmLHNhfjUfiTav8du/A5X3jTot6pFUm0vxFsZG8NbBwZYI1xCN7VVaovG4Syzxg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudeftddgudeffecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvuffkfhggtggujgesghdtreertddtvdenucfhrhhomheprfgrthhr ihgtkhcuufhtvghinhhhrghrughtuceophhssehpkhhsrdhimheqnecukfhppeejkedrhe egrddukeehrdduieenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhl fhhrohhmpehpshesphhkshdrihhm X-ME-Proxy: Received: from vm-mail (x4e36b910.dyn.telefonica.de [78.54.185.16]) by mail.messagingengine.com (Postfix) with ESMTPA id BB66730614FA; Sun, 15 Mar 2020 06:14:46 -0400 (EDT) Received: from localhost (ncase [10.192.0.11]) by vm-mail (OpenSMTPD) with ESMTPSA id 9187d3d8 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Sun, 15 Mar 2020 10:14:40 +0000 (UTC) Date: Sun, 15 Mar 2020 11:14:44 +0100 From: Patrick Steinhardt To: Leif Lindholm Cc: grub-devel@gnu.org, Daniel Kiper , 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: <20200315101444.GA13363@ncase> References: <20200313125508.GO23627@bivouac.eciton.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="jRHKVT23PllUwdXP" Content-Disposition: inline In-Reply-To: <20200313125508.GO23627@bivouac.eciton.net> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 64.147.123.25 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: Sun, 15 Mar 2020 10:14:57 -0000 --jRHKVT23PllUwdXP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. > >=20 > > 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. > >=20 > > 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. >=20 > Thanks for this, but it doesn't fully resolve my concerns. > Comments below. >=20 > > Signed-off-by: Patrick Steinhardt > > --- > > grub-core/kern/efi/mm.c | 21 +++++++++++---------- > > 1 file changed, 11 insertions(+), 10 deletions(-) > >=20 > > 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 > > =20 > > /* 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) > > =20 > > static void *finish_mmap_buf =3D 0; > > static grub_efi_uintn_t finish_mmap_size =3D 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; > > =20 > > /* Prepare a memory region to store two memory maps. */ > > @@ -599,14 +599,15 @@ grub_efi_mm_init (void) > > filtered_memory_map_end =3D filter_memory_map (memory_map, filtered_= memory_map, > > desc_size, memory_map_end); > > =20 > > - /* 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 =3D get_total_pages (filtered_memory_map, desc_size, > > filtered_memory_map_end); > > - required_pages =3D (total_pages >> 2); > > - if (required_pages < BYTES_TO_PAGES (MIN_HEAP_SIZE)) > > - required_pages =3D BYTES_TO_PAGES (MIN_HEAP_SIZE); > > - else if (required_pages > BYTES_TO_PAGES (MAX_HEAP_SIZE)) > > - required_pages =3D BYTES_TO_PAGES (MAX_HEAP_SIZE); > > + target_heap_pages =3D TARGET_HEAP_PAGES; > > + if (target_heap_pages > (total_pages / 2)) > > + target_heap_pages =3D total_pages / 2; >=20 > 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): >=20 > target_heap_pages =3D MIN_HEAP_PAGES; > #ifdef GRUB_LUKS2_ARGON2_ENABLED > target_heap_pages +=3D GRUB_LUKS2_ARGON2_PAGES; > #endif >=20 > and then >=20 > if (target_heap_pages > (total_pages >> 2) > target_heap_pages =3D total_pages >> 2; >=20 > and then possibly >=20 > if (target_heap_pages > MAX_HEAP_PAGES) > target_heap_pages =3D MAX_HEAP_PAGES; >=20 > 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! >=20 > (Yes, this may mean we want to increase MIN_HEAP_PAGES, or add > some other intermediate #define as well.) >=20 > 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 --jRHKVT23PllUwdXP Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEF9hrgiFbCdvenl/rVbJhu7ckPpQFAl5uABEACgkQVbJhu7ck PpRq/RAArtRG3eZFBTOT1MNCr02W2ztjxu+yyWVFeKoT1PHfPCDFEczzGMk8myb5 KWwVkDcKA4Snzfr50NO2RrcXVSjZJpKkUmPXfTGnSSIbCnYYpMiC1JofOxoYrFZc 2MGIHY6s5CMpWy4NM1qSWRmAPsoFL4j45Awt8gipWWNEvyhKu9zWb2frU1YrfIrf p+j+VMwiyjSd5nafkq7nHBCcEA+qjnMt1RDvqKqVl0w9TBZEeW8cDR3qpM+Vi/qJ YZcVDY40MGlS2posfsv8WxlfD7hK9J2RaR7xO+KlGLAAXRSwerLRUwTSEUiIiWhf TQy32gfWFi3zA4HXBhbauFoU42xGKKfLcccnOvcUbsOLwxA+IAWDL2h184rLqS/k rg/oPcyuDTf+uiKhNs0RHouQfg0pwXiakf4EldsABT0VFUVXfwlNj6DyzBzGSJ9P TIrpJaNaASw0q+a2JPo/t805Y3FqO7wxTgwjRIQhc+8fFNXgzex+0SImW2L7yDWI mJYpV1xBYDlsdNmAyarM9PFIUTsmdNxt9zgLFaBddLzdlifO/U3KkNhPkOWLdg3p xzx6luAc3cW8uQi6KOxBNaRY6iExhyA4hjt8gr2lg1k5FJDqF7BqwZQHHXUaIslz cvypvhtpkCUqxVc/jmGxR1H6AKBBFNlqFUL1ApSvhMoREBLG4vs= =8rU8 -----END PGP SIGNATURE----- --jRHKVT23PllUwdXP--