grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: kern/efi/mm.c - MAX_USABLE_ADDRESS


From: Vladimir 'φ-coder/phcoder' Serbinenko
Subject: Re: kern/efi/mm.c - MAX_USABLE_ADDRESS
Date: Mon, 09 Dec 2013 20:43:57 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10

On 09.12.2013 20:08, Vladimir 'φ-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 <cpu/efi/memory.h> (which is currently
>> a dummy for all platforms, simply including <efi/memory.h>) or types.h.
>>
> 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 well
> 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=large due to compiler
> 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 conservative
> 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
-             = (BYTES_TO_PAGES (MAX_USABLE_ADDRESS+1LL)
+             = (BYTES_TO_PAGES_DOWN (MAX_USABLE_ADDRESS)
                 - BYTES_TO_PAGES (filtered_desc->physical_start));
 #endif



Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]