What's Changed

🚀 Features & ✨ Enhancements

1. AdvLoggerPkg: 64-bit SEC & PEI C Code changes

   C code changes for building the code as 64-bit.

2. AdvLoggerPkg/SecDebugAgent: Update for 64-bit

   Allows the module to be built for 64-bit SEC.

• 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

• Platform with X64 SEC & PEI

Integration Instructions

N/A - Appropriate code will be built based on module architecture.

Note: In draft while testing is in progress.

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

What's Changed

• 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

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

What's Changed

The advanced logging at runtime is lack of usage. However, this becomes increasingly important for server platforms, where the system could potentially stay up for months, or even years. This will make the advanced logger fill up the buffer during runtime/MM logging well ahead of a reset event, making the buffer content stale when being reviewed.

This change added a feature PCD guarded feature that, when enabled, will automatically wrap the LogCurrent cursor to the beginning and continue to log. This will effectively create a circular buffer as the stale content will remain in place. The tooling update is still under development.

• 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 QEMU Q35 along with the UEFI shell based test app to verify that the entry after wrapping is correct and is multi-threading safe.

Integration Instructions

Platforms can enable this feature by setting gAdvLoggerPkgTokenSpaceGuid.PcdAdvancedLoggerAutoClearEnable|TRUE

Adds commits that only applied Uncrustify formatting or converted
line endings to a .git-blame-ignore-revs file so they are ignored
by git blame. This is supported by GitHub:
https://github.blog/changelog/2022-03-24-ignore-commits-in-the-blame-view-beta/

This helps clean up git blame by filtering out these changes.

Note: This file needs to be updated on rebase branches. Processes
like filter-branch can automatically update relevant SHAs.

• 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

• git blame

Integration Instructions

N/A

🐛 Bug Fixes

https://github.com/microsoft/mu_plus/commit/267e27f6a64a80fe82e5ea9adef25edc71776ba3 change introduced a build error on certain platforms, due to a local variable being used uninitialized. This change will set the variable to 0 before 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

This change is tested with LineParserTestApp on QEMU Q35 platform.

Integration Instructions

N/A

🔐 Security Impacting

https://github.com/microsoft/mu_plus/commit/267e27f6a64a80fe82e5ea9adef25edc71776ba3 change introduced a build error on certain platforms, due to a local variable being used uninitialized. This change will set the variable to 0 before 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

This change is tested with LineParserTestApp on QEMU Q35 platform.

Integration Instructions

N/A

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

What's Changed

⚠️ Breaking Changes

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

Description

This change introduces a new message entry structure, which contains extra information of log producer and can be used to differentiate the different boot phases, i.e. PEI, DXE, SMM, etc. Platforms that have multiple firmware entities can leverage this extra information to distinguish coalesced memory logging regions.

The updated applications (UEFI shell app and host OS Python script) are also updated to support new message entry structure while maintaining the backwards compatibility.

Resolves https://github.com/microsoft/mu_plus/issues/375.

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 QEMU Q35 and verified that prefix are properly injected for DXE phase prints.

Integration Instructions

The log parsers are updated, thus platforms use the existing parser should pick up the latest tool from mu_plus. For platforms that carry their own implementation, they should add the proper support in their own implementation before picking up this change from mu_plus.

Full Changelog: https://github.com/microsoft/mu_plus/compare/v2023020005.0.0...v2023020006.0.0

What's Changed

⚠️ Breaking Changes

mu_plus commit f535499 creates DXE and SMM instances of MemoryProtectionTestApp, and updates the naming of the support driver for the SMM test app. This split is to support testing for platforms which do not use SMM.

Instances of the following will need to be DELETED
UefiTestingPkg/FunctionalSystemTests/MemoryProtectionTest/App/MemoryProtectionTestApp.inf
UefiTestingPkg/FunctionalSystemTests/MemoryProtectionTest/Smm/MemoryProtectionTestSmm.inf

The following will need to be ADDED for unit test builds
​UefiTestingPkg/FunctionalSystemTests/MemoryProtectionTest/App/DxeMemoryProtectionTestApp.inf

If the platform uses SMM, add this to the platform DSC
UefiTestingPkg/FunctionalSystemTests/MemoryProtectionTest/App/SmmMemoryProtectionTestApp.inf

And this to both the platform DSC and FDF files
​UefiTestingPkg/FunctionalSystemTests/MemoryProtectionTest/Driver/SmmMemoryProtectionTestDriver.inf

https://github.com/microsoft/mu_plus/commit/f5354997aee1fb5caee28d92e232fe638ebf965b split the MemoryProtectionTestApp into DXE and SMM instances but did not delete the old files to give consumers time to update their platform DSC files. This PR is the breaking change which removes the old files.

• 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/v2023020004.1.2...v2023020005.0.0

What's Changed

The MemoryInfoDatabase.dat file contains information about the content of memory regions. If an entry in the database file is invalid, it will break the generation of the paging audit. Before adding the stack info to the database file, check that the stack size is greater than zero.

• 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 by generating the paging audit

Integration Instructions

N/A

This change set was primarily created to improve the accuracy of the DXE paging audit shell test. The problem was two-fold:

1. The layout of memory would change as data was collected. This is solved by pre-allocating space for two of the memory maps (flat page table and EFI memory map). Those two maps will have their size requirement checked at the start of each function to ensure enough heap space has been allocated for them prior to populating them with memory information.
2. The shell test was imprecise when reporting which regions failed the various tests. I'll use the UnallocatedMemoryIsRP() test as an example. The test parses the EFI memory map for EfiConventionalMemory regions which indicate unallocated memory. If any subsection of the region was not read protected, then the entire region would be reported as failing. With this update, every subsection which does not comply will be individually reported giving platform developers more precise information on where the problem areas are.

Patch breakdown:

1. Updates the DXE paging audit to always write out all .dat files even if the buffers are empty. The presence of the file acts as a receipt that the audit was run successfully and helps with automated unit testing.
2. Adds a function to FlatPageTableLib to dump the contents of a flat page table to the console. This is useful for debugging.
3. Updates GetRegionAccessAttributes() in FlatPageTableLib to return the attributes of the first attribute-contiguous range found in the region and report the actual size of that range. This allows the caller to collect the attributes of the region by calling the function repeatedly instead of needing to guess which subsection of the region has contiguous attributes.
4. Updates the DXE paging audit shell tests to pre-allocate memory for memory maps. The page table map, EFI memory map, and EFI memory space map all describe the layout of the system address space. Because of this, if allocations are performed while these maps are being generated, then the maps generated the earliest will be inaccurate.
5. Adds ValidatePageTableAttributes() to the DXE paging audit shell test logic. This function validates the attributes of the input memory region. It uses GetRegionAccessAttributes() to get the attributes of the region and compares them to the attributes passed in. This function will be used by each test case to check that the page/translation table attributes match the memory protection requirements and enables more precise reporting of regions which do not match the requirements.
6. Updates the DXE paging audit shell tests to use ValidatePageTableAttributes() to determine policy compliance.

How This Was Tested

This was tested on Q35 and an ARM platform. Some changes in test caused the UnallocatedMemoryIsRP() test to erroneously fail due to reason 1 above which has been fixed with this patch set. Additionally, this patch set was checked by comparing the shell test output to the full HTML paging audit to verify that errant regions are exact and consistent.

Integration Instructions

N/A

🐛 Bug Fixes

DxePagingAuditTestApp: When checking an image section characteristics, a bitmasking is done which incorrectly includes a logical OR instead of a bitwise OR.
FlatPageTableLib: The AARCH64 IsPageReadable() routine correctly checks for the no access, r/w case (0b00) but not the r/w, r/w case (0b01) because both 0b11 and 0b01 would pass the latter check.

• 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 Surface ARM platform and SBSA

Integration Instructions

N/A

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

What's Changed

This was discovered in a platform that uses AdvancedLogger Starting in Pei, but without permanent memory until after MRC runs.
(i.e. AdvancedLoggerLib PeiCore instance allocates CAR heap for the log buffer)

The platform makes uses of EFI_PEI_TEMPORARY_RAM_DONE_PPI, where is tears down all variable range MTRRs.

When PeiCore is reentered after memory has become available, it will relocate Hobs to system memory, then it will go through the Hobs and fix up the memory allocation pointers to point to the system memory addresses instead of the Heap addresses.

During this transition, the PlatformBlob pointer will become invalid, after CAR is torn down.

During the PeiCore's PeiServicesInstallPpi (&mMemoryDiscoveredPpi);, a debug message will attempt to be output about the Install PPI: of the Memory Discovered Ppi, and the current logic will attempt to use the PlatformBlob, which results in a memory exception (the pointer is all Fs).

This PR updates the logic in AdvancedLoggerGetLoggerInfo to verify the PlatformBlob pointer contains the correct signature before returning it, and if that fails, it then will go through Memory Allocation Hobs to try to find a memory allocation that corresponds to the AdvancedLogger buffer. If it fails, it will fall through to the existing functionality of creating a new allocation hob.

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

Verified that the system that was triggering an exception was able to function correctly after this change was incorporated.

Integration Instructions

N/A

  </blockquote>
  <hr>
</details>

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

What's Changed

🚀 Features & ✨ Enhancements

This PR introduces a "v2" implementation of UefiHidDxe that has significant refactoring to support unit tests and architectural improvements.

• UefiHidDxeV2 code coverage with unit tests is ~80% or greater for all modules of the UefiHidDxe crate
• Better separation between FFI layers and native rust layers

The long term plan is to eventually remove the original UefiHidDxe in favor of this implementation.

• Impacts functionality?
  • Driver provides the same functionality as UefiHidDxe which should be considered deprecated going forward.
• Impacts security?
• Breaking change?
• Includes tests?
  • Includes Rust unit tests covering all new modules.
• Includes documentation?
  • Standard rustdocs included.

How This Was Tested

Tested under QEMU using simulated USB keyboard and mouse.

Integration Instructions

UefiHidDxeV2 is a drop-in replacement for UefiHidDxe; platforms that wish to move to the new implementation can do so by pulling in the new UefiHidDxeV2 and adding the necessary mockall crate to their workspace Cargo.toml.

📖 Documentation Updates

This PR introduces a "v2" implementation of UefiHidDxe that has significant refactoring to support unit tests and architectural improvements.

• UefiHidDxeV2 code coverage with unit tests is ~80% or greater for all modules of the UefiHidDxe crate
• Better separation between FFI layers and native rust layers

The long term plan is to eventually remove the original UefiHidDxe in favor of this implementation.

• Impacts functionality?
  • Driver provides the same functionality as UefiHidDxe which should be considered deprecated going forward.
• Impacts security?
• Breaking change?
• Includes tests?
  • Includes Rust unit tests covering all new modules.
• Includes documentation?
  • Standard rustdocs included.

How This Was Tested

Tested under QEMU using simulated USB keyboard and mouse.

Integration Instructions

UefiHidDxeV2 is a drop-in replacement for UefiHidDxe; platforms that wish to move to the new implementation can do so by pulling in the new UefiHidDxeV2 and adding the necessary mockall crate to their workspace Cargo.toml.

Full Changelog: https://github.com/microsoft/mu_plus/compare/v2023020004.0.5...v2023020004.1.0

What's Changed

1. Add header guards missing in some files

   Some header files, such as those which define structures,
   cannot be included more than once within a translation unit, as doing
   so would cause a redefinition error. Such headers must be guarded to
   prevent ill-effects from multiple inclusion. Similarly, if header
   files include other header files, and this inclusion graph contains
   a cycle, then at least one file within the cycle must contain header
   guards in order to break the cycle. Because of cases like these, all
   headers should be guarded as a matter of good practice, even if they
   do not strictly need to be.

   Furthermore, most modern compilers contain optimizations which are
   triggered by header guards. If the header guard strictly conforms
   to the pattern that compilers expect, then inclusions of that
   header other than the first have absolutely no effect: the file
   isn't re-read from disk, nor is it re-tokenised or re-preprocessed.
   This can result in a noticeable, albeit minor, improvement to
   compilation time.

2. MsWheaPkg/MsWheaEarlyStorageLib: Remove unused static function

   Removes MsWheaCMOSStoreClearAll() which is scoped to the file and
   not used. Improves code readability and maintenance.

3. MsWheaPkg/MsWheaEarlyStorageLib: Remove unsigned comparisons to zero

   Removes an unnecessary condition since unsigned values are always
   greater than or equal to 0.

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

Integration Instructions

N/A

🐛 Bug Fixes

Checks the index is within expected bounds before accessing the array.

• 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

CodeQL and package compilation.

Integration Instructions

N/A

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

What's Changed

📖 Documentation Updates

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

Description

This change added support for enablement/disablement of advanced file logger through policy services. Platforms intending to support this functionality should produce policy prior to the driver load. The default configuration is set to file logger enabled.

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 Q35 and verified that not creating policy will remain producing log files, and disabling the policy will prevent the driver from logging any files to ESP.

Integration Instructions

In platform code, use SetPolicy with gAdvancedFileLoggerPolicyGuid to produce a policy entry for file logger driver to consume.

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

What's Changed

This change updated some print levels and added the PDB name for images being looked at.

• 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 proprietary virtual ARM platform and verified updated prints works as expected.

Integration Instructions

N/A

🐛 Bug Fixes

1. MemoryOutsideEfiMemoryMapIsInaccessible checks if memory not present in the EFI memory map has the EFI_MEMORY_RP attribute. The previous version of this test assumed that the memory range spanned by the EFI memory map was contiguous which is sometimes not the case on platforms. This update changes the flow of the test to look at interstitial gaps in the memory map and not just those on the flanks.

2. The EFI memory map returned through the boot services table is sometimes out of order. This update sorts the memory map and memory space map whenever they're populated for a test.

3. The X64 MemoryOutsideEfiMemoryMapIsInaccessible HTML test had a typo which is fixed in this update.

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

Integration Instructions

N/A

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

What's Changed

MemoryProtectionTestApp was written before Project Mu supported an ARM platform and Standalone MM. The test app generates the test cases for both the SMM and DXE environments. The SMM tests will report failure for Arm platforms and platforms using Standalone MM, so this update separates the test app into SMM and DXE versions.

The SMM version will still require a driver to handle the SMI calls. To reduce confusing naming, MemoryProtectionTestSmm (the driver supporting SMM memory protection testing) has been renamed to SmmMemoryProtectionTestDriver.

NOTE: Removing the old test app will be delayed for a couple of weeks to give consumers a chance to switch references in their DSC files.

• 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

SMM test was checked on a physical x86 platform. The DXE test was checked on Q35 and SBSA

Integration Instructions

Instances of

UefiTestingPkg/FunctionalSystemTests/MemoryProtectionTest/App/MemoryProtectionTestApp.inf

will need to be updated to

UefiTestingPkg/FunctionalSystemTests/MemoryProtectionTest/App/SmmMemoryProtectionTestApp.inf UefiTestingPkg/FunctionalSystemTests/MemoryProtectionTest/App/DxeMemoryProtectionTestApp.inf

And instances of

UefiTestingPkg/FunctionalSystemTests/MemoryProtectionTest/Smm/MemoryProtectionTestSmm.inf

will need to be updated to

UefiTestingPkg/FunctionalSystemTests/MemoryProtectionTest/Driver/SmmMemoryProtectionTestDriver.inf

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

What's Changed

The reset test method is not supported on ARM platforms currently (support will be added later, but it's not high priority because this test method often takes 40+ minutes). This PR separates the initialization of this testing method to architecture specific logic so the test method is not attempted on ARM platforms.

This also fixes a build error on ARM platforms caused by DefaultExceptionHandlerLib being included (which does not support UEFI_APPLICATION without a MU override).

• 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 updated test app on Q35 and SBSA

Integration Instructions

N/A

🚀 Features & ✨ Enhancements

Adds SecureBootKeyStoreLib which provides secureboot key store options by consuming fixed at build PCDs that represent the Pk, Db, 3PDb, Kek, and Dbx.

• Impacts functionality?
  • Adds 5 new PCDs to represent the Pk, Db, 3PDb, Kek, and Dbx, which are consumed by SedcureBootKeyStoreLibOem when configuring SecureBoot.
• 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 secureboot is properly enabled on Qemu35Pkg for Microsoft and Microsoft 3rd party.

Integration Instructions

Generate the following PCDs for your platform DSC:

1. gOemPkgTokenSpaceGuid.PcdDefaultKek
2. gOemPkgTokenSpaceGuid.PcdDefaultDb
3. gOemPkgTokenSpaceGuid.PcdDefault3PDb
4. gOemPkgTokenSpaceGuid.PcdDefaultDbx
5. gOemPkgTokenSpaceGuid.PcdDefaultPk

It is highly suggested, but not required, that each pcd is generated by running BaseTools BinToPcd over the binary blobs created in secureboot_objects, then including them in the platform's DSC file.

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

What's Changed

⚠️ Breaking Changes

Splitting inf's for PEI and DXE FrameBufferMemDrawLib to support building for 64bit PEIM.

• 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?
    Remove old inf path and add the separate PEI and DXE inf to DSC files.
• 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 platform packages consuming the library can build fine and FrameBufferDraw works as expected for PEI and DXE graphics.

Integration Instructions

Update dsc file to remove the old inf path and include separate PEI and DXE infs.

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

What's Changed

🚀 Features & ✨ Enhancements

Adds several enhancements to the TpmReplay feature script.

Add crypto agile log format support

Allows TCG event logs with the "crypto agile format" to be decoded
similar to those generated for TPM Replay by the script.

This includes the log produced by Windows (usually present in the
C:\Windows\Logs\MeasuredBoot directory).

The log is passed with the existing log input parameter "-e".

Example:
TpmReplay.py -e WindowsLog.log -o YamlLog.yaml -l TxtLog.txt -v

Add UEFI variable decode support

Adds the capability to recognize UEFI variable data in UEFI variable
events (e.g. EV_EFI_VARIABLE_DRIVER_CONFIG) and output that to the
YAML file and text log.

This makes inspecting and configuring UEFI variables more user
friendly.

tcg_platform.py: Add SHA1 support

Add support for accepting SHA1 hashes. Updates the JSON schema to
accept 160-bit values for SHA1 hashes.

Use a local logger

Uses a local logger instance to avoid using the root logger to avoid
picking up log output from external libraries.

Add variable data hex view to log

Updates the string formatting for UEFI variable data to return a
hexadecimal string followed by a decoded ASCII representation to
make the data easier to view.

This can be seen in a file specified using the -l parameter in
combination with -v to output verbose text to the file.

Readme.md: Add new log and variable details

Describes crytpo agile event log and UEFI variable decode support.

Note: There are some general improvements that can be made to the overall design of
the code. That would require a bit of a refactor that I don't have time for at
the moment. Such as using inheritance in a few places that could benefit from it
and reorganizing some of the code 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

• Existing PCR0-7 YAML file to binary.
• TPM replay log binary back to YAML file.
• Windows event log to YAML file.
  • Resulting YAML file to TPM replay binary.

Integration Instructions

N/A - Details captured in readme. No backward incompatible changes.

📖 Documentation Updates

This PR implements 3 enhancements for the RustAdvancedLoggerDxe driver:

• Removes spinlocks altogether. State that used to be shared (in particular, the current log level while generating a multi-part log message) is now on the stack.
• Add function!() macro that returns the current function name as a static string.
• Add std feture that maps debug!() and by extension debugln!() macros to std::println;

• Impacts functionality?
• Impacts security?
• Breaking change?
• Includes tests?
  • Existing unit tests updated to accommodate new design.
• Includes documentation?
  • Existing docs updated to accommodate new design.

How This Was Tested

Unit tests pass, new features validated in both unit test environment (std feature active and mapping to std::print) and qemu UEFI boot (std feature not active, using AdvLogger protocol).

Integration Instructions

N/A - existing code should function as-is.

[dev-dependencies]
RustAdvancedLoggerDxe = {workspace=true, features=["std"]}

New code that wants to take advantage of std can activate it for tests by specifying it as a feature for RustAdvLoggerDxe in dev-dependencies as shown above.

Full Changelog: https://github.com/microsoft/mu_plus/compare/v2023020003.3.1...v2023020003.4.0

What's Changed

🐛 Bug Fixes

EDK2 added EfiUnacceptedMemoryType to the memory type list. This update adds this memory type to the memory protection test app and skips it because it is not allocatable.

• 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 test on Q35

Integration Instructions

N/A

🔐 Security Impacting

Update one DSC file to use the new stack cookie library, and MdePkg/MdeLibs.dsc.inc contains the definitions for the new stack cookie libraries for the remaining DSC files.

• 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 GCC and MSVC builds

Integration Instructions

N/A

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

What's Changed

Fix an issue where rust boot services allocator implementation could deadlock if memory allocations were attempted at different TPLs. Deadlock occurs in following scenario:

1. Task running at low TPL initiates an allocation request.
2. While that allocation is in progress and the lock is held, an interrupt occurs, and a new task executes at a higher TPL
3. new task attempts an allocation.

Deadlock occurs because the higher TPL task cannot acquire the lock because it is held by the lower TPL task, and the lower TPL task cannot make forward progress because it has been interrupted by the higher TPL task.

To resolve this, this PR updates the allocation implementation to remove the spinlock. An AtomicPtr is used to give well-ordered access to the bootservices pointer used as the basis for the allocation implementation. Other aspects of the implementation (i.e. creation of the allocation tracker) are already thread-safe or are the responsibility of the boot services implementation.

PR also contains some minor style cleanup.

• Impacts functionality?
• Impacts security?
• Breaking change?
• Includes tests?
  • RustBootServicesAllocatorDxe unit tests updated to accommodate new implementation.
• Includes documentation?

How This Was Tested

Verified boot on QEMU.

Integration Instructions

N/A

🚀 Features & ✨ Enhancements

USB HID specification 1.11 (https://www.usb.org/document-library/device-class-definition-hid-111) section 7.2.6 states:

When initialized, all devices default to report protocol. However the host should 
not make any assumptions about the device’s state and should set the desired 
protocol whenever initializing a device. 

In testing actual devices, it has been observed that some actual endpoint HID devices come up in "boot protocol" rather than "report protocol." This PR implements the recommendation that the host (in this case, the UsbHidDxe driver) not make any assumptions about device state, and explicitly sets report protocol for devices that implement the "boot" interface subclass.

The PR also makes a minor adjustment to debug verbosity.

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

How This Was Tested

Verified with QEMU that command is sent; verified with hardware that has this issue that SetProtocol resolves it.

Integration Instructions

N/A

This PR resolves an issue where invocation of the debugln!() macro could result in deadlock due to contention between two different TPL levels. The deadlock occurs in the following scenario:

1. A task running at a lower TPL invokes debugln!() and acquires the spinlock on the logger object.
2. That task is interrupted by a TPL running at a higher level (the lower task has not released the lock).
3. The higher TPL invokes debugln!().

In this scenario, the higher TPL task cannot make forward progress because it cannot acquire the lock held by the lower TPL task, and the lower TPL task is not executing because it was interrupted by the higher TPL task.

This resolves the issue by changing the "lock" to a "try_lock" - in the scenario above, this allows the higher TPL task to make forward progress. This has the downside of dropping the message from the higher TPL task; so this is only intended as an interim fix.

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

How This Was Tested

Reproduced the issue using QEMU emulator; with this change the above flow no longer deadlocks.

Integration Instructions

N/A

🐛 Bug Fixes

This PR resolves an issue where invocation of the debugln!() macro could result in deadlock due to contention between two different TPL levels. The deadlock occurs in the following scenario:

1. A task running at a lower TPL invokes debugln!() and acquires the spinlock on the logger object.
2. That task is interrupted by a TPL running at a higher level (the lower task has not released the lock).
3. The higher TPL invokes debugln!().

In this scenario, the higher TPL task cannot make forward progress because it cannot acquire the lock held by the lower TPL task, and the lower TPL task is not executing because it was interrupted by the higher TPL task.

This resolves the issue by changing the "lock" to a "try_lock" - in the scenario above, this allows the higher TPL task to make forward progress. This has the downside of dropping the message from the higher TPL task; so this is only intended as an interim fix.

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

How This Was Tested

Reproduced the issue using QEMU emulator; with this change the above flow no longer deadlocks.

Integration Instructions

N/A

Full Changelog: https://github.com/microsoft/mu_plus/compare/v2023020003.2.2...v2023020003.3.0

What's Changed

This change adds an inspection of mLoggerInfo variable before reading from GetTime() runtime service. As the advanced logger design expects the mLoggerInfo to be set to NULL, we should always check the pointer before usage, otherwise page fault could occur under certain edge cases.

• 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 QEMU Q35 platform.

Integration Instructions

N/A

Full Changelog: https://github.com/microsoft/mu_plus/compare/v2023020003.2.1...v2023020003.2.2

What's Changed

🐛 Bug Fixes

When using advanced logger starting from DxeCore, the library constructor will allocate space for the advanced logger buffer.
When this allocation takes place, the associated global variable mMaxAddress will be created to specify the last address for the log buffer.

In the DxeCore case, the calculation for mMaxAddress did not take into account the size of the ADVANCED_LOGGER_INFO structure that is at the start of the buffer, resulting in an inconsistent address between mMaxAddress and LoggerInfo->LogBuffer + LoggerInfo->LogBufferSize

All other instances of this code use LoggerInfo->LogBuffer + LoggerInfo->LogBufferSize, so change DxeCore library instance to use the same logic as other library instances.

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

Found by setting debug messages to such a high level that the end of the buffer was reached, resulting in incorrect checks of mMaxAddress overwriting the end of the buffer.

Incorrect logic was tripped up in ValidateInfoBlock() where mMaxAddress would cause a return of false, which in turn would result in NULL being returned from an arbitrary call to AdvancedLoggerGetLoggerInfo.

Integration Instructions

n/a

📖 Documentation Updates

Log retrieval information is not as accessible as it could be. Adding some blurbs to make the information more accessible at the top level.

• 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/v2023020003.2.0...v2023020003.2.1

What's Changed

🚀 Features & ✨ Enhancements

Adds an instance of PanicLib that outputs through advanced logger
using AdvancedLoggerLib.

This allows platforms already using advanced logger to use this
library instance which can decrease the size impact as opposed to
linking to output stacks like serial that might be redundant when
advanced logger is active.

• 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

• Physical IA32/X64 platform with advanced logger used in PEI

Example of a test PANIC() placed in ResetSystemPei through this library
instance:

PANIC [ResetSystemPei] d:\src\ws\MU_BASECORE\MdeModulePkg\Universal\ResetSystemPei\ResetSystem.c(110): Test panic

Integration Instructions

Use this library instance if routing panic messages through advanced logger
is preferred.

📖 Documentation Updates

Adds HID keyboard support to UefiHidDxe input driver.

• Impacts functionality?
  • Adds keyboard support.
• Impacts security?
• Breaking change?
• Includes tests?
• Includes documentation?
  • standard rustdocs

How This Was Tested

Tested with USB keyboard support in QEMU. Early iterations also tested in hardware.

Integration Instructions

Platforms will need to add HiiKeyboardLayout = {path = "HidPkg/Crates/HiiKeyboardLayout"} to the [workspace.dependencies] in their cargo.toml if not already present.

Adds an instance of PanicLib that outputs through advanced logger
using AdvancedLoggerLib.

This allows platforms already using advanced logger to use this
library instance which can decrease the size impact as opposed to
linking to output stacks like serial that might be redundant when
advanced logger is active.

• 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

• Physical IA32/X64 platform with advanced logger used in PEI

Example of a test PANIC() placed in ResetSystemPei through this library
instance:

PANIC [ResetSystemPei] d:\src\ws\MU_BASECORE\MdeModulePkg\Universal\ResetSystemPei\ResetSystem.c(110): Test panic

Integration Instructions

Use this library instance if routing panic messages through advanced logger
is preferred.

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