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 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
- HidPkg build and QEMU Q35 shell boot
Integration Instructions

N/A

HidPkg/UsbHidDxe: Continue on failure to get descriptor @makubacki (#334)
Change Details
## Description
In case a HID device fails to return a valid HID descriptor, this change
will return the error status from UsbHidDriverBindingStart() rather
than assert to match previous behavior from HID drivers that required
the boot protocol. The HID IO protocol will not be installed on these
devices.
- 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 functionality is unchanged on physical platform with UsbHidDxe integrated.
- Verified boot previously encountering an assert on the QEMU virtual platform is
  not blocking boot.
Integration Instructions

Update to a Mu Plus release with this change.

[REBASE \&\& FF] Update DxePagingAuditTestApp with Additional Shell and HTML Tests @TaylorBeebe (#327)
Change Details
Adds 8 tests to the paging audit shell app. Which check the following: 1. Unallocated memory is EFI_MEMORY_RP 2. Memory Attribute Protocol is present 3. Calls to allocate pages and pools return buffers with restrictive access attributes 4. NULL page is EFI_MEMORY_RP 5. MMIO Regions are Non Executable 6. Image code sections are EFI_MEMORY_RO and and data sections are EFI_MEMORY_XP 7. BSP stack is EFI_MEMORY_XP and has EFI_MEMORY_RP guard page 8. Memory outside of the EFI Memory Map is inaccessible
Adds 5 tests to the HTML templates:
1. Test that the NULL page is EFI_MEMORY_RP
2. Check that MMIO memory is non-executable.
3. Check that EfiConventionalMemory is non-executable.
4. Check that memory not in the EFI memory map is not accessible.
5. Check that the memory attribute protocol is present on the platform.
This also refactors much of the HTML, adds some quality of life updates to the output
HTML paging audit, adds logical OR filtering capability, and adds the collection of
Memory Attribute Protocol presence on the tested platform.

Tested on Q35, SBSA, and on development devices at UEFI Plugfest.

Only call HdwPortWrite if DebugLevel Met @os-d (#311)
Change Details
## Description
The DebugLevel is checked twice in the hot path on serial path writes and the HdwPortWrite call is made even if the upper layer knows that the message being logged does not meet the DebugLevel criteria.

Closes #309.

In order to maintain backwards compatibility, if the LoggerInfo block is found to have a version less than the hardware logging level version, the PCD is checked to decide whether to call HdwPortWrite or not.

In SEC, because we may not have the LoggerInfo structure, we check the PCD to see if the message should be logged at this DebugLevel.

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

Build tested.

Integration Instructions

If a bespoke AdvLoggerHdwPortLib is used, AdvLoggerHdwPortWrite should not check DebugLevel, but simply write the message to the hardware port.

Feature/MsApplicationPkg/SecureBootRecovery @Flickdm (#323)

Change Details

Description This Secure Boot Recovery application, when ran will append a 2011 KEK signed 2023 Certificate to the DB. This may be used to fix the DB for in market devices in order to boot a 2023 signed Boot loader.
Impacts functionality?
N/A
Impacts security?
N/A
validation improvement, ...
Breaking change?
N/A
Includes tests?
N/A
Includes documentation?
Readme.md
Explains how to build the application
How This Was Tested
This was tested on a handful of in market devices (AARCH64 and X64) by different OEMS.

This was tested using test payloads and the real payload in order to verify it would work as expected

Integration Instructions
N/A

Integrate UefiCpuLib breaking change @makubacki (#304)
Change Details
## Description
Updates the repo for a change that merged UefiCpuLib with CpuLib.

UefiCpuLib will be removed entirely soon so all references are updated to CpuLib.
- 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
- Repo CI build
- Platform integration build (in QemuQ35Pkg)
Integration Instructions

N/A

[REBASE \&\& FF] Publish and Parse PlatformInfo.dat in Paging Audit @TaylorBeebe (#299)

Change Details

1. Create the PlatformInfo.dat file which contains the required platform information to parse the page/translation tables (bitwidth, execution level, phase, architecture). 2. Check the execution level when parsing AARCH64 translation tables in the paging report generator scripts.
These patches will fix the paging audit test failure on SBSA, and will reduce the number of command line options which need to be passed into the page parsing scripts.

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

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

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

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

[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.

[CHERRY-PICK] Take changes from 202208 into 202302 [Rebase \& FF] @kenlautner (#245)
Change Details
## Description
Cherry-picked changes from 202208 into 202302.

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

Built and booted a physical platform with these changes.

Integration Instructions

N/A

Continue power management on disabled APs @kuqin12 (#243)
Change Details
# Preface
Please ensure you have read the contribution docs prior
to submitting the pull request. In particular,
pull request guidelines.

Description

Current implementation will stop the execution on the APs that are disabled. This behavior will prevent the test suites from full validation, as some cores might be disabled by design.

This change will add a check prior to core power management operations and proceed with the other cores if the AP of interest is disabled.

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 ARM FVP virtual platform with 16 cores. A shell based unit test is used for validation.

Integration Instructions

N/A

Use Mu DevOps @makubacki (#73)
Change Details
## Description
Updates this repo to use mu_devops for Azure Pipeline definitions.

In order to centralize definitions and avoid build churn in individual Mu repos,
some changes are made to allow build administrators to quickly adjust settings:
- Toolchain, VM image, and architecture are controlled by build administrators through centralized
  variable groups
- CI triggers, CI schedules, and PR triggers are controlled by build administrators within the
  individual pipeline UI settings
- Breaking change?
  - Will this change break pre-existing builds or functionality without action being taken?
    No
How This Was Tested

Verified in test pipelines.

Integration Instructions

N/A - No developer integration required

Signed-off-by: Michael Kubacki [email protected]

Updated pipelines to only run CI and PR gates on release/202208 and r… @kenlautner (#71)
Change Details
…elease/202202
Description

Updated pipelines to only run CI and PR gates on release/202208 and release/202202.
- Breaking change?
  No.
How This Was Tested

Pipelines passed.

Integration Instructions

N/A

[CHERRY-PICK] Fix Line Endings in Repo (LF -> CRLF) @makubacki (#68)
Change Details
## Description
Converts line endings in the following packages:
- AdvLoggerPkg: Fix line endings (LF to CRLF)
- DfciPkg: Fix line endings (LF to CRLF)
- HidPkg: Fix line endings (LF to CRLF)
- MfciPkg: Fix line endings (LF to CRLF)
- MsCorePkg: Fix line endings (LF to CRLF)
- MsGraphicsPkg: Fix line endings (LF to CRLF)
- MsWheaPkg: Fix line endings (LF to CRLF)
- PcBdsPkg: Fix line endings (LF to CRLF)
- UefiTestingPkg: Fix line endings (LF to CRLF)
- XmlSupportPkg: Fix line endings (LF to CRLF)
- ZeroTouchPkg: Fix line endings (LF to CRLF) (cherry picked from commit a6195ca in release/202202)
- Breaking change?
  - Will this change break pre-existing builds or functionality without action being taken?
    POSSIBLY - Tools might break that depended on LF line endings.
How This Was Tested

Verified CI build results. Checked new line endings.

Integration Instructions

Rerun tools that parse source files to ensure they handle the new line endings appropriately.

(cherry picked from commit a6195ca in release/202202)

Signed-off-by: Michael Kubacki [email protected]

AdvancedLogger DxeCore - set mBufferSize if AdvancedLoggerGettLoggerI… @antklein (#58)
Change Details
AdvancedLogger DxeCore - set mBufferSize if AdvancedLoggerGettLoggerInfo returns NULL
Description
- Update AdvancedLoggerPkg AdvancedLoggerLib DxeCore variant to set mBufferSize if AdvancedLoggerGetLoggerInfo returns NULL.
- Breaking change?
  - Will this change break pre-existing builds or functionality without action being taken?
    No, this is not a breaking change.
How This Was Tested
- Verified on Surface Arm platform.
Integration Instructions

N/A

Add dependabot @makubacki (#52)
Change Details
## Description
To keep pip dependencies up to date.
- Breaking change?
  - Will this change break pre-existing builds or functionality without action being taken?
    No
How This Was Tested

Confirmed file matches contents of the file working in other repos.

Integration Instructions

N/A - Only updates this repo

Signed-off-by: Michael Kubacki [email protected]

Add Host Based Unit Tests for HidMouseAbsolutePointerDxe @spbrogan (#49)

Change Details

Add Host-based unit tests for the HidMouseAbsolutePointerDxe to make sure HID report format parsing is correct and robust.

Use Python 3.10.6+ @makubacki (#51)
Change Details
## Description
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3891

Changes the Python version used in pipelines to 3.10.6 or greater
since that version introduces a fix (bp0-47231) for inconsistent
trailing slashes in tarfile longname directories.

This is required for stuart_update to succeed when handling a
web_dependency (e.g. GCC ARM compilers).
- Breaking change?
  - Will this change break pre-existing builds or functionality without action being taken?
    No
How This Was Tested

Verified in CI builds

Integration Instructions

Determine if moving from Python 3.8 to 3.10 impacts any scripts

Signed-off-by: Michael Kubacki [email protected]

Add Pull Request template @makubacki (#50)

Change Details

Adds a template so consistent sets of information can be provided across pull requests.

UpdateFacsHardwareSignatureLib: Initialize NULL variables before use @antklein (#47)

Change Details

Initialize Buffer and PciHandleBuffer to NULL before use. No functional changes. This fixes CLANG build errors.
File: UpdateFacsHardwareSignatureLib.c
337: CleanUp:
338: //
339: // Step 12. Free buffers
340: //
341: if (PciHandleBuffer != NULL) {
342: FreePool (PciHandleBuffer);
343: }
344:
345: if (Buffer != NULL) {
346: FreePool (Buffer);
347: }

Fix some comments and unnecessary includes in HidKeyboardDxe @joschock (#45)

Change Details

Minor code cleanup for HidPkg. - Removed unused UsbIo.h include - Removed incorrect references to USB in comments.

Move architectural diagram into Docs directory @joschock (#43)

Change Details

Remove gEfiEventPreReadyToBootGuid from Dfci @spbrogan (#42)

Change Details

This guid is not used by these modules and therefore should not be declared a dependency. Extra dependencies like this are incorrect and make the code harder to integrate into other code bases.

MfciPkg: enforce spell check, fix spelling, add exceptions where needed @out0xb2 (#39)
Change Details
MfciPkg spelling update
- CI build will no longer "audit" spelling issues, they will cause CI to fail
- Spelling errors fixed
- Real terms added to dictionary

Add instance of MfciDeviceIdSupportLib that leverages SMBIOS @out0xb2 (#38)

Change Details

Adds an instance of MfciDeviceIdSupportLib that leverages SMBIOS Details and usage can be found in the ReadMe.md adjacent to the library and also part of this PR

Document OpenSSL cipher change for DFCI @out0xb2 (#34)

Change Details

We needed to add support for ECDHE as part of TLS modernization. Adding a reference in the DFCI docs.

[SharedCrypto] Fix SharedNetwork typos in md files @makubacki (#32)

Change Details

Updates markdown documentation in SharedCryptoPkg to fix incorrect references to SharedNetwork related code.

Avoid extra string manipulation for gEfiStatusCodeDataTypeStringGuid @joschock (#31)

Change Details

This PR changes the implementation of SerialStatusCodeHandler so that pre-formatted strings (such as ones passed from FSP) don't use AsciiSprint() and are instead passed straight to the writer routine.

Updating links \& minor tweaks @out0xb2 (#29)

Change Details

Relicense entire repo for BSD2+Patent to align with TianoCore @corthon (#27)

Change Details

Changing the status returned by RequestToLock in Foundation. @corthon (#24)

Change Details

VariablePolicy Disabled is considered a valid condition, but the RequestToLock interface to VariablePolicy would return an error if Disabled. This wouldn't be a problem normally, but many places will ASSERT if RequestToLock returns an error.
This may be re-evaluated in the future, but it should also encourage drivers to move away from VariableLockProtocol and towards VariablePolicyProtocol.

Replacing GCC\_CC\_XIP flags for MathLib to allow floating point operations @mknutsen (#23)

Change Details

[Feature] Added SharedCrypto (drop-in replacement for BaseCryptLib) @matthewfcarlson (#22)

Change Details

This uses a precompiled EFI's to speed up compile times when using OpenSSL and decrease space used. This approach can be used by other crypto Libraries other than OpenSSL as long as they conform to the API of BaseCryptLib.

Add bars for Platform Mode 2 \& 3 and remove STATE\_UNDEFINED color bar @joschock (#21)

Change Details

Provide two additional Platform color bars (Indigo and Brown) and remove STATE_UNDEFINED so we can repurpose its color for one of the platform color bars.

Fix for indexing problem in FilterHandles @joschock (#10)

Change Details

MsGraphicsPkg: Fix incorrect parameters in DEBUG macro. @tsunghowu (#9)

Change Details

When compiling the code with GCC 7, found couple of coding errors on using DEBUG macro.

Fix an issue where an empty grid can cause a bad pointer dereference @joschock (#8)

Change Details

Fix case sensitivity for markdown image @AaronAntone (#7)

Change Details

PNG now shows correctly on systems where case sensitivity matters for file names

Fixing DfciPkg build @kuqin12 (#4)

Change Details

Fixing DfciPkg build by changing library class of FileHandleLib

Adding introductory DFCI documentation @out0xb2 (#1)

Change Details

⚠️ Breaking Changes

Add PCD to allow device exclusions for UsbHidDxe @joschock (#340)

Change Details

## Description

Adds a PCD for configuring device exclusions for UsbHidDxe. Prior to this change, the UsbHidDxe driver included logic to exclude keyboard devices from being handled by HID, due to other parts of the stack not being fully implemented yet. This removes that code and replaces it with a PCD list that the platform integrator can use to disable particular devices as desired for the platform.

Impacts functionality?
- Changes how UsbHidDxe exclusions are handled.
Impacts security?
Breaking change?
Previously keyboard exclusion was hard-coded; to replicate this behavior platforms will need to add a PCD specification in the DSC files to exclude keyboards. See Integration Instructions below for more details.
Includes tests?
Includes documentation?

How This Was Tested

Verified with functional testing of several different exclusions in Qemu Q35.

Integration Instructions

Platforms will need to add PCD specification to the DSC like the following to exclude USB keyboards:

[PcdsFixedAtBuild]
  gHidPkgTokenSpaceGuid.PcdExcludedHidDevices|{0x3, 0x1, 0x1, 0x0, 0x0, 0x0}
``

To replicate existing behavior.
      </blockquote>
      <hr>
    </details>
  </li>
</ul>
<ul>
  <li>
    [REBASE \&\& FF] Add FlatPageTableLib, Make Spellcheck Fixes, Update Paging Audit to Use FlatPageTableLib @TaylorBeebe (#322)
    <br>
    <details>
      <summary>Change Details</summary>
      <blockquote>
        <!-- Non-breaking space to have content if body is empty -->
        &nbsp; ## Description

Makes some spellcheck fixes.

Creates a new library, FlatPageTableLib, which works on X64 and AARCH64 platforms and converts the page table to a "flat" version. The flat version is a one-dimensional array where each entry is an address, a length, and attributes. The library will walk the page/translation table and combine blocks/leaves with the same attributes into a single entry in the flat array. The attributes mask for each architecture is defined in the header and includes both the upper and lower block/leaf attributes. On both X64 and AARCH64, the hierarchical inheritance of attributes is factored into the determination of block/leaf attributes. This allows the consumer of the library to easily check the attributes of any region in the page/translation table.

Updates DxePagingAuditTestApp to use FlatPageTableLib which allows us to delete the custom parsing logic in the test app.

- [x] 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, ...
- [x] Breaking change?
  - **Breaking change** - Will anyone consuming this change experience a break
    in build or boot behavior?
  - Examples: Add a new library class, move a module to a different repo, call
    a function in a new library class in a pre-existing module, ...
- [ ] Includes tests?
  - **Tests** - Does the change include any explicit test code?
  - Examples: Unit tests, integration tests, robot tests, ...
- [ ] Includes documentation?
  - **Documentation** - Does the change contain explicit documentation additions
    outside direct code modifications (and comments)?
  - Examples: Update readme file, add feature readme file, link to documentation
    on an a separate Web page, ...

## How This Was Tested

Tested by running the paging audit on SBSA and Q35 and by comparing the output against the Memory Attribute Protocol

## Integration Instructions

Platforms which build the paging audit will need to add an instance of FlatPageTableLib to their platform
DSC files.
      </blockquote>
      <hr>
    </details>
  </li>
</ul>
<ul>
  <li>
    AdvLoggerPkg: fix AdvLoggerSerialPortLib class @Javagedes (#268)
    <br>
    <details>
      <summary>Change Details</summary>
      <blockquote>
        <!-- Non-breaking space to have content if body is empty -->
        &nbsp; ## 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, ...
- [x] 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.
      </blockquote>
      <hr>
    </details>
  </li>
</ul>

## 🚀 Features & ✨ Enhancements

<ul>
  <li>
    Add call to HdwPortInitialize() when instantiating logger in DXE @joschock (#411)
    <br>
    <details>
      <summary>Change Details</summary>
      <blockquote>
        <!-- Non-breaking space to have content if body is empty -->
        &nbsp; ## 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. 

- [x] 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
      </blockquote>
      <hr>
    </details>
  </li>
</ul>
<ul>
  <li>
    UefiHidDxe: Change HID descriptor read algorithm @joschock (#339)
    <br>
    <details>
      <summary>Change Details</summary>
      <blockquote>
        <!-- Non-breaking space to have content if body is empty -->
        &nbsp; Resolves #338 

## Description

Updates the algorithm used to read the HID descriptor from HID devices. Empirical testing indicates that some devices do not support reading the HID descriptor via the class-specific Get_Report() method described in USB HID 1.11. This changes the HID read to read the entire configuration descriptor and parse the HID descriptor out of the larger structure, and gives compatibility with a broader range of devices.

- [x] Impacts functionality?
Supports a broader range of devices.
- [ ] Impacts security?
- [ ] Breaking change?
- [ ] Includes tests?
- [ ] Includes documentation?

## How This Was Tested

Verified against emulated USB devices in QEMU.

## Integration Instructions

N/A
      </blockquote>
      <hr>
    </details>
  </li>
</ul>
<ul>
  <li>
    CodeQlFilters.yml: Glob file patterns in nested directories @makubacki (#307)
    <br>
    <details>
      <summary>Change Details</summary>
      <blockquote>
        <!-- Non-breaking space to have content if body is empty -->
        &nbsp; ## Description

This filter file is picked up both directly in `mu_plus` but also
downstream repos. Therefore, the file patterns should allow matches
regardless of where a `mu_plus` submodule or external dependency
may reside in the overall repo structure.

- [ ] 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 local `mu_plus` CodeQL build
- Verified downstream (`mu_tiano_platforms`) CodeQL build that leverages
  the `CodeQlFilters.yml` file from `mu_plus`.

## Integration Instructions

No change in filtering behavior within `mu_plus`. Downstream repos that use
`mu_plus` will see more results auto filtered matching the expectations of
upstream repos.
      </blockquote>
      <hr>
    </details>
  </li>
</ul>
<ul>
  <li>
    Add Rust Module [Rebase \& FF] @makubacki (#300)
    <br>
    <details>
      <summary>Change Details</summary>
      <blockquote>
        <!-- Non-breaking space to have content if body is empty -->
        &nbsp; ## Description

Makes some adjustments to allow edk2 Rust-based modules to build
in the repo and adds a hello world Rust DXE module.

These are based on the Rust code from @joschock.

Summary of changes:

---

.pytool/CISettings.py: Set rust-ci scope and use in tree BaseTools

The Rust BaseTool changes are not in the edk2-basetools PIP module,
so this change updates CISettings.py to use the in tree tools by
default.

The `rust-ci` scope is added as an active scope so Rust related
plugins like `RustHostUnitTestPlugin` will run.

---

MsCorePkg: Add RustBootServicesAllocatorDxe

Adds a library crate that implements a global allocator based on
`AllocatePool()`. Memory is allocated from the
`EFI_BOOT_SERVICES_DATA` pool.

---

MsCorePkg: Add HelloWorldRustDxe

Adds a simple Rust based DXE driver to demonstrate how to structure
a DXE driver that only has Rust crate dependencies.

Within the firmware build framework, this is considered a "pure Rust"
DXE driver in that it only has a `Cargo.toml` file in the `[Sources]`
section of the INF with no EDK II library dependencies.

The module uses the `RustAdvancedLoggerDxe` crate (which is a wrapper
around the Advanced Logger protocol) to write debug messages and the
`RustBootServicesAllocatorDxe`.

---

- [x] 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, ...
- [x] 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

- MsCorePkg CI build
- Boot and test HelloWorldRustDxe on QEMU Q35

## Integration Instructions

See [Rust Build](https://github.com/microsoft/mu_basecore/blob/release/202302/Docs/rust_build.md) for more details about building and using Rust modules.
      </blockquote>
      <hr>
    </details>
  </li>
</ul>
<ul>
  <li>
    Add Rust Support and Advanced Logger Crate [Rebase \& FF] @makubacki (#289)
    <br>
    <details>
      <summary>Change Details</summary>
      <blockquote>
        <!-- Non-breaking space to have content if body is empty -->
        &nbsp; 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.

---

- [x] 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, ...
- [x] 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](https://dev.azure.com/projectmu/mu/_build/results?buildId=52786&view=results)
  - [Linux build without Rust](https://dev.azure.com/projectmu/mu/_build/results?buildId=52788&view=results)
  - [Windows build with Rust](https://dev.azure.com/projectmu/mu/_build/results?buildId=52747&view=results)

## Integration Instructions

No changes are needed for mu_plus integrators.

Review [general Rust documentation](https://github.com/microsoft/mu_basecore/blob/HEAD/Docs/rust_build.md) in mu_basecore for more info.
      </blockquote>
      <hr>
    </details>
  </li>
</ul>
<ul>
  <li>
    Add TpmTestingPkg and TPM Replay feature [Rebase \& FF] @makubacki (#287)
    <br>
    <details>
      <summary>Change Details</summary>
      <blockquote>
        <!-- Non-breaking space to have content if body is empty -->
        &nbsp; ## 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.

---

- [x] 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

![tpm_replay_script_example](https://github.com/microsoft/mu_plus/assets/21320094/15535256-9815-4cf6-a46d-3495f317947e)
*(click the image to enlarge it)*

#### Example: Viewing the Replayed Log in Windows

![tpm_replay_event_log_in_os](https://github.com/microsoft/mu_plus/assets/21320094/26a87837-08f5-40fc-a430-09b608ca8953)

## Integration Instructions

N/A
      </blockquote>
      <hr>
    </details>
  </li>
</ul>
<ul>
  <li>
    Close ReadyToBoot and ExitBootServices events if a reset is notified. @joschock (#275)
    <br>
    <details>
      <summary>Change Details</summary>
      <blockquote>
        <!-- Non-breaking space to have content if body is empty -->
        &nbsp; ## 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>
  </li>
</ul>
<ul>
  <li>
    [CHERRY-PICK] Remove bootmode from con var update 202302 [Rebase \& FF] @makubacki (#260)
    <br>
    <details>
      <summary>Change Details</summary>
      <blockquote>
        <!-- Non-breaking space to have content if body is empty -->
        &nbsp; ## 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.

- [x] 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.
      </blockquote>
      <hr>
    </details>
  </li>
</ul>

## 🐛 Bug Fixes

<ul>
  <li>
    Add call to HdwPortInitialize() when instantiating logger in DXE @joschock (#411)
    <br>
    <details>
      <summary>Change Details</summary>
      <blockquote>
        <!-- Non-breaking space to have content if body is empty -->
        &nbsp; ## 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. 

- [x] 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
      </blockquote>
      <hr>
    </details>
  </li>
</ul>
<ul>
  <li>
    AdvLoggerPkg: BaseAdvancedLoggerLib: Fixing a missed PCD for AARCH64 usage @kuqin12 (#331)
    <br>
    <details>
      <summary>Change Details</summary>
      <blockquote>
        <!-- Non-breaking space to have content if body is empty -->
        &nbsp; # Preface

Please ensure you have read the [contribution docs](https://github.com/microsoft/mu/blob/master/CONTRIBUTING.md) prior
to submitting the pull request. In particular,
[pull request guidelines](https://github.com/microsoft/mu/blob/master/CONTRIBUTING.md#pull-request-best-practices).

## Description

There was a missed PCD not caught in the previous PR (https://github.com/microsoft/mu_plus/pull/311) when it comes to the usage on AARCH64 platform. This change added the PCD entry in the library inf file.

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 FVP based AARCH64 platform.

## Integration Instructions

N/A
      </blockquote>
      <hr>
    </details>
  </li>
</ul>
<ul>
  <li>
    Bugfix: Fix Off by One Error When Creating X64 PlatformInfo.dat @TaylorBeebe (#317)
    <br>
    <details>
      <summary>Change Details</summary>
      <blockquote>
        <!-- Non-breaking space to have content if body is empty -->
        &nbsp; ## Description

AsciiSPrint() returns the string index non-inclusive of the NULL terminator, so adding 1 to the returned string index causes a NULL byte to be at the end of the PlatformInfo.dat file which can cause a parsing error when interpreted in .csv format in python.

- [x] 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

## Integration Instructions

N/A
      </blockquote>
      <hr>
    </details>
  </li>
</ul>
<ul>
  <li>
    CodeQlFilters.yml: Glob file patterns in nested directories @makubacki (#307)
    <br>
    <details>
      <summary>Change Details</summary>
      <blockquote>
        <!-- Non-breaking space to have content if body is empty -->
        &nbsp; ## Description

This filter file is picked up both directly in `mu_plus` but also
downstream repos. Therefore, the file patterns should allow matches
regardless of where a `mu_plus` submodule or external dependency
may reside in the overall repo structure.

- [ ] 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 local `mu_plus` CodeQL build
- Verified downstream (`mu_tiano_platforms`) CodeQL build that leverages
  the `CodeQlFilters.yml` file from `mu_plus`.

## Integration Instructions

No change in filtering behavior within `mu_plus`. Downstream repos that use
`mu_plus` will see more results auto filtered matching the expectations of
upstream repos.
      </blockquote>
      <hr>
    </details>
  </li>
</ul>
<ul>
  <li>
    MsCorePkg: Remove invalid library instance in DSC @makubacki (#302)
    <br>
    <details>
      <summary>Change Details</summary>
      <blockquote>
        <!-- Non-breaking space to have content if body is empty -->
        &nbsp; ## Description

- `GuidedSectionExtract` is not a library class name.
- `GuidedSectionExtractPeim/GuidedSectionExtract.inf` is a PEIM not
  a library.

This appears to be an accidental library class mapping that in any
case is confusing and ineffective.

- [ ] 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

MsCorePkg CI build.

## Integration Instructions

N/A
      </blockquote>
      <hr>
    </details>
  </li>
</ul>
<ul>
  <li>
    PcBdsPkg: Fix previous CodeQL change (51c7dc2) @kenlautner (#280)
    <br>
    <details>
      <summary>Change Details</summary>
      <blockquote>
        <!-- Non-breaking space to have content if body is empty -->
        &nbsp; ## 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.

- [x] 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>
  </li>
</ul>
<ul>
  <li>
    Add a check on the `PcdAdvancedFileLoggerFlush` for exit boot services @kuqin12 (#277)
    <br>
    <details>
      <summary>Change Details</summary>
      <blockquote>
        <!-- Non-breaking space to have content if body is empty -->
        &nbsp; ## 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.

- [x] 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>
  </li>
</ul>

## 🔐 Security Impacting

<ul>
  <li>
    [CHERRY-PICK] Fix CodeQL errors @kenlautner (#274)
    <br>
    <details>
      <summary>Change Details</summary>
      <blockquote>
        <!-- Non-breaking space to have content if body is empty -->
        &nbsp; ## 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, ...
- [x] 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>
  </li>
</ul>

## 📖 Documentation Updates

<ul>
  <li>
    Add HidIo protocol, USB HidIo implementation, and UefiHidDxe Rust input driver [Rebase \& FF] @joschock (#324)
    <br>
    <details>
      <summary>Change Details</summary>
      <blockquote>
        <!-- Non-breaking space to have content if body is empty -->
        &nbsp; ## Description

Adds support for Rust-based input stack. 
- Adds a new protocol interface that defines a general abstraction for HID devices: Protocols/HidIo.
- Adds Rust protocol definition of HidIo.
- Adds Rust protocol definition for AbsolutePointer
- Adds UsbHidDxe driver - written in C, provides an implementation of HidIo over USB.
- Adds UefiHidDxe driver - written in Rust, provides input report handling for HidIo pointer devices.

Note: does not yet support HID keyboards. This is planned future work. 

- [x] Impacts functionality?
Adds new input support functionality.
 
- [ ] Impacts security?
- [ ] Breaking change?
- [ ] Includes tests?
- [x] Includes documentation?
  - includes standard RustDocs.

## How This Was Tested

Pointer verified in preboot console (UEFI setup menu and Bitlocker Recovery).

## Integration Instructions

Assuming a project is setup to build rust modules generally, integration of the new stack is accomplished by:
- Remove UsbMouseAbsolutePointerDxe
- Add UsbHidDxe and UefiHidDxe to the build
      </blockquote>
      <hr>
    </details>
  </li>
</ul>
<ul>
  <li>
    Document current data flow of debug logging filtering @kuqin12 (#332)
    <br>
    <details>
      <summary>Change Details</summary>
      <blockquote>
        <!-- Non-breaking space to have content if body is empty -->
        &nbsp; ## Description

This change adds a short description of how logging level works in advanced logger as well as a flowchart for visualization.

- [ ] 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, ...
- [x] 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>
  </li>
</ul>
<ul>
  <li>
    TpmTestingPkg/TpmReplay: Add schema documentation @makubacki (#295)
    <br>
    <details>
      <summary>Change Details</summary>
      <blockquote>
        <!-- Non-breaking space to have content if body is empty -->
        &nbsp; ## Description

Adds a file that helps summarize the schema so TPM Replay event log
authors have a more human readable reference for how a TPM Replay
event log description should be structured.

- [ ] 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, ...
- [x] 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

- Based on and referenced against `TpmReplaySchema.json`.
- markdownlint

## Integration Instructions

N/A
      </blockquote>
      <hr>
    </details>
  </li>
</ul>

**Full Changelog**: https://github.com/microsoft/mu_plus/compare/...v0.1.0

v2023110000.0.0

What's Changed

How This Was Tested

Integration Instructions

Description

How This Was Tested

Integration Instructions

Description

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

Description

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

Description

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

Description

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

Description

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

⚠️ Breaking Changes

How This Was Tested

Integration Instructions

Contributors