[major] Do Not Allow Non-Page Aligned GCD Allocations - #1767
Open
os-d wants to merge 3 commits into
Open
Conversation
Currently, Patina took the stance that it should allocate FVs to make sure memory allocations did not stomp on them. However, this led to an issue where FVs are not page aligned and so non-page aligned allocations were made in the GCD. The EFI_MEMORY_MAP must be page aligned, so these regions could not be added and had to be silently dropped. Patina does not have the information required to know if it is safe to extend these allocations to page aligned lengths. Originally, Patina inherited behavior from EDK II to only allocate FV regions if they were MMIO. However, MMIO allocations are not used in the core. It is the domain of the pre-DXE phase to properly describe allocations to DXE so that existing allocations are not stomped on. The PI spec defined way is to do this through memory allocation HOBs. As such, Patina should only rely on memory allocation HOBs to build the GCD, not FV HOBs. It is then a reasonable expectation to say that memory allocation HOBs must be page aligned. This expectation is also testable and added to the patina-readiness-tool. Signed-off-by: Oliver Smith-Denny <osde@microsoft.com>
The GCD must have page aligned allocations because the EFI_MEMORY_MAP is built from it, which must be page aligned per spec (and the structure only describes ranges in page count length). In addition, memory protections rely on page aligned regions. This commit enforces this expectation. Signed-off-by: Oliver Smith-Denny <osde@microsoft.com>
This reverts commit 7d88394. This commit allowed for non-page aligned GCD allocations, but that allowance is no longer made because of the two preceding commits. Signed-off-by: Oliver Smith-Denny <osde@microsoft.com>
github-actions
Bot
added
the
impact:breaking-change
1 task
Contributor
Author
|
I need to come back and update the docs as well |
joschock
approved these changes
Sep 4, 2026
makubacki
approved these changes
Sep 4, 2026
makubacki
left a comment
makubacki
left a comment
Collaborator
There was a problem hiding this comment.
Looks good pending the doc update.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
This PR fixes #1614 and has three commits. This PR is targeting the major branch because platforms should re-run the readiness tool to confirm FV regions are covered by memory allocation HOBs.
GCD: Do Not Allocate FV HOB Regions
Currently, Patina took the stance that it should allocate FVs to make sure memory allocations did not stomp on them. However, this led to an issue where FVs are not page aligned and so non-page aligned allocations were made in the GCD. The EFI_MEMORY_MAP must be page aligned, so these regions could not be added and had to be silently dropped. Patina does not have the information required to know if it is safe to extend these allocations to page aligned lengths.
Originally, Patina inherited behavior from EDK II to only allocate FV regions if they were MMIO. However, MMIO allocations are not used in the core.
It is the domain of the pre-DXE phase to properly describe allocations to DXE so that existing allocations are not stomped on. The PI spec defined way is to do this through memory allocation HOBs. As such, Patina should only rely on memory allocation HOBs to build the GCD, not FV HOBs. It is then a reasonable expectation to say that memory allocation HOBs must be page aligned.
This expectation is also testable and added to the patina-readiness-tool.
GCD: Enforce Page Aligned Allocations
The GCD must have page aligned allocations because the EFI_MEMORY_MAP is built from it, which must be page aligned per spec (and the structure only describes ranges in page count length). In addition, memory protections rely on page aligned regions.
This commit enforces this expectation.
Revert "dxe: GCD: Don't Assert on Non-Page Aligned GCD Allocations"
This reverts commit 7d88394. This commit allowed for non-page aligned GCD allocations, but that allowance is no longer made because of the two preceding commits.
How This Was Tested
Through updating the patina-readiness-tool and confirming these assumptions are valid.
Integration Instructions
Platforms should re-run the patina-readiness-tool v0.4.0 or greater when about to ingest this change. They should confirm that FV HOBs are covered by memory allocation HOBs. If not, page aligned memory allocation HOBs must be produced by the platform for the FV regions.
Separately, the platform should identify if any non-page aligned GCD allocations are being made (debug_asserts will catch this). If so, they must convert them to page aligned allocations. This does not affect AllocatePool allocations, only direct GCD allocations through AllocateMemorySpace().