Skip to content

v2023110000.0.2

Compare
Choose a tag to compare
@github-actions github-actions released this 05 Mar 15:17
· 81 commits to refs/heads/release/202311 since this release

What's Changed

  • [CHERRY-PICK] Add StackCheckLib Instances to Platform DSC Files (#446) @TaylorBeebe (#447)
    Change Details
      ## Description

    An instance of StackCheckLib must be in each DSC to accommodate -fstack-protector and /GS flags.

    • 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 in pipelines

    Integration Instructions

    N/A




  • Enable Pre-DXE Logs for Platforms Which Can't use Pre-DXE AdvancedLoggerLib Instances @TaylorBeebe (#440)
    Change Details
      ## Description

    Create a new guid and HOB entry definition for specifying a pre-DXE log buffer on platforms which can't use a pre-DXE AdvancedLoggerLib instance. After the advanced logger info buffer is created, the DxeCore AdvancedLoggerLib constructor will search for the guided HOB and, if found, write the contents of the buffer specified by the entry to the advanced logger buffer.

    • 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 creating the HOB and verifying that the DxeCore constructor located it.

    Integration Instructions

    N/A




  • MsWheaPkg: Add EFIAPI to relevant functions [Rebase \& FF] @makubacki (#442)
    Change Details
      ## Description

    MsWheaReportHandlerPei() is passed to ReportHwErrRecRouter() for the
    MS_WHEA_ERR_REPORT_PS_FN value where that is defined as:

    typedef
    EFI_STATUS
    (EFIAPI *MS_WHEA_ERR_REPORT_PS_FN)(
      IN MS_WHEA_ERROR_ENTRY_MD           *MsWheaEntryMD
      );

    So, MsWheaReportHandlerPei() needs to include EFIAPI as well.

    Similarly, MsWheaRscHandlerPei() needs EFIAPI due to the definition
    of EFI_PEI_RSC_HANDLER_CALLBACK.

    • 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

    • Verified results from a GCC build that reported the issue before and after
      the change.

    Integration Instructions

    N/A




📖 Documentation Updates

  • [Cherry-pick] MfciPkg: Added information about the dependency on MuVarPolicyFoundationDxe @apop5 (#448)
    Change Details
      ## Description

    Mfci has a soft dependency on MuVarPolicyFoundationDxe. The phase based variables (Target\Manufacturer, Target\Product, Target\SerialNumber, Target\OEM_01 and Target\OEM_02) are locked using
    RegisterVarStateVariablePolicy.

    Adding documentation to explicitly call out the need for the MsCorePkg's MuVarPolicyFoundationDxe to enable phase based locking.

    • 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

    Ran CI locally

    Integration Instructions

    n/a




Full Changelog: v2023110000.0.1...v2023110000.0.2