Skip to content

v2023110001.0.0

Compare
Choose a tag to compare
@github-actions github-actions released this 22 May 17:46
· 18 commits to refs/heads/release/202311 since this release
d52a3ed

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:

    1. MemoryAttributeProtocol->SetMemoryAttributes(EFI_MEMORY_RO)
    2. ArmSetMemoryRegionReadOnly ()
    3. SetMemoryRegionAttribute()
    4. UpdateRegionMapping()
    5. UpdateRegionMappingRecursive()
    6. AllocatePages() -> Need memory for a translation table entry
    7. CoreAllocatePages()
    8. ApplyMemoryProtectionPolicy() -> Policy says new page should be XN
    9. gCpu->SetMemoryAttributes()
    10. 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, ...
    • 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, ...
    • 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, ...

    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:

    1. MemoryAttributeProtocol->SetMemoryAttributes(EFI_MEMORY_RO)
    2. ArmSetMemoryRegionReadOnly ()
    3. SetMemoryRegionAttribute()
    4. UpdateRegionMapping()
    5. UpdateRegionMappingRecursive()
    6. AllocatePages() -> Need memory for a translation table entry
    7. CoreAllocatePages()
    8. ApplyMemoryProtectionPolicy() -> Policy says new page should be XN
    9. gCpu->SetMemoryAttributes()
    10. 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, ...
    • 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, ...
    • 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, ...

    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, ...
    • 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, ...
    • 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, ...

    How This Was Tested

    Tested by booting SBSA to shell with RP on free memory active

    Integration Instructions

    N/A




Full Changelog: v2023110000.0.1...v2023110001.0.0