Skip to content

v2023020017.0.0

Compare
Choose a tag to compare
@github-actions github-actions released this 16 Jul 20:38

What's Changed

  • MuCodeQlQueries.qls: Pin to the 0.9.12 codeq/cpp-queries pack @makubacki (#883)
    Change Details
      ## Description

    The codeql/cpp-queries pack used in MuCodeQlQueries.qls was versioned
    0.9.12 for the CodeQL CLI v2.17.3 release currently used.

    https://github.com/github/codeql/blob/codeql-cli/v2.17.3/cpp/ql/src/qlpack.yml

    This change pins that pack version to prevent the CodeQL CLI and
    pack from getting out of sync until explicitly updated.

    • Impacts functionality?
    • Impacts security?
    • Breaking change?
    • Includes tests?
    • Includes documentation?

    How This Was Tested

    • Verified the CodeQL query pack version listed is pulled.

    Integration Instructions

    • N/A - No change to queries used. Should prevent breaks in the future where
      the latest queries are no longer compatible with the current CodeQL CLI used.


⚠️ Breaking Changes

  • [REVERT] [CHERRY-PICK] Reverts previous commit to update to 2023.2.16, moves to 2023.2.15, corrects extdep, removes duplicate files @Flickdm (#913)
    Change Details
      ## Description

    An incorrect assumption was made that the INF's need to be removed from the CryptoPkgDriver because the MU_BASECORE already had duplicate entries and this aligned with previous releases (Now unlisted 2023.2.16). This goes back to the working release (2023.2.15) and updates the extdep accordingly. Further additional (potentially breaking) changes were required to be made to get the crypto package working. See commit 5efeb20

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

    • Impacts functionality?
      • Simplifies RNG Support expected of platforms
      • platforms integrating the binaries may have very different levels of support for random number generation,
      • allow the platform to provide a RNG service for PEI and DXE.
    • Impacts security?
    • Breaking change?
      • Platforms are expected to provide a source for RNG
      • Platforms that have a direct dependency on CryptoPkg should now use $(SHARED_CRYPTO_PATH)
        !include $(SHARED_CRYPTO_PATH)/Driver/Bin/CryptoDriver.inc.dsc
      
    • Includes tests?
    • Includes documentation?

    How This Was Tested

    Built on multiple Release/202302 based platforms
    Booted to Shell

    Integration Instructions

    Platforms are expected to provide a source for RNG [this change]
    (microsoft/mu_crypto_release@68c7e29)

    MU_TIANO_PLATFORMS may be used as an example




  • Update Crypto Driver to 2023.2.16 for RNG Services @Flickdm (#910)
    Change Details
      # Preface

    This updates the crypto driver to simplify RNG support and allows for a platform to provide a RNG service for PEI and DXE.

    The crypto binary (2023.2.15) was built at this commit
    microsoft/mu_crypto_release@c978485

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

    • Impacts functionality?
      • Simplifies RNG Support expected of platforms
      • platforms integrating the binaries may have very different levels of support for random number generation,
      • allow the platform to provide a RNG service for PEI and DXE.
    • Impacts security?
    • Breaking change?
      • Platforms are expected to provide a source for RNG
    • Includes tests?
    • Includes documentation?

    How This Was Tested

    ✔️ Built locally
    ✔️ Built against Pipelines
    ✔️ Booted to shell
    ✔️ Booted to frontpage on a system with rdrand disabled

    Integration Instructions

    • Read the readme update made in this change in the
      "Dependencies Built into Shared Crypto" section.

      </blockquote>
      <hr>
      

🚀 Features & ✨ Enhancements

  • [CHERRY-PICK] Add RNG PPI Support [Rebase \& FF] @makubacki (#888)
    Change Details
      ## Description

    MdePkg: Add Random Number Generator (RNG) PPI

    Adds a new PPI that serves the same purpose as EFI_RNG_PROTOCOL in
    DXE. This PPI can be produced by a PEIM to provide a dynamic interface
    to RNG services in PEI.

    This PPI is called EFI_RNG_PPI because it shares the exact same
    interface with EFI_RNG_PROTOCOL which is described in the UEFI
    Speficiation.


    MdePkg: Add PeiRngLib

    Adds a new PEI library instance for RngLib that uses the RNG services
    provided by the RNG PPI.

    This library instance will add a DEPEX on gEfiRngPpiGuid on modules
    it links against. It can be used to allow PEIMs to get RNG support
    over a dynamic interface.


    (cherry picked from mu_basecore/release/202311)

    • Impacts functionality?
    • Impacts security?
    • Breaking change?
    • Includes tests?
    • Includes documentation?

    How This Was Tested

    • MdePkg CI
    • Verify the RNG PPI can be successfully produced and consumed

    Integration Instructions

    If a platform needs to share RNG support across a dynamic interface
    between PEIMs, the RNG PPI can be used. PeiRngLib provides a RngLib
    instance that use the RNG PPI. It will include a dependency on gEfiRngPpiGuid.




🐛 Bug Fixes

  • [CHERRY-PICK] Set EFI\_MEMORY\_SP as System Memory @makubacki (#920)
    Change Details
      ## Description

    Cherry picks 9051d2e from release/202311.

    When supplying DxeCore with a resource descriptor HOB, a platform can choose which memory type to specify. For EFI_MEMORY_SP resource descriptor HOBs, instead of blindly setting GcdReserved as the memory type, respect what the resource descriptor HOB specified. Closes #884.

    • 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 virtual platforms with CXL memory attached.

    Integration Instructions

    N/A.




  • [CHERRY-PICK] [Release/202302] UnitTestFrameworkPkg: Fix Google Test components with multiple files @Flickdm (#893)
    Change Details
      # Preface REF: https://github.com//pull/891 - Dropping GOOGLETEST_HOST_UNIT_BUILD option as release/202302 does not have any expectation to support it.

    REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4610

    Google Test hides test registration in global constructors on global objects. Global constructors are traditionally implemented by placing references to the global constructor's symbol in special sections (traditionally named .ctors or .init_array). These sections are not explicitly referenced by the linker, and libc only looks at special start and end symbols (and calls them).

    This works fine if you're linking a program manually using

    gcc a.o b.o c.o -o test_suite
    

    but fails miserably when using static libraries (such as what EDK2 does), because traditional static archive symbol resolution rules don't allow for object files to be pulled in to the link if there isn't an undefined symbol reference to that .o elsewhere.

    Fix it by passing --whole-archive (GCC) and /WHOLEARCHIVE (MSVC). These options force the linker to pull in the entire static library, thus including previously-unreferenced constructors and making sure multi-file gtest EDK2 components work.

    Cc: Michael D Kinney [email protected]
    Cc: Michael Kubacki [email protected]
    Cc: Sean Brogan [email protected]

    Reviewed-by: Cc: Michael D Kinney [email protected]

    Description

    This corrects an issue with MSVC where unit tests are not being linked correctly - thus creating unit tests with zero tests

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

    • Impacts functionality?
    • Impacts security?
    • Breaking change?
    • Includes tests?
      • This will cause unit tests to actually run with MSVC
    • Includes documentation?

    How This Was Tested

    Local builds with Host Based Unit Tests

    Integration Instructions

    N/A




  • [CHERRY-PICK] [Release/202302] NetworkPkg TcpDxe: Fixed system stuck on PXE boot flow in iPXE environment @Flickdm (#880)
    Change Details
      ## Description

    This bug fix is based on the following commit "NetworkPkg TcpDxe: SECURITY PATCH"
    REF: 1904a64

    Issue Description:
    An "Invalid handle" error was detected during runtime when attempting to destroy a child instance of the hashing protocol. The problematic code segment was:

    NetworkPkg\TcpDxe\TcpDriver.c
    Status = Hash2ServiceBinding->DestroyChild(Hash2ServiceBinding, ​&mHash2ServiceHandle);

    Root Cause Analysis:
    The root cause of the error was the passing of an incorrect parameter type, a pointer to an EFI_HANDLE instead of an EFI_HANDLE itself, to the DestroyChild function. This mismatch resulted in the function receiving an invalid handle.

    Implemented Solution:
    To resolve this issue, the function call was corrected to pass mHash2ServiceHandle directly:

    NetworkPkg\TcpDxe\TcpDriver.c
    Status = Hash2ServiceBinding->DestroyChild(Hash2ServiceBinding, mHash2ServiceHandle);

    This modification ensures the correct handle type is used, effectively rectifying the "Invalid handle" error.

    Verification:
    Testing has been conducted, confirming the efficacy of the fix. Additionally, the BIOS can boot into the OS in an iPXE environment.

    Cc: Doug Flick [MSFT] [email protected]

    Reviewed-by: Saloni Kasbekar [email protected]

    • [ X] Impacts functionality?
      • Corrects handle passed to DestroyChild(..)
    • Impacts security?
      • N/A
    • Breaking change?
      • N/A
    • Includes tests?
      • N/A
    • Includes documentation?
      • N/A

    How This Was Tested

    "Testing has been conducted, confirming the efficacy of the fix. Additionally, the BIOS can boot into the OS in an iPXE environment."

    iPXE booted successfully

    Integration Instructions

    N/A




🔐 Security Impacting

  • [CHERRY-PICK] [RELEASE/202302] Pulling PixieFail changes from EDK2 for CVE-2023-45237 and CVE-2023-45236 @Flickdm (#898)
    Change Details
      REF: https://github.com//pull/897

    Description

    This pulls in the changes from EDK2 that were made during the upstreaming of CVE-2023-45237 and CVE-2023-45236

    The notable changes are:

    • Updates to the Unit Tests to get them to pass due to the underlying code being altered to use Hash2 Protocol and RngProtocol

    • Addition of the following algorithms to be more inclusive to ARM platforms
      - &gEfiRngAlgorithmArmRndr, // unspecified SP800-90A DRBG via ARM RNDR register
      - &gEfiRngAlgorithmRaw, // Raw data from NRBG (or TRNG)

    • Impacts functionality?

      • gEfiRngAlgorithmArmRndr and gEfiRngAlgorithmRaw allow the platform to be more inclusive of ARM and if they provide these guids they no longer need to depend on DEFAULT
    • Impacts security?

      • As mentioned before - allows for the ARM platforms to be more specific than before
    • Breaking change?

    • Includes tests?

      • Updates the Unit tests to pass due to the new dependencies
    • Includes documentation?

      • File containing what CVEs were patched

    How This Was Tested

    Local unit test

    Integration Instructions

    If the platform was setting PcdEnforceSecureRngAlgorithms before they may not be required to do so now that the new algorithms are included




📖 Documentation Updates

  • [REVERT] [CHERRY-PICK] Reverts previous commit to update to 2023.2.16, moves to 2023.2.15, corrects extdep, removes duplicate files @Flickdm (#913)
    Change Details
      ## Description

    An incorrect assumption was made that the INF's need to be removed from the CryptoPkgDriver because the MU_BASECORE already had duplicate entries and this aligned with previous releases (Now unlisted 2023.2.16). This goes back to the working release (2023.2.15) and updates the extdep accordingly. Further additional (potentially breaking) changes were required to be made to get the crypto package working. See commit 5efeb20

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

    • Impacts functionality?
      • Simplifies RNG Support expected of platforms
      • platforms integrating the binaries may have very different levels of support for random number generation,
      • allow the platform to provide a RNG service for PEI and DXE.
    • Impacts security?
    • Breaking change?
      • Platforms are expected to provide a source for RNG
      • Platforms that have a direct dependency on CryptoPkg should now use $(SHARED_CRYPTO_PATH)
        !include $(SHARED_CRYPTO_PATH)/Driver/Bin/CryptoDriver.inc.dsc
      
    • Includes tests?
    • Includes documentation?

    How This Was Tested

    Built on multiple Release/202302 based platforms
    Booted to Shell

    Integration Instructions

    Platforms are expected to provide a source for RNG [this change]
    (microsoft/mu_crypto_release@68c7e29)

    MU_TIANO_PLATFORMS may be used as an example




  • Update Crypto Driver to 2023.2.16 for RNG Services @Flickdm (#910)
    Change Details
      # Preface

    This updates the crypto driver to simplify RNG support and allows for a platform to provide a RNG service for PEI and DXE.

    The crypto binary (2023.2.15) was built at this commit
    microsoft/mu_crypto_release@c978485

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

    • Impacts functionality?
      • Simplifies RNG Support expected of platforms
      • platforms integrating the binaries may have very different levels of support for random number generation,
      • allow the platform to provide a RNG service for PEI and DXE.
    • Impacts security?
    • Breaking change?
      • Platforms are expected to provide a source for RNG
    • Includes tests?
    • Includes documentation?

    How This Was Tested

    ✔️ Built locally
    ✔️ Built against Pipelines
    ✔️ Booted to shell
    ✔️ Booted to frontpage on a system with rdrand disabled

    Integration Instructions

    • Read the readme update made in this change in the
      "Dependencies Built into Shared Crypto" section.


Full Changelog: v2023020016.1.1...v2023020017.0.0