Skip to content

v2023020016.0.0
Compare
Choose a tag to compare
@github-actions github-actions released this 23 Apr 22:03
· 16 commits to refs/heads/release/202302 since this release
v2023020016.0.0
337190c
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Learn about vigilant mode.

What's Changed

  • Bug: Fix incorrect CodeQL Fix - REBASE with PR 6024 @spbrogan (#819)
    Change Details
      (cherry picked from commit f26f86d)

    Description

    In commit 2998774 an unintentional code change in BmBoot BmExpandFileDevicePath was introduced. The change intended to fix a CodeQL error but introduced a failure with the boot managers ability to expand a "short" file device path boot option.

    • 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 VM

    Integration Instructions

    NA



  • Fix Possible Allocation of Pages While They Are Being Freed @TaylorBeebe (#814)
    Change Details
      ## Description

    FreeMemoryMapStack() within CoreConvertPagesEx() may allocate pages which, if the converted memory is being freed (implied by the new type being EfiConventionalMemory), could cause the memory currently being freed to be allocated during the convert process it if CoreFreeMemoryMapStack() is called after AddRange(). So, if the convert is being done due to a free pages call, free the memory map stack before adding memory to the free list.

    • 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 Q35

    Integration Instructions

    N/A



  • Add a Deprecated Build Option To Allow Incompatible AARCH64 Platforms To Opt Out of 64k Runtime Granularity @os-d (#798)
    Change Details
      ## Description

    Some AARCH64 platforms are incompatible with 64k runtime granularity. This PR adds a build option that is consumed to enable a deprecated option to set the runtime page allocation granularity to 4k. This option should not be used except for old platforms that cannot be updated to comply with 64k runtime granularity. Using this option breaks compatibility with the UEFI spec.

    For each item, place an "x" in between [ and ] if true. Example: [x].
    (you can also check items in the GitHub UI)

    • 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 with setting flag and unsetting.

    Integration Instructions

    Do not use this option without an old platform that cannot support 64k.

    MSFT:*_*_*_CC_FLAGS = /D __DEPRECATED_AARCH64_4K_RUNTIME_GRANULARITY
GCC:*_*_*_CC_FLAGS = -D __DEPRECATED_AARCH64_4K_RUNTIME_GRANULARITY

    For those platforms, set the above in the platform DSC.



⚠️ Breaking Changes

  • [Cherry-Pick] PixieFail Security Patches for TCBZ451 and TCB4542 @Flickdm (#801)
    Change Details
      ## Description

    Cherry-picked from release/202311

    This fixes the remaining two issues from PixieFail.

    See https://blog.quarkslab.com/pixiefail-nine-vulnerabilities-in-tianocores-edk-ii-ipv6-network-stack.html
    for more detailed information on:

    1. CVE 2023-45236 (TCBZ4541)
    2. CVE 2023-45237 (TCBZ4542)
    • Impacts functionality?
    • Impacts security?
      • Fixes vulnerabilities identified by Pixie Fail
      • Updates the ISN generation to follow the specification
      • Replaces all instances of NET_RANDOM with the random number generator provided by the platform.
    • Breaking change?
      • Yes this depends on the Hash2ServiceProtocol. A platform must publish these in order for these patches to work.
    • Includes tests?
    • Includes documentation?

    How This Was Tested

    This was tested on a physical platform by PXEBooting and performing TCP Connections through DFCI

    Integration Instructions

    Ensure the platform publishes the HASH 2 Protocol.



🔐 Security Impacting

  • [Cherry-Pick] PixieFail Security Patches for TCBZ451 and TCB4542 @Flickdm (#801)
    Change Details
      ## Description

    Cherry-picked from release/202311

    This fixes the remaining two issues from PixieFail.

    See https://blog.quarkslab.com/pixiefail-nine-vulnerabilities-in-tianocores-edk-ii-ipv6-network-stack.html
    for more detailed information on:

    1. CVE 2023-45236 (TCBZ4541)
    2. CVE 2023-45237 (TCBZ4542)
    • Impacts functionality?
    • Impacts security?
      • Fixes vulnerabilities identified by Pixie Fail
      • Updates the ISN generation to follow the specification
      • Replaces all instances of NET_RANDOM with the random number generator provided by the platform.
    • Breaking change?
      • Yes this depends on the Hash2ServiceProtocol. A platform must publish these in order for these patches to work.
    • Includes tests?
    • Includes documentation?

    How This Was Tested

    This was tested on a physical platform by PXEBooting and performing TCP Connections through DFCI

    Integration Instructions

    Ensure the platform publishes the HASH 2 Protocol.



  • [CHERRY-PICK] Add NO\_STACK\_COOKIE to Module Entry Points @TaylorBeebe (#796)
    Change Details
      ## Description

    When the DXE dispatcher dispatches an EFI module, execution starts with the ModuleEntryPoint of the EFI. If the stack cookie value is randomized during the library constructor process and the ModuleEntryPoint includes a stack cookie check, then the value of the stack cookie will change between the start and end of the ModuleEntryPoint function and cause a stack cookie check failure. With this change, the following is the structure which ensures the stack cookie check will not erroneously fail:

    NO_STACK_COOKIE
ModuleEntryPoint (

  NO_STACK_COOKIE 
  ProcessLibraryConstructorList (

    NO_STACK_COOKIE 
    InitializeStackCookie ()
  )
)
    • 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 to shell on Q35 built with GCC and VS2022, and by booting SBSA built with GCC.

    Integration Instructions

    N/A



Full Changelog: v2023020015.0.0...v2023020016.0.0

Contributors

spbrogan, Flickdm, and 2 other contributors
Assets 4