What's Changed

🚀 Features & ✨ Enhancements

Adds a new library class (InputChannelLib) that allows the TPM replay
event log to be passed through a platform-specific mechanism.

• 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

• Passed FW CFG TPM event log through QemuQ35Pkg
• Verified library integrated without a custom log being passed uses
  lower priority input channels as expected
• Verified BaseInputChannelLibNull is functionally usable for skipping
  custom log input.

Integration Instructions

Add InputChannelLib|TpmTestingPkg/Library/BaseInputChannelLibNull/BaseInputChannelLibNull.inf
to a platform that uses the TPM Replay feature but does not provide a custom input channel
instance.

Full Changelog: https://github.com/microsoft/mu_plus/compare/v2023020003.0.1...v2023020003.1.0

What's Changed

🚀 Features & 📖 Documentation Updates

This crate provides a rust wrapper around UEFI HII Keyboard Layout structures. The relevant structures defined in the UEFI spec are not well-suited for direct definition in rust; so this crate defines analogous rust structures and provides serialization/deserialization support for converting the rust structures into byte buffers and vice versa. This crate uses the scroll crate (https://github.com/m4b/scroll) to facilitate serialization/deserialization of the Hii structures.

Examples and Usage

Retrieving a default (en-US) layout, writing it to a buffer, and then reading the buffer back into a rust structure:

 use hii_keyboard_layout::{get_default_keyboard_pkg, HiiKeyboardPkg};
 use scroll::{Pread, Pwrite};
 let mut buffer = [0u8; 4096];

 let package = get_default_keyboard_pkg();
 buffer.pwrite(&package, 0).unwrap();

 let package2: HiiKeyboardPkg = buffer.pread(0).unwrap();
 assert_eq!(package, package2);

• Impacts functionality?
  • Introduces a new crate providing support for HII layouts.
• Impacts security?
• Breaking change?
• Includes tests?
  • Includes standard rust unit tests.
• Includes documentation?
  • Includes standard rust documentation.

How This Was Tested

Verified by included unit tests.

Integration Instructions

This crate requires the "scroll," "num-traits" and "num-drive" crates, so platforms intending to use it will need to add these as dependencies in their workspace Cargo.toml files. This PR does this for the workspace Cargo.toml that is at the root of mu_plus.

Sample:

scroll = { version = "0.11", default-features = false, features = ["derive"]}
num-traits = { version = "0.2", default-features = false}
num-derive = { version = "0.4", default-features = false}

Full Changelog: https://github.com/microsoft/mu_plus/compare/v2023020003.0.0...v2023020003.0.1

What's Changed

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

⚠️ Breaking Changes

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

To replicate existing behavior, 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}

Full Changelog: https://github.com/microsoft/mu_plus/compare/v2023020002.1.0...v2023020003.0.0

What's Changed

🚀 Features & ✨ Enhancements

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.

• 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

Full Changelog: https://github.com/microsoft/mu_plus/compare/v2023020002.0.4...v2023020002.1.0

What's Changed

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

Full Changelog: https://github.com/microsoft/mu_plus/compare/v2023020002.0.3...v2023020002.0.4

What's Changed

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.

Full Changelog: https://github.com/microsoft/mu_plus/compare/v2023020002.0.2...v2023020002.0.3

What's Changed

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.

📖 Documentation Updates

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.

• Impacts functionality?
  Adds new input support functionality.
   
• Impacts security?
• Breaking change?
• Includes tests?
• 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
  
  

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, ...
• Includes documentation?
  • Documentation - Does the change contain explicit documentation additions
    outside direct code modifications (and comments)?
  • Examples: Update readme file, add feature readme file, link to documentation
    on an a separate Web page, ...

How This Was Tested

N/A

Integration Instructions

N/A

Full Changelog: https://github.com/microsoft/mu_plus/compare/v2023020002.0.1...v2023020002.0.2

What's Changed

🐛 Bug Fixes

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

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>

Full Changelog: https://github.com/microsoft/mu_plus/compare/v2023020002.0.0...v2023020002.0.1

What's Changed

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.

⚠️ Breaking Changes

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.

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

Full Changelog: https://github.com/microsoft/mu_plus/compare/v2023020001.5.2...v2023020002.0.0

What's Changed

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

Full Changelog: https://github.com/microsoft/mu_plus/compare/v2023020001.5.1...v2023020001.5.2

What's Changed

🐛 Bug Fixes

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.

• 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

Full Changelog: https://github.com/microsoft/mu_plus/compare/v2023020001.5.0...v2023020001.5.1

What's Changed

🚀 Features & ✨ Enhancements

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.

🐛 Bug Fixes

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.

Full Changelog: https://github.com/microsoft/mu_plus/compare/v2023020001.4.1...v2023020001.5.0

What's Changed

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

Full Changelog: https://github.com/microsoft/mu_plus/compare/v2023020001.4.0...v2023020001.4.1

What's Changed

🚀 Features & ✨ Enhancements

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.

• 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
• Boot and test HelloWorldRustDxe on QEMU Q35

Integration Instructions

See Rust Build for more details about building and using Rust modules.

Full Changelog: https://github.com/microsoft/mu_plus/compare/v2023020001.3.2...v2023020001.4.0

What's Changed

🐛 Bug Fixes

• 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

Full Changelog: https://github.com/microsoft/mu_plus/compare/v2023020001.3.1...v2023020001.3.2

What's Changed

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.

📖 Documentation Updates

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

Full Changelog: https://github.com/microsoft/mu_plus/compare/v2023020001.3.0...v2023020001.3.1

What's Changed

🚀 Features & ✨ Enhancements

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: https://github.com/microsoft/mu_plus/compare/v2023020001.2.0...v2023020001.3.0

What's Changed

🚀 Features & ✨ Enhancements

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: https://github.com/microsoft/mu_plus/compare/v2023020001.1.2...v2023020001.2.0

What's Changed

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

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: https://github.com/microsoft/mu_plus/compare/v2023020001.1.1...v2023020001.1.2

What's Changed

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

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>

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: https://github.com/microsoft/mu_plus/compare/v2023020001.1.0...v2023020001.1.1