From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1Vq6kd-0001fs-Ls for mharc-grub-devel@gnu.org; Mon, 09 Dec 2013 14:44:19 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36129) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vq6kU-0001e3-Cb for grub-devel@gnu.org; Mon, 09 Dec 2013 14:44:18 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vq6kL-00007K-D2 for grub-devel@gnu.org; Mon, 09 Dec 2013 14:44:10 -0500 Received: from mail-ee0-x22d.google.com ([2a00:1450:4013:c00::22d]:46221) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vq6kL-000074-2b for grub-devel@gnu.org; Mon, 09 Dec 2013 14:44:01 -0500 Received: by mail-ee0-f45.google.com with SMTP id d49so1779286eek.32 for ; Mon, 09 Dec 2013 11:44:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=rEKUgyS1MLU61s7o8LomhwHJ+8QYnCEt+y5AfAAonkY=; b=D+gEMsH1QA6Y7Xr8MDXuNZur3iguJeMzuI3wPZKASlDZpNyuoDdcyNldr1ZLb9j+Q3 LsYZnQJhXt/ec3SwifXQ1o06GcTyteH3rgKBb4RxK1iVpDychVa5THfUdIp3Pqih+8+z pgkzWhmwUXq5/MC3AJ7SMsYg1cX9tt6EeHtrfdD7h+GbV8Iruj+cUV/eiMzZhRVr3WKl X9bGcOe/AsmYqHQJgUavw5vkeDmOiev49Iu5cny192S8fYB51WGyKWQ+7olIql63n5XV 5fC55gNGqdb1NdUVCY/Nt1xqlP2Tgpf6/8rBoUvr+HVnHSx2npdkCJLF7eaonWELWhRT ynPQ== X-Received: by 10.14.114.71 with SMTP id b47mr14307496eeh.26.1386618240214; Mon, 09 Dec 2013 11:44:00 -0800 (PST) Received: from [192.168.1.16] (85-188.196-178.cust.bluewin.ch. [178.196.188.85]) by mx.google.com with ESMTPSA id 44sm32433680eek.5.2013.12.09.11.43.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Dec 2013 11:43:58 -0800 (PST) Message-ID: <52A61D7D.60109@gmail.com> Date: Mon, 09 Dec 2013 20:43:57 +0100 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10 MIME-Version: 1.0 To: The development of GNU GRUB Subject: Re: kern/efi/mm.c - MAX_USABLE_ADDRESS References: <20131209173036.GK24997@rocoto.smurfnet.nu> <52A61537.7030407@gmail.com> In-Reply-To: <52A61537.7030407@gmail.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="DssaEG92rmEBpmXtJfLsKQg2ong9TXdSb" X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4013:c00::22d X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 19:44:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DssaEG92rmEBpmXtJfLsKQg2ong9TXdSb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 09.12.2013 20:08, Vladimir '=CF=86-coder/phcoder' Serbinenko wrote: > On 09.12.2013 18:30, Leif Lindholm wrote: >> Hi, >> >> The EFI memory management code contains a hard-wired limit restricting= >> physical (and virtual, all 1:1 mapped in UEFI) addresses to 32-bit. >> While this may be the right thing to do on x86, and hasn't caused me >> any issues on 32-bit ARM, I have received reports of at least two >> upcoming 64-bit ARM platforms with no RAM in the lower 4GB of physical= >> address space. >> >> A simple fix would be to just stack the ifdefs, but a better one might= >> be to move the define to one of (which is currently= >> a dummy for all platforms, simply including ) or types.h= =2E >> > cpu/efi/memory.h is a possibility. cpu/types.h isn't because it's, at > least partially, EFI limitation (due to EFI bugs), not CPU. Real > restrictions is a mix of unrelated restriction but it seem to align wel= l > with CPU. > Increasing it beyond 0xffffffff will need chacking that efi/mm.c can > handle it without overflow. > The limits are: > -0xffffffff on 32-bit platforms due to address space size (i386, arm) > -0x7fffffff when x86_64 compiled without -mcmodel=3Dlarge due to compil= er > assumptions > -0xffffffff on x86_64 because some EFI implementations don't map memory= > above 4G contrary to spec. > - On ia64 it's probably unlimited but I didn't test and there is always= > a danger of EFI bugs similar to x86_64 one, so better to be conservativ= e > about it > - arm64. You're the expert. If you want to increase it to 0xffffffffffffffff you'll need patch at bottom of this mail. All other uses of MAX_USABLE_ADDRESS seem to be fine. With this patch we would lose the last usable page but it's just 4K and this page is dangerous for overflows anyway so better to avoid. I'd suggest using something lower (perhaps 1M lower) to avoid potential bugs in EFI. diff --git a/grub-core/kern/efi/mm.c b/grub-core/kern/efi/mm.c index 6e9dace..2becb7b 100644 --- a/grub-core/kern/efi/mm.c +++ b/grub-core/kern/efi/mm.c @@ -30,6 +30,7 @@ ((grub_efi_memory_descriptor_t *) ((char *) (desc) + (size))) #define BYTES_TO_PAGES(bytes) (((bytes) + 0xfff) >> 12) +#define BYTES_TO_PAGES_DOWN(bytes) ((bytes) >> 12) #define PAGES_TO_BYTES(pages) ((pages) << 12) #if defined (__code_model_large__) || !defined (__x86_64__) @@ -343,9 +344,9 @@ filter_memory_map (grub_efi_memory_descriptor_t *memory_map, #if 1 if (BYTES_TO_PAGES (filtered_desc->physical_start) + filtered_desc->num_pages - > BYTES_TO_PAGES (MAX_USABLE_ADDRESS+1LL)) + > BYTES_TO_PAGES_DOWN (MAX_USABLE_ADDRESS)) filtered_desc->num_pages - =3D (BYTES_TO_PAGES (MAX_USABLE_ADDRESS+1LL) + =3D (BYTES_TO_PAGES_DOWN (MAX_USABLE_ADDRESS) - BYTES_TO_PAGES (filtered_desc->physical_start)); #endif --DssaEG92rmEBpmXtJfLsKQg2ong9TXdSb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iF4EAREKAAYFAlKmHX0ACgkQmBXlbbo5nOsTAAEAhj1CBsPZnsleckIHYIejddaY 9OXm7HhQlSuj6onLbv8BAK72NVqGSfiQ68A/BLravCUgT9SZu8FtOr/ho54zkfIJ =dRcp -----END PGP SIGNATURE----- --DssaEG92rmEBpmXtJfLsKQg2ong9TXdSb--