| Message ID | 20181207112304.19765-4-ard.biesheuvel@linaro.org |
|---|---|
| State | Superseded |
| Headers | show |
| Series | introduce MAX_ALLOC_ADDRESS to limit boot time allocations | expand |
Hi Ard,
I think MAX_ALLOC_ADDRESS will affect other archs besides ARM. Please do enough
test for them (IA32/X64 for my concern).
In addition, do you think it's safer to replace MAX_ADDRESS with MAX_ALLOC_ADDRESS
in MemoryAllocationLib like following situation?
(MdeModulePkg\Library\DxeCoreMemoryAllocationLib\MemoryAllocationLib.c)
VOID *
InternalAllocateCopyPool (
IN EFI_MEMORY_TYPE PoolType,
IN UINTN AllocationSize,
IN CONST VOID *Buffer
)
{
VOID *Memory;
ASSERT (Buffer != NULL);
ASSERT (AllocationSize <= (MAX_ADDRESS - (UINTN) Buffer + 1));
...
}
Regards,
Jian
> -----Original Message-----
> From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
> Sent: Friday, December 07, 2018 7:23 PM
> To: edk2-devel@lists.01.org
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>; Kinney, Michael D
> <michael.d.kinney@intel.com>; Gao, Liming <liming.gao@intel.com>; Wang,
> Jian J <jian.j.wang@intel.com>; Wu, Hao A <hao.a.wu@intel.com>; Leif
> Lindholm <leif.lindholm@linaro.org>; Laszlo Ersek <lersek@redhat.com>; Eric
> Auger <eric.auger@redhat.com>; Andrew Jones <drjones@redhat.com>;
> Philippe Mathieu-Daude <philmd@redhat.com>
> Subject: [RFC PATCH 3/7] MdeModulePkg/Dxe/Page: take
> MAX_ALLOC_ADDRESS into account
>
> Take MAX_ALLOC_ADDRESS into account in the implementation of the
> page allocation routines, so that they will only return memory
> that is addressable by the CPU at boot time, even if more memory
> is available in the GCD memory map.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> MdeModulePkg/Core/Dxe/Mem/Page.c | 52 ++++++++++----------
> 1 file changed, 26 insertions(+), 26 deletions(-)
>
> diff --git a/MdeModulePkg/Core/Dxe/Mem/Page.c
> b/MdeModulePkg/Core/Dxe/Mem/Page.c
> index 961c5b833546..5ad8e1171ef7 100644
> --- a/MdeModulePkg/Core/Dxe/Mem/Page.c
> +++ b/MdeModulePkg/Core/Dxe/Mem/Page.c
> @@ -52,26 +52,26 @@ LIST_ENTRY mFreeMemoryMapEntryList =
> INITIALIZE_LIST_HEAD_VARIABLE (mFreeMemor
> BOOLEAN mMemoryTypeInformationInitialized = FALSE;
>
> EFI_MEMORY_TYPE_STATISTICS mMemoryTypeStatistics[EfiMaxMemoryType +
> 1] = {
> - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE, FALSE }, //
> EfiReservedMemoryType
> - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, //
> EfiLoaderCode
> - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, //
> EfiLoaderData
> - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, //
> EfiBootServicesCode
> - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, //
> EfiBootServicesData
> - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE, TRUE }, //
> EfiRuntimeServicesCode
> - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE, TRUE }, //
> EfiRuntimeServicesData
> - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, //
> EfiConventionalMemory
> - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, //
> EfiUnusableMemory
> - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE, FALSE }, //
> EfiACPIReclaimMemory
> - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE, FALSE }, //
> EfiACPIMemoryNVS
> - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, //
> EfiMemoryMappedIO
> - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, //
> EfiMemoryMappedIOPortSpace
> - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE, TRUE }, // EfiPalCode
> - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, //
> EfiPersistentMemory
> - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE } //
> EfiMaxMemoryType
> + { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE, FALSE }, //
> EfiReservedMemoryType
> + { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, //
> EfiLoaderCode
> + { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, //
> EfiLoaderData
> + { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, //
> EfiBootServicesCode
> + { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, //
> EfiBootServicesData
> + { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE, TRUE }, //
> EfiRuntimeServicesCode
> + { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE, TRUE }, //
> EfiRuntimeServicesData
> + { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, //
> EfiConventionalMemory
> + { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, //
> EfiUnusableMemory
> + { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE, FALSE }, //
> EfiACPIReclaimMemory
> + { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE, FALSE }, //
> EfiACPIMemoryNVS
> + { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, //
> EfiMemoryMappedIO
> + { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, //
> EfiMemoryMappedIOPortSpace
> + { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE, TRUE }, //
> EfiPalCode
> + { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, //
> EfiPersistentMemory
> + { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE } //
> EfiMaxMemoryType
> };
>
> -EFI_PHYSICAL_ADDRESS mDefaultMaximumAddress = MAX_ADDRESS;
> -EFI_PHYSICAL_ADDRESS mDefaultBaseAddress = MAX_ADDRESS;
> +EFI_PHYSICAL_ADDRESS mDefaultMaximumAddress = MAX_ALLOC_ADDRESS;
> +EFI_PHYSICAL_ADDRESS mDefaultBaseAddress = MAX_ALLOC_ADDRESS;
>
> EFI_MEMORY_TYPE_INFORMATION
> gMemoryTypeInformation[EfiMaxMemoryType + 1] = {
> { EfiReservedMemoryType, 0 },
> @@ -419,7 +419,7 @@ PromoteMemoryResource (
> Entry = CR (Link, EFI_GCD_MAP_ENTRY, Link, EFI_GCD_MAP_SIGNATURE);
>
> if (Entry->GcdMemoryType == EfiGcdMemoryTypeReserved &&
> - Entry->EndAddress < MAX_ADDRESS &&
> + Entry->EndAddress < MAX_ALLOC_ADDRESS &&
> (Entry->Capabilities & (EFI_MEMORY_PRESENT |
> EFI_MEMORY_INITIALIZED | EFI_MEMORY_TESTED)) ==
> (EFI_MEMORY_PRESENT | EFI_MEMORY_INITIALIZED)) {
> //
> @@ -640,7 +640,7 @@ CoreAddMemoryDescriptor (
> gMemoryTypeInformation[FreeIndex].NumberOfPages
> );
> mMemoryTypeStatistics[Type].BaseAddress = 0;
> - mMemoryTypeStatistics[Type].MaximumAddress = MAX_ADDRESS;
> + mMemoryTypeStatistics[Type].MaximumAddress =
> MAX_ALLOC_ADDRESS;
> }
> }
> return;
> @@ -697,7 +697,7 @@ CoreAddMemoryDescriptor (
> }
> }
> mMemoryTypeStatistics[Type].CurrentNumberOfPages = 0;
> - if (mMemoryTypeStatistics[Type].MaximumAddress == MAX_ADDRESS) {
> + if (mMemoryTypeStatistics[Type].MaximumAddress ==
> MAX_ALLOC_ADDRESS) {
> mMemoryTypeStatistics[Type].MaximumAddress =
> mDefaultMaximumAddress;
> }
> }
> @@ -1318,15 +1318,15 @@ CoreInternalAllocatePages (
> //
> // The max address is the max natively addressable address for the processor
> //
> - MaxAddress = MAX_ADDRESS;
> + MaxAddress = MAX_ALLOC_ADDRESS;
>
> //
> // Check for Type AllocateAddress,
> // if NumberOfPages is 0 or
> - // if (NumberOfPages << EFI_PAGE_SHIFT) is above MAX_ADDRESS or
> + // if (NumberOfPages << EFI_PAGE_SHIFT) is above MAX_ALLOC_ADDRESS or
> // if (Start + NumberOfBytes) rolls over 0 or
> - // if Start is above MAX_ADDRESS or
> - // if End is above MAX_ADDRESS,
> + // if Start is above MAX_ALLOC_ADDRESS or
> + // if End is above MAX_ALLOC_ADDRESS,
> // return EFI_NOT_FOUND.
> //
> if (Type == AllocateAddress) {
> @@ -1968,7 +1968,7 @@ CoreAllocatePoolPages (
> //
> // Find the pages to convert
> //
> - Start = FindFreePages (MAX_ADDRESS, NumberOfPages, PoolType, Alignment,
> + Start = FindFreePages (MAX_ALLOC_ADDRESS, NumberOfPages, PoolType,
> Alignment,
> NeedGuard);
>
> //
> --
> 2.19.2
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
On Mon, 10 Dec 2018 at 03:04, Wang, Jian J <jian.j.wang@intel.com> wrote: > > Hi Ard, > > I think MAX_ALLOC_ADDRESS will affect other archs besides ARM. Please do enough > test for them (IA32/X64 for my concern). > For all other architectures, MAX_ADDRESS == MAX_ALLOC_ADDRESS is always true, so these changes only affect AARCH64. > In addition, do you think it's safer to replace MAX_ADDRESS with MAX_ALLOC_ADDRESS > in MemoryAllocationLib like following situation? > > (MdeModulePkg\Library\DxeCoreMemoryAllocationLib\MemoryAllocationLib.c) > VOID * > InternalAllocateCopyPool ( > IN EFI_MEMORY_TYPE PoolType, > IN UINTN AllocationSize, > IN CONST VOID *Buffer > ) > { > VOID *Memory; > > ASSERT (Buffer != NULL); > ASSERT (AllocationSize <= (MAX_ADDRESS - (UINTN) Buffer + 1)); > ... This assert ensures that the copied buffer does not extend across the end of the address space and wraps. This is a separate concern, and is similar to numerous other occurrences of MAX_ADDRESS that maybe we should update as well at some point. However, it does not affect page allocation at all, it only puts an upper bound on the *size* of the allocation. So the changes as they are will be sufficient to ensure that AllocateCopyPool() does not allocate from a region that is not addressable by the CPU. _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Ard: I prefer to define MAX_ALLOC_ADDRESS together with MAX_ADDRESS in ProcessorBind.h. I don't want to leave the choice to override MAX_ALLOC_ADDRESS definition. Thanks Liming > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Ard Biesheuvel > Sent: Monday, December 10, 2018 3:23 PM > To: Wang, Jian J <jian.j.wang@intel.com> > Cc: Andrew Jones <drjones@redhat.com>; Wu, Hao A <hao.a.wu@intel.com>; edk2-devel@lists.01.org; Gao, Liming > <liming.gao@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>; Laszlo Ersek <lersek@redhat.com> > Subject: Re: [edk2] [RFC PATCH 3/7] MdeModulePkg/Dxe/Page: take MAX_ALLOC_ADDRESS into account > > On Mon, 10 Dec 2018 at 03:04, Wang, Jian J <jian.j.wang@intel.com> wrote: > > > > Hi Ard, > > > > I think MAX_ALLOC_ADDRESS will affect other archs besides ARM. Please do enough > > test for them (IA32/X64 for my concern). > > > > For all other architectures, MAX_ADDRESS == MAX_ALLOC_ADDRESS is > always true, so these changes only affect AARCH64. > > > In addition, do you think it's safer to replace MAX_ADDRESS with MAX_ALLOC_ADDRESS > > in MemoryAllocationLib like following situation? > > > > (MdeModulePkg\Library\DxeCoreMemoryAllocationLib\MemoryAllocationLib.c) > > VOID * > > InternalAllocateCopyPool ( > > IN EFI_MEMORY_TYPE PoolType, > > IN UINTN AllocationSize, > > IN CONST VOID *Buffer > > ) > > { > > VOID *Memory; > > > > ASSERT (Buffer != NULL); > > ASSERT (AllocationSize <= (MAX_ADDRESS - (UINTN) Buffer + 1)); > > ... > > This assert ensures that the copied buffer does not extend across the > end of the address space and wraps. This is a separate concern, and is > similar to numerous other occurrences of MAX_ADDRESS that maybe we > should update as well at some point. However, it does not affect page > allocation at all, it only puts an upper bound on the *size* of the > allocation. So the changes as they are will be sufficient to ensure > that AllocateCopyPool() does not allocate from a region that is not > addressable by the CPU. > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
On Mon, 10 Dec 2018 at 15:52, Gao, Liming <liming.gao@intel.com> wrote: > > Ard: > I prefer to define MAX_ALLOC_ADDRESS together with MAX_ADDRESS in ProcessorBind.h. I don't want to leave the choice to override MAX_ALLOC_ADDRESS definition. > Seems reasonable. What should be the value for X64? > Thanks > Liming > > -----Original Message----- > > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Ard Biesheuvel > > Sent: Monday, December 10, 2018 3:23 PM > > To: Wang, Jian J <jian.j.wang@intel.com> > > Cc: Andrew Jones <drjones@redhat.com>; Wu, Hao A <hao.a.wu@intel.com>; edk2-devel@lists.01.org; Gao, Liming > > <liming.gao@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>; Laszlo Ersek <lersek@redhat.com> > > Subject: Re: [edk2] [RFC PATCH 3/7] MdeModulePkg/Dxe/Page: take MAX_ALLOC_ADDRESS into account > > > > On Mon, 10 Dec 2018 at 03:04, Wang, Jian J <jian.j.wang@intel.com> wrote: > > > > > > Hi Ard, > > > > > > I think MAX_ALLOC_ADDRESS will affect other archs besides ARM. Please do enough > > > test for them (IA32/X64 for my concern). > > > > > > > For all other architectures, MAX_ADDRESS == MAX_ALLOC_ADDRESS is > > always true, so these changes only affect AARCH64. > > > > > In addition, do you think it's safer to replace MAX_ADDRESS with MAX_ALLOC_ADDRESS > > > in MemoryAllocationLib like following situation? > > > > > > (MdeModulePkg\Library\DxeCoreMemoryAllocationLib\MemoryAllocationLib.c) > > > VOID * > > > InternalAllocateCopyPool ( > > > IN EFI_MEMORY_TYPE PoolType, > > > IN UINTN AllocationSize, > > > IN CONST VOID *Buffer > > > ) > > > { > > > VOID *Memory; > > > > > > ASSERT (Buffer != NULL); > > > ASSERT (AllocationSize <= (MAX_ADDRESS - (UINTN) Buffer + 1)); > > > ... > > > > This assert ensures that the copied buffer does not extend across the > > end of the address space and wraps. This is a separate concern, and is > > similar to numerous other occurrences of MAX_ADDRESS that maybe we > > should update as well at some point. However, it does not affect page > > allocation at all, it only puts an upper bound on the *size* of the > > allocation. So the changes as they are will be sufficient to ensure > > that AllocateCopyPool() does not allocate from a region that is not > > addressable by the CPU. > > _______________________________________________ > > edk2-devel mailing list > > edk2-devel@lists.01.org > > https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Keep the same value of MAX_ADDRESS. There is no change now. Thanks Liming > -----Original Message----- > From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] > Sent: Monday, December 10, 2018 10:54 PM > To: Gao, Liming <liming.gao@intel.com> > Cc: Wang, Jian J <jian.j.wang@intel.com>; Andrew Jones <drjones@redhat.com>; Wu, Hao A <hao.a.wu@intel.com>; > edk2-devel@lists.01.org; Kinney, Michael D <michael.d.kinney@intel.com>; Laszlo Ersek <lersek@redhat.com> > Subject: Re: [edk2] [RFC PATCH 3/7] MdeModulePkg/Dxe/Page: take MAX_ALLOC_ADDRESS into account > > On Mon, 10 Dec 2018 at 15:52, Gao, Liming <liming.gao@intel.com> wrote: > > > > Ard: > > I prefer to define MAX_ALLOC_ADDRESS together with MAX_ADDRESS in ProcessorBind.h. I don't want to leave the choice to > override MAX_ALLOC_ADDRESS definition. > > > > Seems reasonable. What should be the value for X64? > > > Thanks > > Liming > > > -----Original Message----- > > > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Ard Biesheuvel > > > Sent: Monday, December 10, 2018 3:23 PM > > > To: Wang, Jian J <jian.j.wang@intel.com> > > > Cc: Andrew Jones <drjones@redhat.com>; Wu, Hao A <hao.a.wu@intel.com>; edk2-devel@lists.01.org; Gao, Liming > > > <liming.gao@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>; Laszlo Ersek <lersek@redhat.com> > > > Subject: Re: [edk2] [RFC PATCH 3/7] MdeModulePkg/Dxe/Page: take MAX_ALLOC_ADDRESS into account > > > > > > On Mon, 10 Dec 2018 at 03:04, Wang, Jian J <jian.j.wang@intel.com> wrote: > > > > > > > > Hi Ard, > > > > > > > > I think MAX_ALLOC_ADDRESS will affect other archs besides ARM. Please do enough > > > > test for them (IA32/X64 for my concern). > > > > > > > > > > For all other architectures, MAX_ADDRESS == MAX_ALLOC_ADDRESS is > > > always true, so these changes only affect AARCH64. > > > > > > > In addition, do you think it's safer to replace MAX_ADDRESS with MAX_ALLOC_ADDRESS > > > > in MemoryAllocationLib like following situation? > > > > > > > > (MdeModulePkg\Library\DxeCoreMemoryAllocationLib\MemoryAllocationLib.c) > > > > VOID * > > > > InternalAllocateCopyPool ( > > > > IN EFI_MEMORY_TYPE PoolType, > > > > IN UINTN AllocationSize, > > > > IN CONST VOID *Buffer > > > > ) > > > > { > > > > VOID *Memory; > > > > > > > > ASSERT (Buffer != NULL); > > > > ASSERT (AllocationSize <= (MAX_ADDRESS - (UINTN) Buffer + 1)); > > > > ... > > > > > > This assert ensures that the copied buffer does not extend across the > > > end of the address space and wraps. This is a separate concern, and is > > > similar to numerous other occurrences of MAX_ADDRESS that maybe we > > > should update as well at some point. However, it does not affect page > > > allocation at all, it only puts an upper bound on the *size* of the > > > allocation. So the changes as they are will be sufficient to ensure > > > that AllocateCopyPool() does not allocate from a region that is not > > > addressable by the CPU. > > > _______________________________________________ > > > edk2-devel mailing list > > > edk2-devel@lists.01.org > > > https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
diff --git a/MdeModulePkg/Core/Dxe/Mem/Page.c b/MdeModulePkg/Core/Dxe/Mem/Page.c index 961c5b833546..5ad8e1171ef7 100644 --- a/MdeModulePkg/Core/Dxe/Mem/Page.c +++ b/MdeModulePkg/Core/Dxe/Mem/Page.c @@ -52,26 +52,26 @@ LIST_ENTRY mFreeMemoryMapEntryList = INITIALIZE_LIST_HEAD_VARIABLE (mFreeMemor BOOLEAN mMemoryTypeInformationInitialized = FALSE; EFI_MEMORY_TYPE_STATISTICS mMemoryTypeStatistics[EfiMaxMemoryType + 1] = { - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE, FALSE }, // EfiReservedMemoryType - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, // EfiLoaderCode - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, // EfiLoaderData - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, // EfiBootServicesCode - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, // EfiBootServicesData - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE, TRUE }, // EfiRuntimeServicesCode - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE, TRUE }, // EfiRuntimeServicesData - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, // EfiConventionalMemory - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, // EfiUnusableMemory - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE, FALSE }, // EfiACPIReclaimMemory - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE, FALSE }, // EfiACPIMemoryNVS - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, // EfiMemoryMappedIO - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, // EfiMemoryMappedIOPortSpace - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE, TRUE }, // EfiPalCode - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, // EfiPersistentMemory - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE } // EfiMaxMemoryType + { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE, FALSE }, // EfiReservedMemoryType + { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, // EfiLoaderCode + { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, // EfiLoaderData + { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, // EfiBootServicesCode + { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, // EfiBootServicesData + { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE, TRUE }, // EfiRuntimeServicesCode + { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE, TRUE }, // EfiRuntimeServicesData + { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, // EfiConventionalMemory + { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, // EfiUnusableMemory + { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE, FALSE }, // EfiACPIReclaimMemory + { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE, FALSE }, // EfiACPIMemoryNVS + { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, // EfiMemoryMappedIO + { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, // EfiMemoryMappedIOPortSpace + { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE, TRUE }, // EfiPalCode + { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, // EfiPersistentMemory + { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE } // EfiMaxMemoryType }; -EFI_PHYSICAL_ADDRESS mDefaultMaximumAddress = MAX_ADDRESS; -EFI_PHYSICAL_ADDRESS mDefaultBaseAddress = MAX_ADDRESS; +EFI_PHYSICAL_ADDRESS mDefaultMaximumAddress = MAX_ALLOC_ADDRESS; +EFI_PHYSICAL_ADDRESS mDefaultBaseAddress = MAX_ALLOC_ADDRESS; EFI_MEMORY_TYPE_INFORMATION gMemoryTypeInformation[EfiMaxMemoryType + 1] = { { EfiReservedMemoryType, 0 }, @@ -419,7 +419,7 @@ PromoteMemoryResource ( Entry = CR (Link, EFI_GCD_MAP_ENTRY, Link, EFI_GCD_MAP_SIGNATURE); if (Entry->GcdMemoryType == EfiGcdMemoryTypeReserved && - Entry->EndAddress < MAX_ADDRESS && + Entry->EndAddress < MAX_ALLOC_ADDRESS && (Entry->Capabilities & (EFI_MEMORY_PRESENT | EFI_MEMORY_INITIALIZED | EFI_MEMORY_TESTED)) == (EFI_MEMORY_PRESENT | EFI_MEMORY_INITIALIZED)) { // @@ -640,7 +640,7 @@ CoreAddMemoryDescriptor ( gMemoryTypeInformation[FreeIndex].NumberOfPages ); mMemoryTypeStatistics[Type].BaseAddress = 0; - mMemoryTypeStatistics[Type].MaximumAddress = MAX_ADDRESS; + mMemoryTypeStatistics[Type].MaximumAddress = MAX_ALLOC_ADDRESS; } } return; @@ -697,7 +697,7 @@ CoreAddMemoryDescriptor ( } } mMemoryTypeStatistics[Type].CurrentNumberOfPages = 0; - if (mMemoryTypeStatistics[Type].MaximumAddress == MAX_ADDRESS) { + if (mMemoryTypeStatistics[Type].MaximumAddress == MAX_ALLOC_ADDRESS) { mMemoryTypeStatistics[Type].MaximumAddress = mDefaultMaximumAddress; } } @@ -1318,15 +1318,15 @@ CoreInternalAllocatePages ( // // The max address is the max natively addressable address for the processor // - MaxAddress = MAX_ADDRESS; + MaxAddress = MAX_ALLOC_ADDRESS; // // Check for Type AllocateAddress, // if NumberOfPages is 0 or - // if (NumberOfPages << EFI_PAGE_SHIFT) is above MAX_ADDRESS or + // if (NumberOfPages << EFI_PAGE_SHIFT) is above MAX_ALLOC_ADDRESS or // if (Start + NumberOfBytes) rolls over 0 or - // if Start is above MAX_ADDRESS or - // if End is above MAX_ADDRESS, + // if Start is above MAX_ALLOC_ADDRESS or + // if End is above MAX_ALLOC_ADDRESS, // return EFI_NOT_FOUND. // if (Type == AllocateAddress) { @@ -1968,7 +1968,7 @@ CoreAllocatePoolPages ( // // Find the pages to convert // - Start = FindFreePages (MAX_ADDRESS, NumberOfPages, PoolType, Alignment, + Start = FindFreePages (MAX_ALLOC_ADDRESS, NumberOfPages, PoolType, Alignment, NeedGuard); //
Take MAX_ALLOC_ADDRESS into account in the implementation of the page allocation routines, so that they will only return memory that is addressable by the CPU at boot time, even if more memory is available in the GCD memory map. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> --- MdeModulePkg/Core/Dxe/Mem/Page.c | 52 ++++++++++---------- 1 file changed, 26 insertions(+), 26 deletions(-) -- 2.19.2 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel