mu_plus - v2024050001.0.0

Published by github-actions[bot] 25 days ago

What's Changed

Add GoogleTest for AdvancedLogger DxeCore Lib

Add mock for AdvancedLoggerHdwPortLib

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

How This Was Tested

CI

Integration Instructions

N/A

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

How This Was Tested

Local CI. Building the test locally.

Integration Instructions

N/A

Create Mock for DeviceBootManagerLibNull

For details on how to complete to complete these options and their meaning refer to CONTRIBUTING.md.

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

How This Was Tested

Unit tests component can call these mock functions success

Integration Instructions

N/A

⚠️ Breaking Changes

Cherry picking commits from 202311 to 202405 related to the PcdAdvancedLogger.

For details on how to complete to complete these options and their meaning refer to CONTRIBUTING.md.

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

How This Was Tested

Built and tested in 202311 branch

Integration Instructions

N/A

🐛 Bug Fixes

Current behavior allows the PPI to be used if there is a signature or version mismatch. This fix returns from the function to exit gracefully and prevent memory corruption.

Create a bug to track this behavior elsewhere in Advanced Logger Library: https://github.com/microsoft/mu_plus/issues/567

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

How This Was Tested

Local CI and unit test.

Integration Instructions

N/A

📖 Documentation Updates

Cherry picking commits from 202311 to 202405 related to the PcdAdvancedLogger.

For details on how to complete to complete these options and their meaning refer to CONTRIBUTING.md.

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

How This Was Tested

Built and tested in 202311 branch

Integration Instructions

N/A

Full Changelog: https://github.com/microsoft/mu_plus/compare/v2024050000.0.0...v2024050001.0.0

mu_plus - v2023110003.0.0

Published by github-actions[bot] 25 days ago

What's Changed

⚠️ Breaking Changes

The PCD PcdAdvancedLoggerPeiInRam does not work and is being removed. For Intel systems, the PEI phase uses cache-as-ram and determines that there is no way to allocate memory. This PCD was supposed to signal to the logger that it could allocate memory, however, it would error as memory allocation was not allowed in that phase.

Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
Impacts security?
- Security - Does the change have a direct security impact on an application,
  flow, or firmware?
- Examples: Crypto algorithm change, buffer overflow fix, parameter
  validation improvement, ...
Breaking change?
- Breaking change - Will anyone consuming this change experience a break
  in build or boot behavior?
- Examples: Add a new library class, move a module to a different repo, call
  a function in a new library class in a pre-existing module, ...
Includes tests?
- Tests - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
Includes documentation?
- Documentation - Does the change contain explicit documentation additions
  outside direct code modifications (and comments)?
- Examples: Update readme file, add feature readme file, link to documentation
  on an a separate Web page, ...

How This Was Tested

Ran the CI build for all packages in mu_plus for the X64 architecture. All tests passing.

Integration Instructions

Users of PcdAdvancedLoggerPeiInRam will need to remove that PCD from DSCs. It is not expected there are users as the PCD does not work, although platforms may have specifically set it to FALSE.

🐛 Bug Fixes

MemoryOutsideEfiMemoryMapIsInaccessible was attempting to test that memory outside the EFI_MEMORY_MAP was marked EFI_MEMORY_RP or unmapped, however this is not a valid test as we expect there to be ranges outside of the EFI_MEMORY_MAP, such as GCD non-existent memory and non-runtime MMIO ranges. This patch removes the test. Closes #531.

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.

📖 Documentation Updates

MemoryOutsideEfiMemoryMapIsInaccessible was attempting to test that memory outside the EFI_MEMORY_MAP was marked EFI_MEMORY_RP or unmapped, however this is not a valid test as we expect there to be ranges outside of the EFI_MEMORY_MAP, such as GCD non-existent memory and non-runtime MMIO ranges. This patch removes the test. Closes #531.

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.

The PCD PcdAdvancedLoggerPeiInRam does not work and is being removed. For Intel systems, the PEI phase uses cache-as-ram and determines that there is no way to allocate memory. This PCD was supposed to signal to the logger that it could allocate memory, however, it would error as memory allocation was not allowed in that phase.

Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
Impacts security?
- Security - Does the change have a direct security impact on an application,
  flow, or firmware?
- Examples: Crypto algorithm change, buffer overflow fix, parameter
  validation improvement, ...
Breaking change?
- Breaking change - Will anyone consuming this change experience a break
  in build or boot behavior?
- Examples: Add a new library class, move a module to a different repo, call
  a function in a new library class in a pre-existing module, ...
Includes tests?
- Tests - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
Includes documentation?
- Documentation - Does the change contain explicit documentation additions
  outside direct code modifications (and comments)?
- Examples: Update readme file, add feature readme file, link to documentation
  on an a separate Web page, ...

How This Was Tested

Ran the CI build for all packages in mu_plus for the X64 architecture. All tests passing.

Integration Instructions

Users of PcdAdvancedLoggerPeiInRam will need to remove that PCD from DSCs. It is not expected there are users as the PCD does not work, although platforms may have specifically set it to FALSE.

Removed reference to PcdAdvHdwLoggerDisable in the ReadMe MarkDown document.

In commit 38339016109e88a3f4ebaf8a7728b68bde0ca95f, PcdAdvancedSerialLoggerDisable in AdvLoggerPkg.dec was changed to PcdAdvancedLoggerHdwPortDisable but in the ReadMe was changed to PcdAdvancedHdwLoggerDisable.

This PCD was later removed from the .DEC in commit 8770182b7b18d55497763c4771f0804bc1e6d783 but wasn't removed from the ReadMe due to the naming difference.

Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
Impacts security?
- Security - Does the change have a direct security impact on an application,
  flow, or firmware?
- Examples: Crypto algorithm change, buffer overflow fix, parameter
  validation improvement, ...
Breaking change?
- Breaking change - Will anyone consuming this change experience a break
  in build or boot behavior?
- Examples: Add a new library class, move a module to a different repo, call
  a function in a new library class in a pre-existing module, ...
Includes tests?
- Tests - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
Includes documentation?
- Documentation - Does the change contain explicit documentation additions
  outside direct code modifications (and comments)?
- Examples: Update readme file, add feature readme file, link to documentation
  on an a separate Web page, ...

How This Was Tested

Ran CI for X64 Architecture. All Test Passed.

Integration Instructions

N/A

Full Changelog: https://github.com/microsoft/mu_plus/compare/v2023110002.0.2...v2023110003.0.0

mu_plus - v2024050000.0.0 Latest Release

Published by apop5 about 2 months ago

Initial Release notes of 202405 contain a full list of mu changes on top of edk2-stable202405

PR associated with the commit can be found at the bottom of the information pane reached by clicking on the commit hash

What's Changed## 🚀 Features & ✨ Enhancements

⚠️ Breaking Changes

mu_plus - v2023110002.0.1

Published by github-actions[bot] 2 months ago

What's Changed

Add debug level prefix for advanced logger memory message entries - Driver implementation
This change added the existing metadata - debug level into the final
advanced logger memory entries through AdvancedFileLogger. This is a followup PR for https://github.com/microsoft/mu_plus/commit/243bd187e4aa6ac68a3eb323d07554576d39ad47.
After this PR checked in, we can easily track the DEBUG_ERRORs through advanced logger files on UEFI that included this driver.
Added an extra space in the decodeuefilog.py to improve readability of the log.
For the for loop in the code, ran with perf_trace enabled, and influence is very low and can be ignored.
Updated the prefix of python script to match the design here.
Use [ERROR] instead of [DEBUG_ERROR], which could save overall log file sizes and memory buffer usage.

Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
Impacts security?
- Security - Does the change have a direct security impact on an application,
  flow, or firmware?
- Examples: Crypto algorithm change, buffer overflow fix, parameter
  validation improvement, ...
Breaking change?
- Breaking change - Will anyone consuming this change experience a break
  in build or boot behavior?
- Examples: Add a new library class, move a module to a different repo, call
  a function in a new library class in a pre-existing module, ...
Includes tests?
- Tests - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
Includes documentation?
- Documentation - Does the change contain explicit documentation additions
  outside direct code modifications (and comments)?
- Examples: Update readme file, add feature readme file, link to documentation
  on an a separate Web page, ...

How This Was Tested

Tested with two platforms that uses AdvancedFileLogger and can see debug level
prefixes in the logs in the EFI Partition and USB UefiLogs folder.
[MM_CORE] [ERROR] Image - MmSupervisorCore.pdb

Integration Instructions

N/A

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

mu_plus - v2023020006.1.3

Published by github-actions[bot] 2 months ago

What's Changed

🐛 Bug Fixes

This PR cherry-picks one full commit and one very small part of another commit from 202311:

Remove NVMe Check from File Logger

This is a complete cherry-pick from c024ed1e61108d71e7e8fa4693c2d55839f87ac0. It adds support for File Logger to create the UefiLogs directory on non-NVMe devices.

Allocate AdvLogger Pre-Mem Pages as EfiBootServicesData

This is a part of be9a3d273ffabebca606266c6cb3a47bbf49c4d5. The rest of this commit is not taken because it is a new feature (a new version of the AdvLogger structure). This portion of the commit was taken because it is a bugfix for when ARM64 switched over to 64k runtime page allocation granularity. Because PeiCore has a hardcoded assumption it is operating pre-mem, which is not true for ARM64, we cannot allocate a minimum of 16 pages for a runtime type at the start of PeiCore (when AdvLogger is initialized there). We instead need to allocate as EfiBootServicesData (which does not have the runtime page allocation granularity) and reallocate as EfiRuntimeServicesData after permanent memory is installed.

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/v2023020006.1.2...v2023020006.1.3

mu_plus - v2023110001.0.3

Published by github-actions[bot] 3 months ago

What's Changed

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

Description

This change added the existing metadata - debug level into the final advanced logger memory entries, it can differentiate the different debug levels, DEBUG_INFO, DEBUG_ERROR, etc.
We don't need to touch firmware as debug level info is already part of metadata, so we only need to update the decode script.
It's useful to be able to filter out the specific debug level msgs that we care about and make data processing of uefi logs possible.
For example, DEBUG_ERROR level prints are generally very important and worth analyzing. One blocking thing now is that we can't tell the difference between different debug level msgs because not all DEBUG_ERROR will have an "error:" as the prefix of the debug msg, and search for "error" will also be noisy as it's a commonly used word. After this PR checked in, we can easily track the DEBUG_ERRORs.

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 with a platform that uses advancedlogger and can seedebug level prefixes in the msg.
22:36:22.840 : [MM_CORE] [DEBUG_INFO]AdvancedLoggerGetLoggerInfo: LoggerInfo=70F37000
22:36:22.857 : [MM_CORE] [DEBUG_ERROR]ERROR - The FV at 0xFFE60000 is invalid!

Integration Instructions

N/A

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

mu_plus - v2023110001.0.2

Published by github-actions[bot] 3 months ago

What's Changed

MfciVerifyPolicyAndChangeRoTHostTest.c and MfciVerifyPolicyAndChangeHostTest.c both contained an additonal registered test suite that did not contain any tests.

MsWheaPkg also contained a test suite where the tests associated were not registered correctly.

This started failing after fd8a09795aa where empty test suites will now be reported as an error.

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

Local CI passed after change.

Integration Instructions

N/A

Currently, File Logger will only create the UefiLogs directory on the ESP if the device is an NVMe device. This is an unneccesary restriction and is removed in this patch.

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 system with a non-NVMe drive that failed to have the FileLogger directory created before this change and succeeds now.

Integration Instructions

If the integrating platform has a filesystem that does not support being logged to, it should set PcdAdvancedFileLoggerForceEnable to FALSE so that the directory is not attempted to be created.

Use more idiomatic rust pattern and remove the explicitly implementation of Sync and Send since these traits are automatically implemented.

Note: changes in pointer.rs are cause by cargo fmt

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

How This Was Tested

Ran cargo make test

Integration Instructions

N/A

Unit tests started failing due to compilation errors. This stemmed from a bug fixed in microsoft/mu_basecore#891. Once this bug was fixed, the unit tests starting to be compiled which blocked pipelines.

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

Ran Local CI to verify unit tests change.

Integration Instructions

N/A

This PR adds support for Digitizer switch usages (HID Usage Page 0xD, usages 0x42 through 0x46) as buttons in the AbsolutePointer implementation.

See https://usb.org/document-library/hid-usage-tables-15 for usage tables.

Impacts functionality?
- Add support for Digitizer switch usages as buttons in the pointer interface.
Impacts security?
Breaking change?
Includes tests?
Includes documentation?

How This Was Tested

Functionally verified with a touch panel implementation that exposes these HID usages.

Integration Instructions

No special integration required.

  </blockquote>
  <hr>
</details>

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

Description

This change fixed the incorrect precendence where the "not" operator will be evaluated before the bitwise operator.

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

The test does not change result.

Integration Instructions

N/A

  </blockquote>
  <hr>
</details>

🔐 Security Impacting

Added support to invoke AdvlogDump as in-built UEFI Shell application using EFI_SHELL_DYNAMIC_COMMAND_PROTOCOL
Created new INF file to add this support
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

Invoked "Advlogdump" from UEFI Shell and verified LogDumper functionality

Integration Instructions

Integration

Add the following to DSC file
AdvLoggerPkg/Application/AdvancedLogDumper/AdvancedLogDumperDynamicCommand.inf {

gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
}

in FDF file

INF AdvLoggerPkg/Application/AdvancedLogDumper/AdvancedLogDumperDynamicCommand.inf

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

mu_plus - v2023110001.0.1

Published by github-actions[bot] 5 months ago

What's Changed

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

Description

This change fixes an code path when the error occurs early enough, the Status might get evaluated without being initialized.

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 is tested building with CLANGPDB. The build failure is gone after the fix.

Integration Instructions

N/A

  </blockquote>
  <hr>
</details>

The GCC build options in the INF referenced a function in the sample PRM driver (and was apparently not caught by CI). Building on GCC breaks without this function defined. Instead require that the PRM handler is defined (so that GCC does not strip it out when building the binary, seeing it not being referenced).

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

Building on GCC.

Integration Instructions

N/A.

  </blockquote>
  <hr>
</details>

When TcgMorLockSmm.c the SetVariableCheckHandlerMorLock() function was changed to set the MorLock variable Value to 0x01 to indicate Locked Without Key, MorLockTestApp also need to be changed to make sure the test flow can get positive results.

Changes are listed as below

MorLockShouldNotBeSet(): This function should compare with MOR_LOCK_DATA_UNLOCKED.
MorLockv2LockedWithoutKeyShouldReportCorrectly(): Rename from MorLockv2ShouldReportCorrectly() and update usage in MorLockTestApp() as it is compared with MOR_LOCK_DATA_LOCKED_WITHOUT_KEY.
MorLockv2LockedWithKeyShouldReportCorrectly(): This new function compares MorLock with MOR_LOCK_DATA_LOCKED_WITH_KEY for Morlock V2 testing. Also update usage in MorLockTestApp().
MorLockv2ShouldNotClearWithWrongKey(): Should compare with MOR_LOCK_DATA_LOCKED_WITHOUT_KEY when using wrong key to clear MorLock.
MorLockv2ShouldSetClearSet(): Should compare with MOR_LOCK_DATA_LOCKED_WITHOUT_KEY when using different key to clear MorLock.
MorLockTestApp(): Update above function usage in different test cases to make sure the test can be finished.

Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
Impacts security?
- Security - Does the change have a direct security impact on an application,
  flow, or firmware?
- Examples: Crypto algorithm change, buffer overflow fix, parameter
  validation improvement, ...
Breaking change?
- Breaking change - Will anyone consuming this change experience a break
  in build or boot behavior?
- Examples: Add a new library class, move a module to a different repo, call
  a function in a new library class in a pre-existing module, ...
Includes tests?
- Tests - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
Includes documentation?
- Documentation - Does the change contain explicit documentation additions
  outside direct code modifications (and comments)?
- Examples: Update readme file, add feature readme file, link to documentation
  on an a separate Web page, ...

How This Was Tested

Tested in the uefi shell. The tests should get positive results and no errors are reported.

Integration Instructions

N/A

🐛 Bug Fixes

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

Description

When using GCC(-like) compilers to build MathLib, the sqrt_d function will use built-in functions for bit scan reverse. However, the calculation for 64 bit BSR is incorrectly using the built-in function specifically for unsigned long, which is 32-bit for CLANGPDB and cause the unit test to fail.

This change fixed the built-in function usage.

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

Unit test passed on QEMU SBSA platform built with CLANGPDB.

Integration Instructions

N/A

  </blockquote>
  <hr>
</details>

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

mu_plus - v2023110000.0.6

Published by github-actions[bot] 6 months ago

What's Changed

This PR brings in two fixes to support a wider variety of devices, some of which might not be completely self-consistent:

Allow report lengths that don't match the report descriptor. Reports that are shorter than the Report Descriptor specifies will be processed for whatever fields are fully present. Reports that are longer than the Report descriptor specifies will simply ignore the extra bytes in the report.
Move away from using signal_event to force keyboard layout initialization, and install call the layout change routine directly. This avoids introducing sequencing issues based on the TPL that the keyboard is being initialized at, resulting in more deterministic behavior.

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

How This Was Tested

Rust unit tests updated to cover new functionality all pass. Functional testing on hardware with the changes also passes.

Integration Instructions

N/A

  </blockquote>
  <hr>
</details>

📖 Documentation Updates

The current implementation of instantiating global variables will make each c file that includes this header to carry a copy of such variable, which is space redundant.

This change removed the variable into the single module that uses it and removed the structure it defines. The function descriptions are also updated.

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 is a non-functional change.

Integration Instructions

N/A

Full Changelog: https://github.com/microsoft/mu_plus/compare/v2023110000.0.5...v2023110000.0.6

mu_plus - v2023110000.0.5

Published by github-actions[bot] 6 months ago

What's Changed

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

Description

The current implementation will directly allocation pages through PEI services when Advanced logger is not initialized. This cause an issue of permanent loop if/when there are prints from the allocation routine.

This change will create a hob during this interim state and log messages to hobs temporarily and coalesce the hobs after the allocation is finalized. This will reduce the print restriction down to hob creation only.

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 is tested on QEMU SBSA as well as Q35. Both booted to UEFI shell.

Integration Instructions

N/A

  </blockquote>
  <hr>
</details>

The Mem Map and MAT shell test currently has a hard dependency on 4k alignment of EFI_MEMORY_MAP and MAT table entries. This is only valid when the RUNTIME_PAGE_ALLOCATION_GRANULARITY is 4k. To make this more universal, compare the MAT entries to RUNTIME_PAGE_ALLOCATION_GRANULARITY as well as the UEFI spec defined EFI_MEMORY_MAP types that should have RUNTIME_PAGE_ALLOCATION_GRANULARITY.

As a small cleanup, rename LegacyMemoryMap to EfiMemoryMap as it is certainly not legacy and to avoid confusion :).

This also removes a duplicate test.

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 by running the shell app on Q35 and confirming it still succeeds.

Integration Instructions

N/A. This has no dependency on mu_basecore 64k changes because the RUNTIME_PAGE_ALLOCATION_GRANULARITY is what we expect the MAT and runtime EFI_MEMORY_MAP entries to be aligned to, regardless of whether that is 4k or 64k.

  </blockquote>
  <hr>
</details>

This PR also removes the AllocatedPagesAndPoolsAreProtected test because it is not required according to the Enhanced Memory Protection spec and a similar test is run in the DxeMemoryProtectionTestApp. The NullCheck test is renamed to better reflect purpose.

📖 Documentation Updates

Console app to get Advanced Logger dump.

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

Built and ran on ARM and x64 machines. Verified output was identical to DecodeUefiLog script raw dump.

Integration Instructions

N/A

Full Changelog: https://github.com/microsoft/mu_plus/compare/v2023110000.0.4...v2023110000.0.5

mu_plus - v2023110000.0.3

Published by github-actions[bot] 7 months ago

What's Changed

Remove the Collection of Page Directories: Table entries were being collected but are not used in the paging audit. While they could be used to check heritable attributes, the PDE entries would need to be split by level which makes determining heritability difficult. Instead, FlatPageTableLib can be used in the future to check heritability.
Paging Audit: Update File Collection to Defer Free/Allocate Calls: While collecting platform paging and memory info, freeing and allocating memory will potentially change the memory layout and corrupt the test results. Because allocating and freeing memory only transitions memory type between EfiConventionalMemory and EfiBootServicesMemory (which are required to have the same memory protection policy), this nuance didn't matter much. However, as the DXE core is updated to support more strict protections on free memory, this nuance will matter. This patch updates the data collection routines to calculate and allocate all required memory before fetching the memory map and collecting page table data.
FIx SMM Paging Audit: The SMM paging audit needed to be updated to match the improvements made to the DXE audit. This PR reformats the SMM HTML template, updates the HTML template so the memory range object strings match the template naming, fixes the parsing of GDT and IDT entries, adds the platform info data collection

How This Was Tested

Tested on Q35 and SBSA by running the paging audit with various memory protection profiles. The SMM audit was tested on an SMM-enabled Surface platform.

Integration Instructions

N/A

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

mu_plus - v2023020006.1.2

Published by github-actions[bot] 8 months ago

What's Changed

An instance of StackCheckLib must be in each DSC to accommodate -fstack-protector and /GS flags.

Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
Impacts security?
- Security - Does the change have a direct security impact on an application,
  flow, or firmware?
- Examples: Crypto algorithm change, buffer overflow fix, parameter
  validation improvement, ...
Breaking change?
- Breaking change - Will anyone consuming this change experience a break
  in build or boot behavior?
- Examples: Add a new library class, move a module to a different repo, call
  a function in a new library class in a pre-existing module, ...
Includes tests?
- Tests - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
Includes documentation?
- Documentation - Does the change contain explicit documentation additions
  outside direct code modifications (and comments)?
- Examples: Update readme file, add feature readme file, link to documentation
  on an a separate Web page, ...

How This Was Tested

Tested in pipelines

Integration Instructions

N/A

MsWheaReportHandlerPei() is passed to ReportHwErrRecRouter() for the
MS_WHEA_ERR_REPORT_PS_FN value where that is defined as:

typedef
EFI_STATUS
(EFIAPI *MS_WHEA_ERR_REPORT_PS_FN)(
  IN MS_WHEA_ERROR_ENTRY_MD           *MsWheaEntryMD
  );

So, MsWheaReportHandlerPei() needs to include EFIAPI as well.

Similarly, MsWheaRscHandlerPei() needs EFIAPI due to the definition
of EFI_PEI_RSC_HANDLER_CALLBACK.

Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
Impacts security?
- Security - Does the change have a direct security impact on an application,
  flow, or firmware?
- Examples: Crypto algorithm change, buffer overflow fix, parameter
  validation improvement, ...
Breaking change?
- Breaking change - Will anyone consuming this change experience a break
  in build or boot behavior?
- Examples: Add a new library class, move a module to a different repo, call
  a function in a new library class in a pre-existing module, ...
Includes tests?
- Tests - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
Includes documentation?
- Documentation - Does the change contain explicit documentation additions
  outside direct code modifications (and comments)?
- Examples: Update readme file, add feature readme file, link to documentation
  on an a separate Web page, ...

How This Was Tested

Verified results from a GCC build that reported the issue before and after
the change.

Integration Instructions

N/A

📖 Documentation Updates

Mfci has a soft dependency on MuVarPolicyFoundationDxe. The phase based variables (Target\Manufacturer, Target\Product, Target\SerialNumber, Target\OEM_01 and Target\OEM_02) are locked using RegisterVarStateVariablePolicy.

Adding documentation to explicitly call out the need for the MsCorePkg's MuVarPolicyFoundationDxe to enable phase based locking.

Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
Impacts security?
- Security - Does the change have a direct security impact on an application,
  flow, or firmware?
- Examples: Crypto algorithm change, buffer overflow fix, parameter
  validation improvement, ...
Breaking change?
- Breaking change - Will anyone consuming this change experience a break
  in build or boot behavior?
- Examples: Add a new library class, move a module to a different repo, call
  a function in a new library class in a pre-existing module, ...
Includes tests?
- Tests - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
Includes documentation?
- Documentation - Does the change contain explicit documentation additions
  outside direct code modifications (and comments)?
- Examples: Update readme file, add feature readme file, link to documentation
  on an a separate Web page, ...

How This Was Tested

Ran CI locally

Integration Instructions

n/a

Full Changelog: https://github.com/microsoft/mu_plus/compare/v2023020006.1.1...v2023020006.1.2

mu_plus - v2023110000.0.2

Published by github-actions[bot] 8 months ago

What's Changed

An instance of StackCheckLib must be in each DSC to accommodate -fstack-protector and /GS flags.

Impacts functionality?
Functionality - Does the change ultimately impact how firmware functions?
Examples: Add a new library, publish a new PPI, update an algorithm, ...
Impacts security?
Security - Does the change have a direct security impact on an application,
flow, or firmware?
- Examples: Crypto algorithm change, buffer overflow fix, parameter validation improvement, ...
Breaking change?
Breaking change - Will anyone consuming this change experience a break
in build or boot behavior?
Examples: Add a new library class, move a module to a different repo, call
a function in a new library class in a pre-existing module, ...
Includes tests?
- Tests - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
Includes documentation?
Documentation - Does the change contain explicit documentation additions
outside direct code modifications (and comments)?
Examples: Update readme file, add feature readme file, link to documentation
on an a separate Web page, ...

How This Was Tested

Tested in pipelines

Integration Instructions

N/A

Create a new guid and HOB entry definition for specifying a pre-DXE log buffer on platforms which can't use a pre-DXE AdvancedLoggerLib instance. After the advanced logger info buffer is created, the DxeCore AdvancedLoggerLib constructor will search for the guided HOB and, if found, write the contents of the buffer specified by the entry to the advanced logger buffer.

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 creating the HOB and verifying that the DxeCore constructor located it.

Integration Instructions

N/A

MsWheaReportHandlerPei() is passed to ReportHwErrRecRouter() for the
MS_WHEA_ERR_REPORT_PS_FN value where that is defined as:

typedef
EFI_STATUS
(EFIAPI *MS_WHEA_ERR_REPORT_PS_FN)(
  IN MS_WHEA_ERROR_ENTRY_MD           *MsWheaEntryMD
  );

So, MsWheaReportHandlerPei() needs to include EFIAPI as well.

Similarly, MsWheaRscHandlerPei() needs EFIAPI due to the definition
of EFI_PEI_RSC_HANDLER_CALLBACK.

Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
Impacts security?
- Security - Does the change have a direct security impact on an application,
  flow, or firmware?
- Examples: Crypto algorithm change, buffer overflow fix, parameter
  validation improvement, ...
Breaking change?
- Breaking change - Will anyone consuming this change experience a break
  in build or boot behavior?
- Examples: Add a new library class, move a module to a different repo, call
  a function in a new library class in a pre-existing module, ...
Includes tests?
- Tests - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
Includes documentation?
- Documentation - Does the change contain explicit documentation additions
  outside direct code modifications (and comments)?
- Examples: Update readme file, add feature readme file, link to documentation
  on an a separate Web page, ...

How This Was Tested

Verified results from a GCC build that reported the issue before and after
the change.

Integration Instructions

N/A

📖 Documentation Updates

Mfci has a soft dependency on MuVarPolicyFoundationDxe. The phase based variables (Target\Manufacturer, Target\Product, Target\SerialNumber, Target\OEM_01 and Target\OEM_02) are locked using
RegisterVarStateVariablePolicy.

Adding documentation to explicitly call out the need for the MsCorePkg's MuVarPolicyFoundationDxe to enable phase based locking.

Impacts functionality?
Functionality - Does the change ultimately impact how firmware functions?
Examples: Add a new library, publish a new PPI, update an algorithm, ...
Impacts security?
Security - Does the change have a direct security impact on an application,
flow, or firmware?
- Examples: Crypto algorithm change, buffer overflow fix, parameter validation improvement, ...
Breaking change?
Breaking change - Will anyone consuming this change experience a break
in build or boot behavior?
Examples: Add a new library class, move a module to a different repo, call
a function in a new library class in a pre-existing module, ...
Includes tests?
- Tests - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
Includes documentation?
Documentation - Does the change contain explicit documentation additions
outside direct code modifications (and comments)?
Examples: Update readme file, add feature readme file, link to documentation
on an a separate Web page, ...

How This Was Tested

Ran CI locally

Integration Instructions

n/a

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

mu_plus - v2023110000.0.0

Published by github-actions[bot] 9 months ago

What's Changed

First 202311 Mu Plus release 🎉.

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

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 https://github.com/microsoft/mu_plus/issues/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 12f028aaa23f23d229bdb6b266f736f3ff928ac8)

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

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

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

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.

Adds 5 tests to the HTML templates:

Test that the NULL page is EFI_MEMORY_RP
Check that MMIO memory is non-executable.
Check that EfiConventionalMemory is non-executable.
Check that memory not in the EFI memory map is not accessible.
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.

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.

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

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

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.

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 the HTML/Javascript filters for RWX to not include GcdNonExistent regions
Combine the UX and PX fields into one Execute field to make it easier to check for RWX regions
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

Fixes the following issues with GetGraphicsInfo().

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

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

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 https://github.com/microsoft/mu_basecore/issues/369 and https://github.com/microsoft/mu_basecore/issues/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-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

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

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]

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

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]

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

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]

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]

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: }

CI build will no longer "audit" spelling issues, they will cause CI to fail
Spelling errors fixed
Real terms added to dictionary

This may be re-evaluated in the future, but it should also encourage drivers to move away from VariableLockProtocol and towards VariablePolicyProtocol.

⚠️ 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

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

mu_plus - v2023020006.1.1

Published by github-actions[bot] 9 months ago

What's Changed

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 https://github.com/microsoft/mu_plus/issues/401

For each item, place an "x" in between [ and ] if true. Example: [x].
(you can also check items in the GitHub UI)

Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
Impacts security?
- Security - Does the change have a direct security impact on an application,
  flow, or firmware?
- Examples: Crypto algorithm change, buffer overflow fix, parameter
  validation improvement, ...
Breaking change?
- Breaking change - Will anyone consuming this change experience a break
  in build or boot behavior?
- Examples: Add a new library class, move a module to a different repo, call
  a function in a new library class in a pre-existing module, ...
Includes tests?
- Tests - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
Includes documentation?
- Documentation - Does the change contain explicit documentation additions
  outside direct code modifications (and comments)?
- Examples: Update readme file, add feature readme file, link to documentation
  on an a separate Web page, ...

How This Was Tested

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

Integration Instructions

N/A

  </blockquote>
  <hr>
</details>

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

Description

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

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

For each item, place an "x" in between [ and ] if true. Example: [x].
(you can also check items in the GitHub UI)

Impacts functionality?
Functionality - Does the change ultimately impact how firmware functions?
Examples: Add a new library, publish a new PPI, update an algorithm, ...
Impacts security?
Security - Does the change have a direct security impact on an application,
flow, or firmware?
- Examples: Crypto algorithm change, buffer overflow fix, parameter validation improvement, ...
Breaking change?
Breaking change - Will anyone consuming this change experience a break
in build or boot behavior?
Examples: Add a new library class, move a module to a different repo, call
a function in a new library class in a pre-existing module, ...
Includes tests?
- Tests - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
Includes documentation?
Documentation - Does the change contain explicit documentation additions
outside direct code modifications (and comments)?
Examples: Update readme file, add feature readme file, link to documentation
on an a separate Web page, ...

How This Was Tested

This change was tested on proprietary hardware with multiple cores.

Integration Instructions

N/A

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

  </blockquote>
  <hr>
</details>

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

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

How This Was Tested

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

Integration Instructions

N/A

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

For each item, place an "x" in between [ and ] if true. Example: [x].
(you can also check items in the GitHub UI)

Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
Impacts security?
- Security - Does the change have a direct security impact on an application,
  flow, or firmware?
- Examples: Crypto algorithm change, buffer overflow fix, parameter
  validation improvement, ...
Breaking change?
- Breaking change - Will anyone consuming this change experience a break
  in build or boot behavior?
- Examples: Add a new library class, move a module to a different repo, call
  a function in a new library class in a pre-existing module, ...
Includes tests?
- Tests - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
Includes documentation?
- Documentation - Does the change contain explicit documentation additions
  outside direct code modifications (and comments)?
- Examples: Update readme file, add feature readme file, link to documentation
  on an a separate Web page, ...

How This Was Tested

N/A

Integration Instructions

N/A

  </blockquote>
  <hr>
</details>

Full Changelog: https://github.com/microsoft/mu_plus/compare/v2023020006.1.0...v2023020006.1.1