v2023110001.0.0
What's Changed
-
Flush the FIFO when initializing the PL011 Serial Lib @cfernald (#227)
Change Details
## Description
Adds logic to the PL011 initialization that will flush the FIFO. Without this change it's possible for garbage or stale data to be read from the UART which can causes unexpected behavior or hangs during boot.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested
Tested on physical and virtual platform
Integration Instructions
N/A
</blockquote> <hr> </details>
⚠️ Breaking Changes
-
Pre-Allocate Page Table Memory in ArmMmuLib @TaylorBeebe (#220)
Change Details
## Description
Allocating memory when memory protection is active can cause the below infinite loop:
- MemoryAttributeProtocol->SetMemoryAttributes(EFI_MEMORY_RO)
- ArmSetMemoryRegionReadOnly ()
- SetMemoryRegionAttribute()
- UpdateRegionMapping()
- UpdateRegionMappingRecursive()
- AllocatePages() -> Need memory for a translation table entry
- CoreAllocatePages()
- ApplyMemoryProtectionPolicy() -> Policy says new page should be XN
- gCpu->SetMemoryAttributes()
- Back to 3
To fix this previously, CpuDxe would update conventional memory to be XN prior to installing the CpuArch protocol. However, when we transition to setting EFI_MEMORY_RP on free memory, this will no longer work.
This PR updates ArmMmuLib to reserve page table memory for allocation during table spits to prevent the infinite loop.
- Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
- Security - Does the change have a direct security impact on an application,
flow, or firmware? - Examples: Crypto algorithm change, buffer overflow fix, parameter
validation improvement, ...
- Security - Does the change have a direct security impact on an application,
- Breaking change?
- Breaking change - Will anyone consuming this change experience a break
in build or boot behavior? - Examples: Add a new library class, move a module to a different repo, call
a function in a new library class in a pre-existing module, ...
- Breaking change - Will anyone consuming this change experience a break
- Includes tests?
- Tests - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
- Documentation - Does the change contain explicit documentation additions
outside direct code modifications (and comments)? - Examples: Update readme file, add feature readme file, link to documentation
on an a separate Web page, ...
- Documentation - Does the change contain explicit documentation additions
How This Was Tested
Tested on SBSA by creating the scenario where the infinite loop (without the XN remap routine in place) and booting successfully. This was also tested using the EFI_MEMORY_RP on free memory feature branch.
Integration Instructions
Platforms which are using ArmMmuBaseLib for PEIM, PEI_CORE, and SEC modules will need to switch those module types to use ArmMmuPeiLib.
[LibraryClasses.common.SEC, LibraryClasses.common.PEIM, LibraryClasses.common.PEI_CORE] ArmMmuLib|ArmPkg/Library/ArmMmuLib/ArmMmuPeiLib.inf
</blockquote> <hr> </details>
🚀 Features & ✨ Enhancements
-
Pre-Allocate Page Table Memory in ArmMmuLib @TaylorBeebe (#220)
Change Details
## Description
Allocating memory when memory protection is active can cause the below infinite loop:
- MemoryAttributeProtocol->SetMemoryAttributes(EFI_MEMORY_RO)
- ArmSetMemoryRegionReadOnly ()
- SetMemoryRegionAttribute()
- UpdateRegionMapping()
- UpdateRegionMappingRecursive()
- AllocatePages() -> Need memory for a translation table entry
- CoreAllocatePages()
- ApplyMemoryProtectionPolicy() -> Policy says new page should be XN
- gCpu->SetMemoryAttributes()
- Back to 3
To fix this previously, CpuDxe would update conventional memory to be XN prior to installing the CpuArch protocol. However, when we transition to setting EFI_MEMORY_RP on free memory, this will no longer work.
This PR updates ArmMmuLib to reserve page table memory for allocation during table spits to prevent the infinite loop.
- Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
- Security - Does the change have a direct security impact on an application,
flow, or firmware? - Examples: Crypto algorithm change, buffer overflow fix, parameter
validation improvement, ...
- Security - Does the change have a direct security impact on an application,
- Breaking change?
- Breaking change - Will anyone consuming this change experience a break
in build or boot behavior? - Examples: Add a new library class, move a module to a different repo, call
a function in a new library class in a pre-existing module, ...
- Breaking change - Will anyone consuming this change experience a break
- Includes tests?
- Tests - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
- Documentation - Does the change contain explicit documentation additions
outside direct code modifications (and comments)? - Examples: Update readme file, add feature readme file, link to documentation
on an a separate Web page, ...
- Documentation - Does the change contain explicit documentation additions
How This Was Tested
Tested on SBSA by creating the scenario where the infinite loop (without the XN remap routine in place) and booting successfully. This was also tested using the EFI_MEMORY_RP on free memory feature branch.
Integration Instructions
Platforms which are using ArmMmuBaseLib for PEIM, PEI_CORE, and SEC modules will need to switch those module types to use ArmMmuPeiLib.
[LibraryClasses.common.SEC, LibraryClasses.common.PEIM, LibraryClasses.common.PEI_CORE] ArmMmuLib|ArmPkg/Library/ArmMmuLib/ArmMmuPeiLib.inf
</blockquote> <hr> </details>
🔐 Security Impacting
-
Install Empty GCD Sync Protocol After SyncCacheConfig() @TaylorBeebe (#228)
Change Details
## Description
With the addition of the following commit in MU_BASECORE, the ordering of memory protection initialization and the GCD sync has been flipped so the GCD sync occurs first: microsoft/mu_basecore@144e3fe
This reverse ordering was done to support RP on free memory because if the initialization was done first then the allocate memory calls during GCD sync would cause page faults because the attributes cannot be changed during the syncing process.
This PR installs the GCD sync complete protocol so the memory protection initialization routine is signaled.
- Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
- Security - Does the change have a direct security impact on an application,
flow, or firmware? - Examples: Crypto algorithm change, buffer overflow fix, parameter
validation improvement, ...
- Security - Does the change have a direct security impact on an application,
- Breaking change?
- Breaking change - Will anyone consuming this change experience a break
in build or boot behavior? - Examples: Add a new library class, move a module to a different repo, call
a function in a new library class in a pre-existing module, ...
- Breaking change - Will anyone consuming this change experience a break
- Includes tests?
- Tests - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
- Documentation - Does the change contain explicit documentation additions
outside direct code modifications (and comments)? - Examples: Update readme file, add feature readme file, link to documentation
on an a separate Web page, ...
- Documentation - Does the change contain explicit documentation additions
How This Was Tested
Tested by booting SBSA to shell with RP on free memory active
Integration Instructions
N/A
- Impacts functionality?
Full Changelog: v2023110000.0.1...v2023110001.0.0