v2023020001.1.2

What's Changed

• AdvLoggerPkg: Switch to using AsciiStrnLenS @apop5 (#293)
  
  Change Details

    ## Description A compounds assert was found in a platform. An assert was triggered, and when attempting to generate the assert messages, print lib triggered an assert as well. The system was found to have reached the PcdMaximumAsciiStringLength referenced in AsciiStrLen.

  To combat this, the AsciiStrLen calls in AdvancedLogger are being switched to use the safe version, with the associated max lengths being the stack buffers that are used in the functions.

  This change allowed assert messages to be displayed.

  Fixes #292

  • 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 platform that was triggering asserts.
  Tested in CI

  Integration Instructions

  N/A - Changes should be
  

  
  

  ---

  
  

• Update UXN/PXN Parsing and Fix Filters in Paging Audit @TaylorBeebe (#290)
  
  Change Details

    ## Description

  1. Update the HTML/Javascript filters for RWX to not include GcdNonExistent regions
  2. Combine the UX and PX fields into one Execute field to make it easier to check for RWX regions
  3. Update the filters to not fail if the multiselect call fails to select all options. This can occur if one of the options does not exist in the paging audit.

  • 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

  Running the paging audit on Q35 and SBSA

  Integration Instructions

  N/A
  

  
  

  ---

  
  

Full Changelog: v2023020001.1.1...v2023020001.1.2

v2023020001.1.1

What's Changed

• MsGraphicsPkg/FrameBufferMemDrawLib: Fix function declaration mismatch @makubacki (#282)
  
  Change Details

    ## Description

  Fixes the following issues with GetGraphicsInfo().

  1. Removes EFIAPI. This is an internal function to the library
     implementation and the explicit calling convention is not needed.
     In turn, this makes the function prototype in the C files match
     the header file.
  2. Add an include guard to the local library header file.

  Resolves the following GCC warning:

  MsGraphicsPkg/Library/FrameBufferMemDrawLib/FrameBufferMemDrawLib.h:16:1:
  warning: type of ‘GetGraphicsInfo’ does not match original declaration [-Wlto-type-mismatch]
  16 | GetGraphicsInfo (
  | ^

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

  Integration Instructions

  N/A
  

  
  

  ---

  
  

🐛 Bug Fixes

• PcBdsPkg: Fix previous CodeQL change (51c7dc2) @kenlautner (#280)
  
  Change Details

    ## Description

  Fixes a previous CodeQL fix (51c7dc2) that was checking for NULL return values. In this case a NULL return value is valid so instead of returning a bogus boot option let the function continue.

  • 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 Physical hardware devices to confirm boot. Also confirmed CodeQL passes.

  Integration Instructions

  N/A

    </blockquote>
    <hr>
  </details>
  

• Add a check on the `PcdAdvancedFileLoggerFlush` for exit boot services @kuqin12 (#277)
  
  Change Details

    ## Description

  The definition of PcdAdvancedFileLoggerFlush mentioned this should be a bitmask for both exit boot services and ready to boot. However, the bit for exit boot services was ignored and a callback was registered regardless of the setting.

  This change adds a check to honor the PCD setting and removed the duplicated definition from package dec file.

  • 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 Q35 platform and booted to Windows.

  Integration Instructions

  N/A

    </blockquote>
    <hr>
  </details>
  

Full Changelog: v2023020001.1.0...v2023020001.1.1

v2023020001.1.0

What's Changed

🚀 Features & ✨ Enhancements

• Close ReadyToBoot and ExitBootServices events if a reset is notified. @joschock (#275)
  
  Change Details

    ## Description

  Close the ReadyToBoot and ExitBootServices events in the reset notification. This prevents the file logger from trying to access the file system after its reset notification has run in the event that the platform implementation invokes one of those notifications in the reset path (which it shouldn't, but some do).

  • Impacts functionality?
    • Should not impact functionality since the reset notification is expected to be the last point at which file log can be flushed on most architectures.
  • Impacts security?
    • No security impact
  • Breaking change?
    • Not breaking change.
  • Includes tests?
    • No tests included as no new functionality is introduced.
  • Includes documentation?
    • No docs changed as no new functionality is introduced.

  How This Was Tested

  Executed reset, confirmed that file log is flushed as expected. On a system that also invokes the exit boot services notification in the reset path, confirmed that log file is not flushed in the exit boot services notification. Confirmed that on normal boot path to OS, log flush is executed in the exit boot path notification.

  Integration Instructions

  N/A

    </blockquote>
    <hr>
  </details>
  

Full Changelog: v2023020001.0.1...v2023020001.1.0

v2023020001.0.1

What's Changed

• Added logic to delete the Memory Type Information variable on a capsule update. @kenlautner (#271)
  
  Change Details

    ## Description

  Added logic to delete the Memory Type Information variable on a capsule update. This is because in rare circumstance where a new memory type is added (or a memory type is removed) a capsule update will cause a mismatch of memory types. Removing the variable and thus forcing a clean memory bucket discovery solves this issue.

  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 on a platform where there is a capsule update between two versions of firmware with a different amount of memory types. Without this change the transition from temp ram to permanent memory breaks but with this change the device correctly goes to the default memory bucket configuration and is able to boot.

  Integration Instructions

  N/A

    </blockquote>
    <hr>
  </details>
  

• ci.yaml: add PrEval entry @Javagedes (#267)
  
  Change Details

    ## Description

  Adds PrEval entries for all packages to enable the new PrEval Policy 5.

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

🔐 Security Impacting

• [CHERRY-PICK] Fix CodeQL errors @kenlautner (#274)
  
  Change Details

    ## Description

  Fixed some CodeQL failures we're seeing in a variety of packages.

  • 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 through CodeQL checks.

  Integration Instructions

  N/A

    </blockquote>
    <hr>
  </details>
  

Full Changelog: v2023020001.0.0...v2023020001.0.1

v2023020001.0.0

What's Changed

⚠️ Breaking Changes

• AdvLoggerPkg: fix AdvLoggerSerialPortLib class @Javagedes (#268)
  
  Change Details

    ## Description

  AdvLoggerSerialPortLib was using a library class that was not a true library class (not defined in any .dec file or have an associated .h).

  This changes the library class to use the correct library class, SerialPortLib.

  • 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

  Successfully build multiple platforms and pass the newly added BaseTools change for verifying library override class names.

  Integration Instructions

  Any library class definitions in a dsc using AdvLoggerSerialPortLib needs to be switched to SerialPortLib.
  

  
  

  ---

  
  

Full Changelog: v2023020000.1.0...v2023020001.0.0

v2023020000.1.0

What's Changed

• [REBASE \&\& FF] Cherry-Pick BootAuditTestApp Update and DxePagingAuditTestApp Update from 202208 @TaylorBeebe (#258)
  
  Change Details

   

  ---

• Onboarding ARM64 builds on selfhosted Azure pipeline agents @kuqin12 (#240)
  
  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 added a few new matrix entries to support building mu_tiano_platforms on native ARM64 systems. The PR will cover both microsoft/mu_basecore#369 and microsoft/mu_basecore#305.

  The PR should also be incorporated with mu_devops change.

  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 selfhost-agents and existing agents.

  Integration Instructions

  Pipeline changes, N/A for integration.

    </blockquote>
    <hr>
  </details>
  

🚀 Features & ✨ Enhancements

• [CHERRY-PICK] Remove bootmode from con var update 202302 [Rebase \& FF] @makubacki (#260)
  
  Change Details

    ## Description

  Cherry picks commits from PR #259 into release/202208 into release/202302.

  Some platforms may not reach BDS on a boot mode expected by the
  current implementation to update the ConIn variable with a new
  console input device.

  For example, support for a new device might be added in a firmware
  update, the update is performed, and the system is reset one or
  more times before reaching PlatformBootManagerBeforeConsole().

  This change always evaluates a potential update to ConIn regardless
  of boot mode to reduce ConIn update complexity.

  • 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 and boot with the change. Since only the boot mode check
  is removed, the underlying behavior within the boot mode condition remains
  the same

  Integration Instructions

  Review the change to when console may be updated relative to boot mode in
  change and the implementation of EfiBootManagerUpdateConsoleVariable()
  being used by the platform to determine if you would like to make any
  changes to that function. No required changes are expected.
  

  
  

  ---

  
  

Full Changelog: v2023020000.0.0...v2023020000.1.0

v2023020000.0.0

What's Changed

This is the first MU Plus 202302 release 🎉

The previous branch was 202208.

These versions correspond to edk2 stable release tags that the code is based upon.

Since edk2 makes a release every 3 months, two stable tags were actually picked up in this release:

• edk2-stable202211
• edk2-stable202302

Review those release notes to understand the changes coming in from edk2. In addition, Mu repos highlight important changes in their Readme files. Review the 202302 Readme before you move code to this branch to understand major changes.