Bot releases are visible (Hide)
Published by github-actions[bot] 25 days ago
Add GoogleTest for AdvancedLogger DxeCore Lib
Add mock for AdvancedLoggerHdwPortLib
CI
N/A
Local CI. Building the test locally.
N/A
Create Mock for DeviceBootManagerLibNull
For details on how to complete to complete these options and their meaning refer to CONTRIBUTING.md.
Unit tests component can call these mock functions success
N/A
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.
Built and tested in 202311 branch
N/A
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
Local CI and unit test.
N/A
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.
Built and tested in 202311 branch
N/A
Full Changelog: https://github.com/microsoft/mu_plus/compare/v2024050000.0.0...v2024050001.0.0
Published by github-actions[bot] 25 days ago
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.
Ran the CI build for all packages in mu_plus for the X64 architecture. All tests passing.
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.
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.
Tested on Q35.
N/A.
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.
Tested on Q35.
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.
Ran the CI build for all packages in mu_plus for the X64 architecture. All tests passing.
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.
Ran CI for X64 Architecture. All Test Passed.
N/A
Full Changelog: https://github.com/microsoft/mu_plus/compare/v2023110002.0.2...v2023110003.0.0
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
Published by github-actions[bot] about 2 months ago
Fix an issue where the wrong format specifier was used for an ASCII string.
Observed that ID_NOT_FOUND string was properly formatted.
N/A
There are multiple copies of VariableSupportLib floating across repos, mostly only supporting Windows.
Functionality has been consolidated into edk2-pytool-library version 0.21.7. Support for Linux has been added.
Switch MfciPolicy.py, DecodeUefiLog.py and UefiVarAudit.py to use consolidated version from edk2-pytool-library.
Removed local copies of VariableSupportLib.py
N/A
Fixes #554
This resolves the issue of the trash can icon overlapping with the ListBox's deletable item's checkbox thus ensuring its related operations work correctly: activating/deactivating the Load Option or deleting it.
Verified that a Load Option allowed to be deleted, such as 'Windows Boot Manager', can now be deleted by pressing the trash icon in its proper position or activated via its check-box.
N/A
Full Changelog: https://github.com/microsoft/mu_plus/compare/v2023110002.0.1...v2023110002.0.2
Published by github-actions[bot] 2 months ago
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.
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
N/A
Full Changelog: https://github.com/microsoft/mu_plus/compare/v2023110002.0.0...v2023110002.0.1
Published by github-actions[bot] 2 months ago
This PR cherry-picks one full commit and one very small part of another commit from 202311:
This is a complete cherry-pick from c024ed1e61108d71e7e8fa4693c2d55839f87ac0. It adds support for File Logger to create the UefiLogs directory on non-NVMe devices.
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.
N/A
N/A
Full Changelog: https://github.com/microsoft/mu_plus/compare/v2023020006.1.2...v2023020006.1.3
Published by github-actions[bot] 3 months ago
For each item, place an "x" in between [
and ]
if true. Example: [x]
.
(you can also check items in the GitHub UI)
Test that the keyboard was still working.
N/A
Remove usage of custom Pi Status code to use one defined in spec, EFI_SW_EC_ILLEGAL_SOFTWARE_STATE
.
CI
For any telemetry report that used EFI_SW_EC_RELEASE_ASSERT
, replace with EFI_SW_EC_ILLEGAL_SOFTWARE_STATE
Fix issues in coordinate calculation to solve On-screen keyboard render issue, and potential issues in other UI widgets.
See https://github.com/microsoft/mu_plus/issues/518
The SWM_RECT structure defines a standard bounding rectangle by specifying the left, top, right, and bottom coordinates. For any SWM_RECT instance, the width is calculated as width = right - left + 1
, and the height is determined by height = bottom - top + 1
. When the origin point of a rectangle is known, along with its width and height, the right coordinate can be derived using right = left + width - 1
, and the bottom coordinate is given by bottom = top + height - 1
. Ensuring the correct application of these formulas prevents the On-Screen Keyboard (OSK) boundary from exceeding its defined limits.
Boot to UEFI menu, all UI items rendered correctly and OSK functioned well.
N/A
Previously in MemoryTypeInformationChangeLib, we were using a custom Status Code. That code is being removed from MU_BASECORE in PR #1001 and we're using an existing code from PI Spec, EFI_SW_EC_ILLEGAL_SOFTWARE_STATE instead.
CI
Upgrading to or already using mu_basecore release/202311, change any reference to the macro as follows:
Any instances of EFI_SW_EC_MEMORY_TYPE_INFORMATION_CHANGE
will need to be replaced with EFI_SW_EC_ILLEGAL_SOFTWARE_STATE
Security.Misc.MemoryOutsideEfiMemoryMapIsInaccessible was failing because it was not checking the return status of
ValidateRegionAttributes, which could return EFI_NO_MAPPING to indicate a given range was not in the page table. There are two independent criteria that can be satisfied to indicate that a region is inaccessible: it is marked EFI_MEMORY_RP or it is not mapped in the page table. This test was only checking the first case and not the second case. With this update it now correctly checks both cases.
Tested on Q35 and saw that the formerly failing test is now passing.
N/A.
Full Changelog: https://github.com/microsoft/mu_plus/compare/v2023110001.0.3...v2023110002.0.0
Published by github-actions[bot] 3 months ago
Please ensure you have read the contribution docs prior
to submitting the pull request. In particular,
pull request guidelines.
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)
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!
N/A
Full Changelog: https://github.com/microsoft/mu_plus/compare/v2023110001.0.2...v2023110001.0.3
Published by github-actions[bot] 3 months ago
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.
Local CI passed after change.
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.
Tested on a system with a non-NVMe drive that failed to have the FileLogger directory created before this change and succeeds now.
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
Ran cargo make test
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)
Ran Local CI to verify unit tests change.
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.
Functionally verified with a touch panel implementation that exposes these HID usages.
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.
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)
The test does not change result.
N/A
</blockquote>
<hr>
</details>
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?
[x ] Impacts security?
Breaking change?
Includes tests?
Includes documentation?
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
Published by github-actions[bot] 5 months ago
Please ensure you have read the contribution docs prior
to submitting the pull request. In particular,
pull request guidelines.
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)
This is tested building with CLANGPDB. The build failure is gone after the fix.
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)
Building on GCC.
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
Tested in the uefi shell. The tests should get positive results and no errors are reported.
N/A
Please ensure you have read the contribution docs prior
to submitting the pull request. In particular,
pull request guidelines.
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)
Unit test passed on QEMU SBSA platform built with CLANGPDB.
N/A
</blockquote>
<hr>
</details>
Full Changelog: https://github.com/microsoft/mu_plus/compare/v2023110001.0.0...v2023110001.0.1
Published by github-actions[bot] 5 months ago
In TcgMorLockSmm.c the SetVariableCheckHandlerMorLock() function was changed to set the MorLock variable Value to 0x01 to indicate Locked Without Key to match the spec when addressing a possible dictionary attack.
The commit in question is here.
This PR changes the checked test results to match the new expected behavior.
Tested in the uefi shell. The tests that previously failed now pass.
N/A
In two places in the Adv Logger v5 update, the incorrect macro was used to calculate mMaxAddress, which led to the log not being fully printed on some architectures. Fixing these leads to the log to be printed.
For each item, place an "x" in between [
and ]
if true. Example: [x]
.
(you can also check items in the GitHub UI)
Tested on a physical platform where this was broken.
N/A. On Mu rebase, this commit can be merged with the AdvLogger v5 commit.
MSVC does not allow inline Assembly, so some logic which reads an ARM register needed to be moved to a separate nasm file: https://learn.microsoft.com/en-us/cpp/assembler/inline/inline-assembler?view=msvc-170
Tested by building the module with MSVC
N/A
This adds a PRM Module to fetch the Advanced Logger Log. It includes a sample Windows drive to query the PRM module and get the log. It also updates the Advanced Logger structure to V5 to use offsets instead of pointers for LogCurrent and LogBuffer. It updates DecodeUefiLog.py to be able to read this V5 structure.
Tested on Q35 on mu_tiano_platforms by booting to Windows, running the sample driver to fetch the log, then decoding with DecodeUefiLog.py. Also tested on various physical platforms.
See README updates for integration instructions.
Fix an error made in the AdvLogger v5 PR (#471). This is the same fix (but for a different variable name which is why it was mixed on the last fix up) as #483.
Usage of mHighAddress (and mMaxAddress) will be evaluated as part of issue #474.
Tested on Q35, LineParserTestApp was failing because of this.
N/A for a platform. For the next Mu integration, this should be combined with the Advanced Logger v5 commit be9a3d273ffabebca606266c6cb3a47bbf49c4d5.
This adds a PRM Module to fetch the Advanced Logger Log. It includes a sample Windows drive to query the PRM module and get the log. It also updates the Advanced Logger structure to V5 to use offsets instead of pointers for LogCurrent and LogBuffer. It updates DecodeUefiLog.py to be able to read this V5 structure.
Tested on Q35 on mu_tiano_platforms by booting to Windows, running the sample driver to fetch the log, then decoding with DecodeUefiLog.py. Also tested on various physical platforms.
See README updates for integration instructions.
This adds a PRM Module to fetch the Advanced Logger Log. It includes a sample Windows drive to query the PRM module and get the log. It also updates the Advanced Logger structure to V5 to use offsets instead of pointers for LogCurrent and LogBuffer. It updates DecodeUefiLog.py to be able to read this V5 structure.
Tested on Q35 on mu_tiano_platforms by booting to Windows, running the sample driver to fetch the log, then decoding with DecodeUefiLog.py. Also tested on various physical platforms.
See README updates for integration instructions.
Adding a sample python script that enables retrieving Policy information from a system.
Script enables applying a new policy into the mailbox for processing on next reboot.
Script enables deleting an existing policy (forcing the system back into its default policy on reboot)
For each item, place an "x" in between [
and ]
if true. Example: [x]
.
(you can also check items in the GitHub UI)
Tested from Windows.
N/A
Readme.md specified that AdvancedLoggerLib SMM_CORE instance was to use SMM instance.
Corrected document to point to SmmCore instance.
For each item, place an "x" in between [
and ]
if true. Example: [x]
.
(you can also check items in the GitHub UI)
N/A
Documentation change only.
N/A
Full Changelog: https://github.com/microsoft/mu_plus/compare/v2023110000.0.6...v2023110001.0.0
Published by github-actions[bot] 6 months ago
This PR brings in two fixes to support a wider variety of devices, some of which might not be completely self-consistent:
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.Rust unit tests updated to cover new functionality all pass. Functional testing on hardware with the changes also passes.
N/A
</blockquote>
<hr>
</details>
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.
This is a non-functional change.
N/A
Full Changelog: https://github.com/microsoft/mu_plus/compare/v2023110000.0.5...v2023110000.0.6
Published by github-actions[bot] 6 months ago
Please ensure you have read the contribution docs prior
to submitting the pull request. In particular,
pull request guidelines.
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)
This is tested on QEMU SBSA as well as Q35. Both booted to UEFI shell.
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)
Tested by running the shell app on Q35 and confirming it still succeeds.
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.
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)
Built and ran on ARM and x64 machines. Verified output was identical to DecodeUefiLog script raw dump.
N/A
Full Changelog: https://github.com/microsoft/mu_plus/compare/v2023110000.0.4...v2023110000.0.5
Published by github-actions[bot] 6 months ago
For the case where advanced logger starts in the PeiCore (through a memory allocation hob in CAR) when attempting to recover the log buffer from the hob list after peicore and transitioned everything to physical ram, the internal pointers in the log buffer also need to be updated to point to the start of the log buffer and the next available log buffer entry.
Tested on a platform where logging starts at peicore into a CAR Hob.
Platform uses gEfiTemporaryRamDonePpiGuid to tear down CAR prior to gEfiPeiMemoryDiscoveredPpiGuid being notified to allow the debugger to switch over to physical ram.
N/A
Fix wrong comment. This module produces gMfciProtocolGuid, and we used this module for the implementation.
No. Just a comment fix.
N/A. Just a comment fix.
Full Changelog: https://github.com/microsoft/mu_plus/compare/v2023110000.0.3...v2023110000.0.4
Published by github-actions[bot] 7 months ago
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.
N/A
Full Changelog: https://github.com/microsoft/mu_plus/compare/v2023110000.0.2...v2023110000.0.3
Published by github-actions[bot] 8 months ago
An instance of StackCheckLib must be in each DSC to accommodate -fstack-protector and /GS flags.
Tested in pipelines
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
.
N/A
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.
Ran CI locally
n/a
Full Changelog: https://github.com/microsoft/mu_plus/compare/v2023020006.1.1...v2023020006.1.2
Published by github-actions[bot] 8 months ago
An instance of StackCheckLib must be in each DSC to accommodate -fstack-protector and /GS flags.
Tested in pipelines
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.
Tested by creating the HOB and verifying that the DxeCore constructor located it.
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
.
N/A
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.
Ran CI locally
n/a
Full Changelog: https://github.com/microsoft/mu_plus/compare/v2023110000.0.1...v2023110000.0.2
Published by github-actions[bot] 8 months ago
Removes edk2-basetools from pip-requirements.txt and any usage of it in the CISettings.py. The is done as there are changes in the build tools python source code that are available locally in BaseTools (as it is managed by Project Mu) that is not available in edk2-basetools.
Verified the build system continues to use the local python source
N/A - only effects this repository's CI system.
The Advanced logger Arm MM Core library may be invoked before the imagine has completed it's PeCOFF section attribute fixup. Previously this was handled by explicitly mapping the data page need for the adv logger globals to be writable, but this leads to potential infinite recursion if any of the functions in the MMU stack calls a print. Instead this change is to remove the dependence on global variables and so remove the need for external calls in these library functions.
Tested and validated presence of MM logs in serial output and adv logger buffer.
N/A
As part of 202311, ArmMmuLib switched to use ArmSetMemoryAttributes instead of the individual set/clear routines. This was also implemented in the MU change to converge ArmMmuStandaloneMmLib's use with ArmMmuLib. This changed fixes MmCoreArm/AdvancedLoggerLib.c to use the updated functions.
It seems this went unnoticed originally due to issue #434
Manually tested.
N/A
Full Changelog: https://github.com/microsoft/mu_plus/compare/v2023110000.0.0...v2023110000.0.1
Published by github-actions[bot] 9 months ago
First 202311 Mu Plus release 🎉.
Cherry-pick the commits from 202302 that are missing from 202311 since the creation of the release branch.
CI
N/A
Please ensure you have read the contribution
docs prior to submitting the pull request. In particular,
pull request
guidelines.
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)
This was tested on both QEMU Q35 and proprietary hardware platform returned advanced logger buffer binary.
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.
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)
This change was tested on proprietary hardware with multiple cores.
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.
Tested with CI.
N/A
Update HelloWorldRustDxe to allow compiling tests.
Cargo test executes sample unit test as expected.
Build for UEFI target and execution QEMU work as expected.
N/A
The protocol was upstreamed to r-efi 4.3.0 and can be picked up from there now.
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.
Update to a Mu Plus release with this change.
Adds 5 tests to the HTML templates:
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)
Build tested.
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.
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
Tested on a platform that was triggering asserts.
Tested in CI
N/A - Changes should be
Running the paging audit on Q35 and SBSA
N/A
Fixes the following issues with GetGraphicsInfo()
.
EFIAPI
. This is an internal function to the libraryResolves 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 (
| ^
CI build.
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)
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.
N/A
Adds PrEval entries for all packages to enable the new PrEval Policy 5.
N/A
N/A
Please ensure you have read the contribution docs prior
to submitting the pull request. In particular,
pull request guidelines.
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)
This was tested on selfhost-agents and existing agents.
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)
Built and booted a physical platform with these changes.
N/A
Please ensure you have read the contribution docs prior
to submitting the pull request. In particular,
pull request guidelines.
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)
This was tested on ARM FVP virtual platform with 16 cores. A shell based unit test is used for validation.
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?
Verified in test pipelines.
N/A - No developer integration required
Signed-off-by: Michael Kubacki [email protected]
Updated pipelines to only run CI and PR gates on release/202208 and release/202202.
Pipelines passed.
N/A
Converts line endings in the following packages:
Verified CI build results. Checked new line endings.
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]
N/A
To keep pip dependencies up to date.
Confirmed file matches contents of the file working in other repos.
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).
Verified in CI builds
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: }
This may be re-evaluated in the future, but it should also encourage drivers to move away from VariableLockProtocol and towards VariablePolicyProtocol.
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.
Verified with functional testing of several different exclusions in Qemu Q35.
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 -->
## 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 -->
## 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 -->
## 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 -->
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 -->
## 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 -->
## 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 -->
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 -->
## 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 -->
## 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 -->
## 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 -->
## 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 -->
# 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 -->
## 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 -->
## 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 -->
## 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 -->
## 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 -->
## 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 -->
## 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 -->
## 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 -->
## 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 -->
## 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
Published by github-actions[bot] 9 months ago
Please ensure you have read the contribution docs prior
to submitting the pull request. In particular,
pull request guidelines.
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)
This was tested on both QEMU Q35 and proprietary hardware platform returned advanced logger buffer binary.
N/A
</blockquote>
<hr>
</details>
Please ensure you have read the contribution
docs prior to submitting the pull request. In particular,
pull request
guidelines.
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)
This change was tested on proprietary hardware with multiple cores.
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.
Verified on a platform where this was not working due to missing HdwPort initialization; verified after this patch that it works as expected.
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)
N/A
N/A
</blockquote>
<hr>
</details>
Full Changelog: https://github.com/microsoft/mu_plus/compare/v2023020006.1.0...v2023020006.1.1