diff options
author | Oliver Smith-Denny <osde@microsoft.com> | 2025-06-17 15:29:13 -0700 |
---|---|---|
committer | mergify[bot] <37929162+mergify[bot]@users.noreply.github.com> | 2025-07-08 03:45:09 +0000 |
commit | 91bb5cee36fe52ef012ddbead4f5932b3f9fd862 (patch) | |
tree | cdeeb4a1599e5a0905fdee1ec44d3c356a8d21ac /MdeModulePkg/Library/PiDxeS3BootScriptLib/BootScriptExecute.c | |
parent | 83b30736bfb57b3895a089968319fb5c0cd42a28 (diff) | |
download | edk2-91bb5cee36fe52ef012ddbead4f5932b3f9fd862.zip edk2-91bb5cee36fe52ef012ddbead4f5932b3f9fd862.tar.gz edk2-91bb5cee36fe52ef012ddbead4f5932b3f9fd862.tar.bz2 |
MdeModulePkg: Don't Allocate Page 0
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 <osde@microsoft.com>
Diffstat (limited to 'MdeModulePkg/Library/PiDxeS3BootScriptLib/BootScriptExecute.c')
0 files changed, 0 insertions, 0 deletions