Tianocore/edk2.git/MdeModulePkg/Core/Dxe/Mem/Pool.c, branch master

MdeModulePkg: Fix missing NULL tests.

2025-11-22T18:58:47+00:00

https://github.com/github/codeql/blob/codeql-cli-2.7.3/cpp/ql/src/Critical/MissingNullTest.qhelp For items which allocate memory, or get a pointer from another structure, it is important to validate that the pointers are not null before they are dereferenced. Signed-off-by: Aaron Pop

MdeModulePkg: DxeCore: Do Not Apply Guards to Unsupported Types

2024-03-14T16:29:22+00:00

Currently, there are multiple issues when page or pool guards are allocated for runtime memory regions that are aligned to non-EFI_PAGE_SIZE alignments. Multiple other issues have been fixed for these same systems (notably ARM64 which has a 64k runtime page allocation granularity) recently. The heap guard system is only built to support 4k guard pages and 4k alignment. Today, the address returned to a caller of AllocatePages will not be aligned correctly to the runtime page allocation granularity, because the heap guard system does not take non-4k alignment requirements into consideration. However, even with this bug fixed, the Memory Allocation Table cannot be produced and an OS with a larger than 4k page granularity will not have aligned memory regions because the guard pages are reported as part of the same memory allocation. So what would have been, on an ARM64 system, a 64k runtime memory allocation is actually a 72k memory allocation as tracked by the Page.c code because the guard pages are tracked as part of the same allocation. This is a core function of the current heap guard architecture. This could also be fixed with rearchitecting the heap guard system to respect alignment requirements and shift the guard pages inside of the outer rounded allocation or by having guard pages be the runtime granularity. Both of these approaches have issues. In the former case, we break UEFI spec 2.10 section 2.3.6 for AARCH64, which states that each 64k page for runtime memory regions may not have mixed memory attributes, which pushing the guard pages inside would create. In the latter case, an immense amount of memory is wasted to support such large guard pages, and with pool guard many systems could not support an additional 128k allocation for all runtime memory. The simpler and safer solution is to disallow page and pool guards for runtime memory allocations for systems that have a runtime granularity greater than the EFI_PAGE_SIZE (4k). The usefulness of such guards is limited, as OSes do not map guard pages today, so there is only boot time protection of these ranges. This also prevents other bugs from being exposed by using guards for regions that have a non-4k alignment requirement, as again, multiple have cropped up because the heap guard system was not built to support it. This patch adds both a static assert to ensure that either the runtime granularity is the EFI_PAGE_SIZE or that the PCD bits are not set to enable heap guard for runtime memory regions. It also adds a check in the page and pool allocation system to ensure that at runtime we are not allocating a runtime region and attempt to guard it (the PCDs are close to being removed in favor of dynamic heap guard configurations). BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4674 Github PR: https://github.com/tianocore/edk2/pull/5382 Cc: Leif Lindholm Cc: Ard Biesheuvel Cc: Sami Mujawar Cc: Liming Gao Signed-off-by: Oliver Smith-Denny Reviewed-by: Liming Gao

MdeModulePkg: DxeCore: Correct Runtime Granularity Memory Type

2024-03-14T16:29:22+00:00

Per the UEFI spec 2.10, section 2.3.6 (for the AARCH64 arch, other architectures in section two confirm the same) the memory types that need runtime page allocation granularity are EfiReservedMemoryType, EfiACPIMemoryNVS, EfiRuntimeServicesCode, and EfiRuntimeServicesData. However, legacy code was setting runtime page allocation granularity for EfiACPIReclaimMemory and not EfiReservedMemoryType. This patch fixes that error. Cc: Leif Lindholm Cc: Ard Biesheuvel Cc: Sami Mujawar Cc: Liming Gao Signed-off-by: Oliver Smith-Denny Suggested-by: Ard Biesheuvel Reviewed-by: Liming Gao

MdeModulePkg: HeapGuard: Don't Assume Pool Head Allocated In First Page

2023-08-19T03:18:50+00:00

Currently, HeapGuard, when in the GuardAlignedToTail mode, assumes that the pool head has been allocated in the first page of memory that was allocated. This is not the case for ARM64 platforms when allocating runtime pools, as RUNTIME_PAGE_ALLOCATION_GRANULARITY is 64k, unlike X64, which has RUNTIME_PAGE_ALLOCATION_GRANULARITY as 4k. When a runtime pool is allocated on ARM64, the minimum number of pages allocated is 16, to match the runtime granularity. When a small pool is allocated and GuardAlignedToTail is true, HeapGuard instructs the pool head to be placed as (MemoryAllocated + EFI_PAGES_TO_SIZE(Number of Pages) - SizeRequiredForPool). This gives this scenario: |Head Guard|Large Free Number of Pages|PoolHead|TailGuard| When this pool goes to be freed, HeapGuard instructs the pool code to free from (PoolHead & ~EFI_PAGE_MASK). However, this assumes that the PoolHead is in the first page allocated, which as shown above is not true in this case. For the 4k granularity case (i.e. where the correct number of pages are allocated for this pool), this logic does work. In this failing case, HeapGuard then instructs the pool code to free 16 (or more depending) pages from the page the pool head was allocated on, which as seen above means we overrun the pool and attempt to free memory far past the pool. We end up running into the tail guard and getting an access flag fault. This causes ArmVirtQemu to fail to boot with an access flag fault when GuardAlignedToTail is set to true (and pool guard enabled for runtime memory). It should also cause all ARM64 platforms to fail in this configuration, for exactly the same reason, as this is core code making the assumption. This patch removes HeapGuard's assumption that the pool head is allocated on the first page and instead undoes the same logic that HeapGuard did when allocating the pool head in the first place. With this patch in place, ArmVirtQemu boots with GuardAlignedToTail set to true (and when it is false, also). BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4521 Github PR: https://github.com/tianocore/edk2/pull/4731 Cc: Leif Lindholm Cc: Ard Biesheuvel Cc: Jian J Wang Cc: Liming Gao Cc: Dandan Bi Signed-off-by: Oliver Smith-Denny Reviewed-by: Ard Biesheuvel Acked-by: Leif Lindholm Reviewed-by: Liming Gao

MdeModulePkg: EfiUnacceptedMemoryType is not allowed in AllocatePool

2023-02-07T05:33:38+00:00

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4315 MemoryType of EfiUnacceptedMemoryType should not be allocated in AllocatePool. Instead it should return EFI_INVALID_PARAMETER. Cc: Liming Gao Cc: Dandan Bi Cc: Erdem Aktas Cc: James Bottomley Cc: Jiewen Yao Cc: Gerd Hoffmann Cc: Tom Lendacky Cc: Michael Roth Reported-by: Liming Gao Signed-off-by: Min Xu Acked-by: Gerd Hoffmann Reviewed-by: Jiewen Yao Reviewed-by: Liming Gao

MdeModulePkg: Apply uncrustify changes

2021-12-07T17:24:28+00:00

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3737 Apply uncrustify changes to .c/.h files in the MdeModulePkg package Cc: Andrew Fish Cc: Leif Lindholm Cc: Michael D Kinney Signed-off-by: Michael Kubacki Reviewed-by: Liming Gao

MdeModulePkg: Replace BSD License with BSD+Patent License

2019-04-09T17:58:08+00:00

https://bugzilla.tianocore.org/show_bug.cgi?id=1373 Replace BSD 2-Clause License with BSD+Patent License. This change is based on the following emails: https://lists.01.org/pipermail/edk2-devel/2019-February/036260.html https://lists.01.org/pipermail/edk2-devel/2018-October/030385.html RFCs with detailed process for the license change: V3: https://lists.01.org/pipermail/edk2-devel/2019-March/038116.html V2: https://lists.01.org/pipermail/edk2-devel/2019-March/037669.html V1: https://lists.01.org/pipermail/edk2-devel/2019-March/037500.html Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Michael D Kinney Reviewed-by: Hao Wu Reviewed-by: Jian J Wang

MdeModulePkg/Core: add freed-memory guard feature

2018-10-26T02:30:35+00:00

Freed-memory guard is used to detect UAF (Use-After-Free) memory issue which is illegal access to memory which has been freed. The principle behind is similar to pool guard feature, that is we'll turn all pool memory allocation to page allocation and mark them to be not-present once they are freed. This also implies that, once a page is allocated and freed, it cannot be re-allocated. This will bring another issue, which is that there's risk that memory space will be used out. To address it, the memory service add logic to put part (at most 64 pages a time) of freed pages back into page pool, so that the memory service can still have memory to allocate, when all memory space have been allocated once. This is called memory promotion. The promoted pages are always from the eldest pages which haven been freed. This feature brings another problem is that memory map descriptors will be increased enormously (200+ -> 2000+). One of change in this patch is to update MergeMemoryMap() in file PropertiesTable.c to allow merge freed pages back into the memory map. Now the number can stay at around 510. Cc: Star Zeng Cc: Michael D Kinney Cc: Jiewen Yao Cc: Ruiyu Ni Cc: Laszlo Ersek Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jian J Wang Reviewed-by: Star Zeng

MdeModulePkg/Core: fix guard page missing issue

2018-02-02T01:50:15+00:00

This issue is a regression one caused by a patch at 425d25699be83c35e12df8470b827d7fbcef3bce That fix didn't take the 0 page to free into account, which still needs to call UnsetGuardPage() even no memory needs to free. The fix is just moving the calling of UnsetGuardPage() to the place right after calling AdjustMemoryF(). Cc: Star Zeng Cc: Eric Dong Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jian J Wang Reviewed-by: Ruiyu Ni

MdeModulePkg/Core: fix a logic hole in page free

2018-01-19T06:16:11+00:00

This hole will cause page fault randomly. The root cause is that Guard page, which is just freed back to page pool but not yet cleared not- present attribute, will be allocated right away by internal function CoreFreeMemoryMapStack(). The solution to this issue is to clear the not-present attribute for freed Guard page before doing any free operation, instead of after those operation. The reason we didn't do this before is due to the fact that manipulating page attributes might cause memory allocation action which would cause a dead lock inside a memory allocation/free operation. So we always set or unset Guard page outside the memory lock. After a thorough analysis, we believe clearing a Guard page will not cause memory allocation because memory we're to manipulate was already manipulated before for sure. Therefore there should be no memory allocation occurring in this situation. Since we cleared Guard page not-present attribute before freeing instead of after freeing, the debug code to clear freed memory can now be restored to its original way (aka no checking and bypassing Guard page). Cc: Ruiyu Ni Cc: Eric Dong Cc: Star Zeng Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jian J Wang Reviewed-by: Star Zeng Reviewed-by: Ruiyu Ni