Tianocore/edk2.git/MdeModulePkg/Core/DxeIplPeim, branch master

MdeModulePkg: DxeIpl: Don't Duplicate Mem Alloc Hob for Stack

2026-09-03T09:00:37+00:00

Currently, DxeIpl will allocate memory for the new DXE stack, which creates a memory allocation HOB for that region. It will then call UpdateStackHob() to find the stack HOB with the old stack info and update the memory address/length to correspond to the new stack. It then creates a new memory allocation HOB for the old stack region as it needs to remain mapped. This ends up creating two memory allocation HOBs for the new stack: a regular memory allocation HOB for the AllocatePages() call and then the stack HOB (which is a memory allocation HOB with a special name). When DXE Core ingests these, it will ignore one of the two HOBs when it goes to allocate memory. However, this is incorrectly describing handoff state. There never should be overlapping memory allocation HOBs. This commit updates DxeIpl behavior to instead find the old stack HOB, convert it to a regular memory allocation HOB, then find the memory allocation HOB for the new stack range and convert it into the stack HOB. Signed-off-by: Oliver Smith-Denny

MdeModulePkg: DxeIpl IA32: Use 256 IDT Entries

2026-03-07T03:58:40+00:00

When IA32 DxeIpl is setting up the IDT, it should populate 256 entries, the architectural size, so that exceptions are handled in a defined way, going to the common exception handler. This includes the stack cookie exception. Signed-off-by: Oliver Smith-Denny

MdeModulePkg: Replace include guards with #pragma once

2026-02-23T21:01:28+00:00

Replace traditional `#ifndef`/`#define`/`#endif` include guards with `#pragma` once. `#pragma once` is a widely supported preprocessor directive that prevents header files from being included multiple times. It is supported by all toolchains used to build edk2: GCC, Clang/LLVM, and MSVC. Compared to macro-based include guards, `#pragma once`: - Eliminates the risk of macro name collisions or copy/paste errors where two headers inadvertently use the same guard macro. - Eliminate inconsistency in the way include guard macros are named (e.g., some files use `__FILE_H__`, others use `FILE_H_`, etc.). - Reduces boilerplate (three lines replaced by one). - Avoids polluting the macro namespace with guard symbols. - Can improve build times as the preprocessor can skip re-opening the file entirely, rather than re-reading it to find the matching `#endif` ("multiple-include optimization"). - Note that some compilers may already optimize traditional include guards, by recognzining the idiomatic pattern. This change is made acknowledging that overall portability of the code will technically be reduced, as `#pragma once` is not part of the C/C++ standards. However, this is considered acceptable given: 1. edk2 already defines a subset of supported compilers in BaseTools/Conf/tools_def.template, all of which have supported `#pragma once` for over two decades. 2. There have been concerns raised to the project about inconsistent include guard naming and potential macro collisions. Approximate compiler support dates: - MSVC: Supported since Visual C++ 4.2 (1996) - GCC: Supported since 3.4 (2004) (http://gnu.ist.utl.pt/software/gcc/gcc-3.4/changes.html) - Clang (LLVM based): Since initial release in 2007 Signed-off-by: Michael Kubacki

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: Remove ARM32 Support

2025-09-25T22:04:10+00:00

edk2 is dropping support for the ARM32 architecture. This commit removes ARM32 support from MdeModulePkg. This also drops irrelevant VALID_ARCHITECTURE comments from infs that are not arch specific. Signed-off-by: Oliver Smith-Denny

MdeModulePkg: Don't Allocate Page 0

2025-07-08T03:45:09+00:00

Currently DxeIpl attempts to set page 0 to all 0's and to create a memory allocation HOB for it. However, DxeIpl will also unmap the page when mapping page tables and if null detection is not enabled, DxeCore will set the page to 0, regardless of allocation status. Because no consumers are using the memory allocation HOB for page 0, drop it. Instead, ensure that PeiCore and DxeCore do not allow allocating page 0; it should always be reserved for null pointer detection. It also complicates the story for platforms that are attempting to audit the system and ensure that no modules are using page 0. With these memory allocation HOBs in place, it is difficult to tell if it is simply DxeIpl who has allocated the memory or another module. This commit drops the memory allocation HOB publishing and ensures that DxeCore and PeiCore do not allocate page 0. DxeCore already will not allocate page 0 to callers of AllocatePages who call with a type other than AllocateAddress, this just changes so that AllocateAddress cannot allocate at page 0 (which if null detection is enabled will cause a page fault). PeiCore does not have AllocateAddress and so this ensures standard allocations do not receive page 0. Signed-off-by: Oliver Smith-Denny

MdeModulePkg: Fix EFI_SUCCESS typos

2025-06-12T17:50:45+00:00

EFI_SUCESS -> EFI_SUCCESS EFI_SUCESSS -> EFI_SUCCESS Signed-off-by: Gao Qihang

MdeModulePkg/DxeIplPeim: Free scratch buffer after FV extraction

2024-12-06T10:17:16+00:00

The scratch buffer (EfiBootServicesData) is assigned to extract DXE FVs that are compressed. The matching decompression library returns the buffer size as below. The buffer is no longer used after completing extraction. Need to free the buffer to optimize memory allocation and usage. BaseUefiDecompressLib : sizeof (SCRATCH_DATA) LzmaCustomDecompressLib : SCRATCH_BUFFER_REQUEST_SIZE (64KB) BrotliCustomDecompressLib : From EncodeData header (usually, xxMB checked) In case of Brotli decompression, it is found that a big chunk of memory is required, based on EncodeData header. (e.g. a 4MB compressed FV reports about 39MB scratch size) Signed-off-by: Phil Noh

MedModulePkg/DxeIplPeim: Fix pagetable protection region in 5 level paging

2024-11-17T20:52:10+00:00

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4873 Currently the function does not cover the 5 level paging case. it will casued pagetable protection region set incorrectly. This patch do the enhancemant and with the patch protection region has been set correctly. Signed-off-by: Ning Feng Cc: Ray Ni

MdeModulePkg/Core/DxeIplPeim: Enhance Code in DxeIplFindDxeCore Function

2024-07-17T05:46:12+00:00

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4653 In DxeIplFindDxeCore function, there exists different behavior between Debug and Release built BIOS. This change is used to unify both of the code flow and fix the potential overflow of "Instance" variable. In this change, [1] Move the ASSERT_EFI_ERROR (Status) in failure to find DxeCore in any firmware volume condition. [2] Break the while-loop when not found required DxeCore. This would make the Instance variable not overflow in while-loop. [3] Add the CpuDeadLoop () in the end of the function and do not return since DxeCore is mandatory for the following booting to hand-off the PEI phase to DXE phase. [4] In case of the CpuDeadLoop () is de-assert by debugger, return the NULL pointer. Signed-off-by: Jason1 Lin