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

v2023110000.0.1

What's Changed

• remove edk2-basetools @Javagedes (#438)
  
  Change Details

    ## Description

  Removes edk2-basetools from pip-requirements.txt and any usage of it in the CISettings.py. The is done as there are changes in the build tools python source code that are available locally in BaseTools (as it is managed by Project Mu) that is not available in edk2-basetools.

  • 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 the build system continues to use the local python source

  Integration Instructions

  N/A - only effects this repository's CI system.
  

  
  

  ---

  
  

• Remove AdvancedLogger MmCoreArm dependence on global variables. @cfernald (#437)
  
  Change Details

    ## Description

  The Advanced logger Arm MM Core library may be invoked before the imagine has completed it's PeCOFF section attribute fixup. Previously this was handled by explicitly mapping the data page need for the adv logger globals to be writable, but this leads to potential infinite recursion if any of the functions in the MMU stack calls a print. Instead this change is to remove the dependence on global variables and so remove the need for external calls in these library functions.

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

  How This Was Tested

  Tested and validated presence of MM logs in serial output and adv logger buffer.

  Integration Instructions

  N/A
  

  
  

  ---

  
  

• Switch MmCoreArm advanced logger to use updated MMU functions @cfernald (#435)
  
  Change Details

    ## Description

  As part of 202311, ArmMmuLib switched to use ArmSetMemoryAttributes instead of the individual set/clear routines. This was also implemented in the MU change to converge ArmMmuStandaloneMmLib's use with ArmMmuLib. This changed fixes MmCoreArm/AdvancedLoggerLib.c to use the updated functions.

  It seems this went unnoticed originally due to issue #434

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

  How This Was Tested

  Manually tested.

  Integration Instructions

  N/A
  

  
  

  ---

  
  

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

v2023110000.0.0

What's Changed

First 202311 Mu Plus release 🎉.

• [Rebase \& FF] [Cherry-pick] Get all the missing commits from 202302 into 202311 @kenlautner (#428)
  
  Change Details

    ## Description

  Cherry-pick the commits from 202302 that are missing from 202311 since the creation of the release branch.

  • 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

  CI

  Integration Instructions

  N/A
  

  
  

  ---

  
  

• [CHERRY-PICK] Adding a more adapt python tooling for Advanced Logger v4 (#415) @kuqin12 (#424)
  
  Change Details

    # Preface

  Please ensure you have read the contribution
  docs prior to submitting the pull request. In particular,
  pull request
  guidelines.

  Description

  This change will allow the advanced logger parser to handle the v4, which would get lines from the same UEFI boot phase without intercepting each other. It will also search for the beginning of returned buffer with more sophisticated logic.

  Resolves #401

  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

  This was tested on both QEMU Q35 and proprietary hardware platform returned advanced logger buffer binary.

  Integration Instructions

  N/A

  ---

  Co-authored-by: Oliver Smith-Denny [email protected]
  (cherry picked from commit 12f028a)
  

  
  

  ---

  
  

• Fixing Advanced logger wrapping unit test @kuqin12 (#417)
  
  Change Details

    # Preface

  Please ensure you have read the contribution docs prior
  to submitting the pull request. In particular,
  pull request guidelines.

  Description

  The existing shell test will not take the disabled processors into account, thus causing the system to have false positive results.

  This change updated the logic to tick out disabled cores, removed some UT logs to avoid spamming the output and replaced all the returned status with UT_ASSERT for easier troubleshooting.

  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

  This change was tested on proprietary hardware with multiple cores.

  Integration Instructions

  N/A
  

  
  

  ---

  
  

• Updated CISettings.py to use the edk2toolext codeql helpers @kenlautner (#414)
  
  Change Details

    ## Description

  The 202311 rebase moved the codeql plugin from .pytool to Basetools. This requires a change in CISettings.py to reference the correct codeql helper functions. Instead of using the internal versions we instead move to the edk2 pytool extensions version.

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

  Integration Instructions

  N/A
  

  
  

  ---

  
  

• Update HelloWorldRustDxe to permit compiling for unit tests @joschock (#341)
  
  Change Details

    ## Description

  Update HelloWorldRustDxe to allow compiling tests.

  • Impacts functionality?
  • Impacts security?
  • Breaking change?
  • Includes tests?
    • adds a sample unit test for the HelloWorldRustDxe driver.
  • Includes documentation?

  How This Was Tested

  Cargo test executes sample unit test as expected.
  Build for UEFI target and execution QEMU work as expected.

  Integration Instructions

  N/A
  

  
  

  ---

  
  

• Use Absolute Pointer Protocol from r-efi 4.3.0 @makubacki (#336)
  
  Change Details

    ## Description

  The protocol was upstreamed to r-efi 4.3.0 and can be picked up from there now.

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

v2023020006.1.1

What's Changed

• Adding a more adapt python tooling for Advanced Logger v4 @kuqin12 (#415)
  
  Change Details

    # Preface

  Please ensure you have read the contribution docs prior
  to submitting the pull request. In particular,
  pull request guidelines.

  Description

  This change will allow the advanced logger parser to handle the v4, which would get lines from the same UEFI boot phase without intercepting each other. It will also search for the beginning of returned buffer with more sophisticated logic.

  Resolves #401

  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

  This was tested on both QEMU Q35 and proprietary hardware platform returned advanced logger buffer binary.

  Integration Instructions

  N/A

    </blockquote>
    <hr>
  </details>
  

• [CHERRY-PICK] Fixing Advanced logger wrapping unit test (#417) @kuqin12 (#423)
  
  Change Details

    # Preface

  Please ensure you have read the contribution
  docs prior to submitting the pull request. In particular,
  pull request
  guidelines.

  Description

  The existing shell test will not take the disabled processors into account, thus causing the system to have false positive results.

  This change updated the logic to tick out disabled cores, removed some UT logs to avoid spamming the output and replaced all the returned status with UT_ASSERT for easier troubleshooting.

  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

  This change was tested on proprietary hardware with multiple cores.

  Integration Instructions

  N/A

  ---

  Co-authored-by: Oliver Smith-Denny [email protected]
  (cherry picked from commit 3c47b5f)

    </blockquote>
    <hr>
  </details>
  

• [Cherry-Pick] Add call to HdwPortInitialize() when instantiating logger in DXE (#411) @kuqin12 (#422)
  
  Change Details

    ## Description

  This change adds a call to AdvancedLoggerHdwPortInitialize() when the advanced logger is created in the DxeCoreAdvancedLoggerLibConstructor(). Previously, hardware port was only initalized in AdvancedLoggerGetInfo() if the logging info structure was present at a fixed location or in a HOB; this would cause writes to the hardware port to potentially fail in the path where the logger is not initialized until the Constructor is called.

  • Impacts functionality?
  • AdvancedLoggerHdwPortInitialize() is now called in the DxeCoreAdvancedLoggerLibConstructor if the logger is instantiated there.
  • Impacts security?
  • Breaking change?
  • Includes tests?
  • Includes documentation?

  How This Was Tested

  Verified on a platform where this was not working due to missing HdwPort initialization; verified after this patch that it works as expected.

  Integration Instructions

  N/A
  

  
  

  ---

  
  

• Update pip-requirements.txt @Javagedes (#421)
  
  Change Details

    ## Description

  Updates edk2-pytool-extensions and edk2-pytool-library to work with the latest commit of MU_BASECORE

  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

  N/A

  Integration Instructions

  N/A

    </blockquote>
    <hr>
  </details>
  

Full Changelog: v2023020006.1.0...v2023020006.1.1

v2023020006.1.0

What's Changed

🚀 Features & ✨ Enhancements

• AdvLoggerPkg: 64-bit SEC \& PEI Changes [Rebase \& FF] @makubacki (#403)
  
  Change Details

    ## Description

  1. AdvLoggerPkg: 64-bit SEC & PEI C Code changes

     C code changes for building the code as 64-bit.

  2. AdvLoggerPkg/SecDebugAgent: Update for 64-bit

     Allows the module to be built for 64-bit SEC.

  • 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

  • Platform with X64 SEC & PEI

  Integration Instructions

  N/A - Appropriate code will be built based on module architecture.

  ---

  Note: In draft while testing is in progress.
  

  
  

  ---

  
  

Full Changelog: v2023020006.0.2...v2023020006.1.0

v2023020006.0.2

What's Changed

• Removed references to openssllib and it's associated libraries @kenlautner (#410)
  
  Change Details

    ## Description There are some references to BaseCryptLib and Openssl in package dsc files. In MU_BASECORE Openssl and its BaseCryptLib implementations were removed so we need to update to using the NULL lib.

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

  Integration Instructions

  N/A
  

  
  

  ---

  
  

Full Changelog: v2023020006.0.1...v2023020006.0.2

v2023020006.0.1

What's Changed

• Wrap advanced logger buffer cursor when the logging area is full @kuqin12 (#408)
  
  Change Details

    ## Description

  The advanced logging at runtime is lack of usage. However, this becomes increasingly important for server platforms, where the system could potentially stay up for months, or even years. This will make the advanced logger fill up the buffer during runtime/MM logging well ahead of a reset event, making the buffer content stale when being reviewed.

  This change added a feature PCD guarded feature that, when enabled, will automatically wrap the LogCurrent cursor to the beginning and continue to log. This will effectively create a circular buffer as the stale content will remain in place. The tooling update is still under development.

  • 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

  This was tested on QEMU Q35 along with the UEFI shell based test app to verify that the entry after wrapping is correct and is multi-threading safe.

  Integration Instructions

  Platforms can enable this feature by setting gAdvLoggerPkgTokenSpaceGuid.PcdAdvancedLoggerAutoClearEnable|TRUE
  

  
  

  ---

  
  

• .git-blame-ignore-revs: Ignore Line Ending and Uncrustify only commits @makubacki (#404)
  
  Change Details

    ## Description

  Adds commits that only applied Uncrustify formatting or converted
  line endings to a .git-blame-ignore-revs file so they are ignored
  by git blame. This is supported by GitHub:
  https://github.blog/changelog/2022-03-24-ignore-commits-in-the-blame-view-beta/

  This helps clean up git blame by filtering out these changes.

  Note: This file needs to be updated on rebase branches. Processes
  like filter-branch can automatically update relevant SHAs.

  • 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

  • git blame

  Integration Instructions

  N/A
  

  
  

  ---

  
  

🐛 Bug Fixes

• Fixing uninitialized variable build error @kuqin12 (#406)
  
  Change Details

    ## Description

  267e27f change introduced a build error on certain platforms, due to a local variable being used uninitialized. This change will set the variable to 0 before usage.

  • 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

  This change is tested with LineParserTestApp on QEMU Q35 platform.

  Integration Instructions

  N/A
  

  
  

  ---

  
  

🔐 Security Impacting

• Fixing uninitialized variable build error @kuqin12 (#406)
  
  Change Details

    ## Description

  267e27f change introduced a build error on certain platforms, due to a local variable being used uninitialized. This change will set the variable to 0 before usage.

  • 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

  This change is tested with LineParserTestApp on QEMU Q35 platform.

  Integration Instructions

  N/A
  

  
  

  ---

  
  

Full Changelog: v2023020006.0.0...v2023020006.0.1

v2023020006.0.0

What's Changed

⚠️ Breaking Changes

• Add prefix for advanced logger memory message entries @kuqin12 (#388)
  
  Change Details

    # Preface

  Please ensure you have read the contribution docs prior
  to submitting the pull request. In particular,
  pull request guidelines.

  Description

  This change introduces a new message entry structure, which contains extra information of log producer and can be used to differentiate the different boot phases, i.e. PEI, DXE, SMM, etc. Platforms that have multiple firmware entities can leverage this extra information to distinguish coalesced memory logging regions.

  The updated applications (UEFI shell app and host OS Python script) are also updated to support new message entry structure while maintaining the backwards compatibility.

  Resolves #375.

  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

  This change was tested on QEMU Q35 and verified that prefix are properly injected for DXE phase prints.

  Integration Instructions

  The log parsers are updated, thus platforms use the existing parser should pick up the latest tool from mu_plus. For platforms that carry their own implementation, they should add the proper support in their own implementation before picking up this change from mu_plus.
  

  
  

  ---

  
  

Full Changelog: v2023020005.0.0...v2023020006.0.0

v2023020005.0.0

What's Changed

⚠️ Breaking Changes

mu_plus commit f535499 creates DXE and SMM instances of MemoryProtectionTestApp, and updates the naming of the support driver for the SMM test app. This split is to support testing for platforms which do not use SMM.

Instances of the following will need to be DELETED
UefiTestingPkg/FunctionalSystemTests/MemoryProtectionTest/App/MemoryProtectionTestApp.inf
UefiTestingPkg/FunctionalSystemTests/MemoryProtectionTest/Smm/MemoryProtectionTestSmm.inf

The following will need to be ADDED for unit test builds
​UefiTestingPkg/FunctionalSystemTests/MemoryProtectionTest/App/DxeMemoryProtectionTestApp.inf

If the platform uses SMM, add this to the platform DSC
UefiTestingPkg/FunctionalSystemTests/MemoryProtectionTest/App/SmmMemoryProtectionTestApp.inf

And this to both the platform DSC and FDF files
​UefiTestingPkg/FunctionalSystemTests/MemoryProtectionTest/Driver/SmmMemoryProtectionTestDriver.inf

• Remove Pre-Split MemoryProtectionTestApp Files @TaylorBeebe (#405)
  
  Change Details

    ## Description

  f535499 split the MemoryProtectionTestApp into DXE and SMM instances but did not delete the old files to give consumers time to update their platform DSC files. This PR is the breaking change which removes the old files.

  • 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

  N/A

  Integration Instructions

  N/A
  

  
  

  ---

  
  

Full Changelog: v2023020004.1.2...v2023020005.0.0

v2023020004.1.2

What's Changed

• DxePagingAudit: Skip Stack Publishing if Stack Info Isn't Valid @TaylorBeebe (#400)
  
  Change Details

    ## Description

  The MemoryInfoDatabase.dat file contains information about the content of memory regions. If an entry in the database file is invalid, it will break the generation of the paging audit. Before adding the stack info to the database file, check that the stack size is greater than zero.

  • 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 by generating the paging audit

  Integration Instructions

  N/A
  

  
  

  ---

  
  

• [REBASE \&\& FF] FlatPageTableLib and DxePagingAuditTestApp Updates @TaylorBeebe (#395)
  
  Change Details

    ## Description

  This change set was primarily created to improve the accuracy of the DXE paging audit shell test. The problem was two-fold:

  1. The layout of memory would change as data was collected. This is solved by pre-allocating space for two of the memory maps (flat page table and EFI memory map). Those two maps will have their size requirement checked at the start of each function to ensure enough heap space has been allocated for them prior to populating them with memory information.
  2. The shell test was imprecise when reporting which regions failed the various tests. I'll use the UnallocatedMemoryIsRP() test as an example. The test parses the EFI memory map for EfiConventionalMemory regions which indicate unallocated memory. If any subsection of the region was not read protected, then the entire region would be reported as failing. With this update, every subsection which does not comply will be individually reported giving platform developers more precise information on where the problem areas are.

  Patch breakdown:

  1. Updates the DXE paging audit to always write out all .dat files even if the buffers are empty. The presence of the file acts as a receipt that the audit was run successfully and helps with automated unit testing.
  2. Adds a function to FlatPageTableLib to dump the contents of a flat page table to the console. This is useful for debugging.
  3. Updates GetRegionAccessAttributes() in FlatPageTableLib to return the attributes of the first attribute-contiguous range found in the region and report the actual size of that range. This allows the caller to collect the attributes of the region by calling the function repeatedly instead of needing to guess which subsection of the region has contiguous attributes.
  4. Updates the DXE paging audit shell tests to pre-allocate memory for memory maps. The page table map, EFI memory map, and EFI memory space map all describe the layout of the system address space. Because of this, if allocations are performed while these maps are being generated, then the maps generated the earliest will be inaccurate.
  5. Adds ValidatePageTableAttributes() to the DXE paging audit shell test logic. This function validates the attributes of the input memory region. It uses GetRegionAccessAttributes() to get the attributes of the region and compares them to the attributes passed in. This function will be used by each test case to check that the page/translation table attributes match the memory protection requirements and enables more precise reporting of regions which do not match the requirements.
  6. Updates the DXE paging audit shell tests to use ValidatePageTableAttributes() to determine policy compliance.

  How This Was Tested

  This was tested on Q35 and an ARM platform. Some changes in test caused the UnallocatedMemoryIsRP() test to erroneously fail due to reason 1 above which has been fixed with this patch set. Additionally, this patch set was checked by comparing the shell test output to the full HTML paging audit to verify that errant regions are exact and consistent.

  Integration Instructions

  N/A
  

  
  

  ---

  
  

🐛 Bug Fixes

• Fix DxePagingAuditTestApp Typo, Update FlatPageTableLib AARCH64 IsPageReadable() Check @TaylorBeebe (#402)
  
  Change Details

    ## Description

  DxePagingAuditTestApp: When checking an image section characteristics, a bitmasking is done which incorrectly includes a logical OR instead of a bitwise OR.
  FlatPageTableLib: The AARCH64 IsPageReadable() routine correctly checks for the no access, r/w case (0b00) but not the r/w, r/w case (0b01) because both 0b11 and 0b01 would pass the latter check.

  • 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 a Surface ARM platform and SBSA

  Integration Instructions

  N/A
  

  
  

  ---

  
  

Full Changelog: v2023020004.1.1...v2023020004.1.2