v2023020001.3.0

What's Changed

🚀 Features & ✨ Enhancements

• Add Rust Support and Advanced Logger Crate [Rebase \& FF] @makubacki (#289)
  
  Change Details

    Closes #294

  Description

  Updates the repo to add some files needed to support Rust builds and a RustAdvancedLoggerDxe library crate.

  Because this repo was used to test the Rust build and is adding a new crate in that process, the infrastructure files are added directly in this PR. In the future, these will be synced from mu_devops. The file content aligns with the current templates in mu_devops so there should be no change in the sync process in this repo. Future repos can simply sync the files with the bot accounts and then add the Rust code in a follow up PR.

  The ability to build with Rust is temporarily disabled in the last commit of the PR branch because changes in mu_devops need to be completed before the pipeline build in this repo will succeed.

  Commit/Change Overview

  ---

  Add initial Rust infrastructure files

  Adds workspace level files to build Rust in the repo.

  ---

  .azurepipelines: Add Rust build support

  Makes the changes needed to build Rust in pipelines on Windows
  and Linux.

  ---

  AdvLoggerPkg: Add RustAdvancedLoggerDxe

  Adds a library crate that serves as a Rust wrapper for access to
  Advanced Logger protocol.

  ---

  • 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

  • Built container image from mu_devops locally with docker
  • Ran container image locally to perform a Rust build
  • Ran all changes in this PR in mu_plus pipelines to verify build results
    • Linux build with Rust
    • Linux build without Rust
    • Windows build with Rust

  Integration Instructions

  No changes are needed for mu_plus integrators.

  Review general Rust documentation in mu_basecore for more info.
  

  
  

  ---

  
  

Full Changelog: v2023020001.2.0...v2023020001.3.0

v2023020001.2.0

What's Changed

🚀 Features & ✨ Enhancements

• Add TpmTestingPkg and TPM Replay feature [Rebase \& FF] @makubacki (#287)
  
  Change Details

    ## Description

  Contains four commits:

  ---

  TpmTestingPkg: Add initial package

  Adds a new package that holds TPM testing functionality.

  Currently, a feature is present called "TPM Replay" that provides
  the ability to replay TPM measurements from a custom-made event log.

  The primary purpose is for testing operating system features
  dependent on TPM measurements. More details about this feature are
  available in TpmTestingPkg/TpmReplayPeiDxe/Readme.md.

  This feature is designed to ease platform integration and can be
  applied to physical and virtual systems.

  ---

  TpmTestingPkg: Remove DXE functionality

  Removes DXE placeholders since they are currently not used. This
  commit is left in source history to show where DXE functionality
  would hook into the code flows if added in the future.

  ---

  TpmTestingPkg: Add TPM Replay tool

  Adds a new tool that allows a user to specify a TPM Event Log in
  JSON or YAML (validated against a supplied schema) that is transformed
  into a binary that can be used by the TPM Replay feature.

  A binary can also be transformed back to a YAML file.

  This is an initial draft of the tool. Some files or code will likely
  move to other more generic repos, the schema to a public schema
  store, and new features are planned to be added as well. For example,
  some PCR7 events will allow individual UEFI variable details to be
  specified in the input JSON/YAML file to make their creation more
  clear.

  While this is planned, the initial draft provides sufficient
  functionality to use with the feature and share with others now.

  ---

  .azurepipelines: Add TpmTestingPkg

  Includes the package in the pipeline build.

  Rebalances the build matrix taking the new package into account.

  ---

  • 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

  • Input YAML to binary
  • Input JSON to binary
  • Input binary to YAML
  • Replay events on QEMU Q35 to PCRs
  • Verify event log in OS against the input file

  Example: YAML to Binary and Binary Back to YAML

  
  (click the image to enlarge it)

  Example: Viewing the Replayed Log in Windows

  

  Integration Instructions

  N/A
  

  
  

  ---

  
  

Full Changelog: v2023020001.1.2...v2023020001.2.0

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.