v2023020006.1.2

What's Changed

• Add StackCheckLib Instances to Platform DSC Files @TaylorBeebe (#446)
  
  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
  

  
  

  ---

  
  

• [CHERRY-PICK] MsWheaPkg: Add EFIAPI to relevant functions [Rebase \& FF] @makubacki (#443)
  
  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

• Added information about the dependency on MuVarPolicyFoundationDxe @apop5 (#378)
  
  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: v2023020006.1.1...v2023020006.1.2