Feature Overview

The current event triggers lack flexibility and cannot be effectively used on some platforms.

We hope to implement something like hooks, allowing the platform to utilize these hooks to execute features.

Solution Overview

1. We plan to implement hooks at the end of dxe event before and after the event.
2. Create a hook after the boot manager dispatch the deferred 3rd party images Event.

Alternatives Considered

No response

Urgency

Medium

Are you going to implement the feature request?

I will implement the feature

Do you need maintainer feedback?

No maintainer feedback needed

Anything else?

No response

Rather than maintain a second copy of the OEMs that support DFCI update the docs to link to Intune which has a current list for visibility of all intune customers.

Is there an existing issue for this?

• I have searched existing issues

Current Behavior

Recently support was added in HidPkg for a Rust-based HID stack in #324.

It's been observed that a USB stall error is encountered with HID devices in some cases. We suspect those devices do not implement the full set of descriptor reads from the HID specification.

An example of such a problem on the QEMU emulated platform:

XhcCheckUrbResult: STALL_ERROR! Completecode = 6
Recovery Halted Slot = 1,Dci = 1
XhcResetEndpoint: Slot = 0x1, Dci = 0x1
XhcControlTransfer: error - Device Error, transfer - 2
[UsbGetFullHidDescriptor] unexpected failure reading HID descriptor: Device Error, Status: 0x2

ASSERT_EFI_ERROR (Status = Device Error)
ASSERT [UsbHidDxe] HidPkg\UsbHidDxe\UsbHidDxe.c(726): !(((INTN)(RETURN_STATUS)(Status)) < 0)

That QEMU Q35 platform can be used to verify changes.

Expected Behavior

A USB stall error should not be encountered as frequently trying to read HID descriptors from HID class devices.

At least in the case of QEMU, we found that (hw/usb/dev-hid.c) all descriptor type requests from the HID 1.1 specification are not supported.

Steps To Reproduce

1. Boot QemuQ35Pkg firmware with default settings using the --FlashRom command
2. Review the boot log in Build/BUILDLOG_QemuQ35Pkg_Run.txt (boots to EFI shell by default)

Build Environment

- OS(s): N/A
- Tool Chain(s): N/A
- Targets Impacted:
  - QEMU virtual platform

Version Information

- PR: #324
- Mu Plus Release v2023020002.0.2

Urgency

Low

Are you going to fix this?

Someone else needs to fix it

Do you need maintainer feedback?

No maintainer feedback needed

Anything else?

No response

Feature Overview

UefiTestingPkg provides various conformance tests for the UEFI environment. These are at least mostly generic and may be used on any UEFI implementation, including such not based on Project Mu. However, its source code has dependencies on Project Mu packages and thus cannot easily be built without a separate development environment.

For this reason, binary releases would greatly improve the usability of UefiTestingPkg outside of Project Mu platforms. Unfortunately, UefiTestingPkg.dsc is explicitly not designed to produce usable binaries as of now:

Many of the dummy library classes are effectively generic. These include:

• MemoryAllocationLib
• DebugPrintErrorLevelLib
• PcdLib

One more library class could be, but currently sometimes may not be [1]:

• HobLib

The one library class that cannot really be generic as of now is DebugLib. While this should usually not pose a problem, the default instance for the UnitTestResultReportLib library class actually is UnitTestResultReportLibDebugLib:

This means that there is no trivial way to build universal binary releases.

[1] In case a non-Null DebugLib is required, ArmVirtPkg has an ArmVirtDxeHobLib that does not depend on DebugLib. The reason is the risk for circular dependencies, such as the ArmVirt serial code that depends on HobLib:

https://github.com/microsoft/mu_silicon_arm_tiano/blob/922860bc4cb762e229b441de8a4ed2b127070168/ArmVirtPkg/Library/FdtPL011SerialPortLib/FdtPL011SerialPortLib.inf#L25

There is nothing ARM-specific about this approach and it might as well be DxeHobLibNoDebug variant (which actually could share its core code with the regular DxeHobLib).

Solution Overview

As I don't have a good overview of everyone's workloads and use cases, I can't propose a solution myself. Potential approaches I can think of are:

• Using UnitTestResultReportLibConOut for binary builds. This would trivially be universal and require only a small patch to UefiTestingPkg.dsc. However, I'm not sure parsing outputs to ConOut is common practice and well-supported. I'm not aware something like this exists, but it may require something to re-route ConOut outputs to a variety of targets, such as a serial port (which we currently use for our CI, as it can easily be routed to stdout via QEMU).

• Rather than hooking ConOut, a test result protocol can be defined by the platform ahead of launching the test application to route the test result to any arbitrary target. This would require a new instance of UnitTestResultReportLib and a driver to expose said protocol.

• The protocol could be more "generic" in the sense that it may be used for other kinds of output. For OpenCorePkg, we have a centralized logging protocol that is also utilized by DebugLib:

https://github.com/acidanthera/OpenCorePkg/blob/2e93c954023df44d7d68c4d896c32a5d07439b3c/Include/Acidanthera/Library/OcLogAggregatorLib.h

This leaves the OpenCore application in charge of the logging targets and the OpenCore drivers consuming its logging protocol. We use this approach to decide where to route logging output based on a user configuration file, which may include multiple targets at once. Naturally, a new DebugLib instance would need to be introduced. However, in this scenario, UnitTestResultReportLibDebugLib could be re-used as-is.

Alternatives Considered

No response

Urgency

Low

Are you going to implement the feature request?

Someone else needs to implement the feature

Do you need maintainer feedback?

Maintainer feedback requested

Anything else?

No response

Feature Overview

Secure Boot Recovery Application should check for the existence of the 2023 Production CA and if it's found respect the existing boot order.

This would prevent scenarios where the application appended correctly yet for some reason the device is continuing to loop.

Solution Overview

1. Loop over each certificate found in the DB
2. for each certificate, determine if it has enough length to compare against a #define thumbprint and subject name
3. compare against the #define thumbprint and subject name
4. if so return EFI_UNSUPPORTED

Alternatives Considered

No response

Urgency

Medium

Are you going to implement the feature request?

I will implement the feature

Do you need maintainer feedback?

No maintainer feedback needed

Anything else?

No response

Is there an existing issue for this?

• I have searched existing issues

Current Behavior

The transforms used in the OnScreenKeyboardDxe driver in the DisplayTransform.c file all use floats to perform calculations for rotation, positioning, scaling, etc. When doing the math for putting the keyboard in the lower right corner of the screen on certain resolutions results in a 1 pixel overrun of either the X or Y max resolution. This incorrect X or Y point eventually makes it's way to the RenderingEngineDxe driver that makes a mParentGop->Blt() call into the GOP with the 1 pixel overrun. Depending on the silicon vendor's GOP, that can have differing results from being ignored to on screen corruption.

Expected Behavior

Three areas need to be addressed:

1. The OnScreenKeyboardDriver.c driver file uses that math for several functions to scale, rotate, and position the keyboard. They all have access to a member GOP pointer, so logic should probably be added to those functions to guarantee any point in the keyboard does not go over the expected resolution.
2. The RenderingEngine.c file in the RenderingEngineDxe driver publishes a protocol that the keyboard driver uses. Since it is a public API, the driver should probably validate the inputs are acceptable and either return an error code, or debug print and clip the overrun.
3. The RenderingEngine.c file in the RenderingEngineDxe driver makes multiple calls to mParentGop->Blt() which is using the GOP protocol without checking the return status code. Again, we probably need to check the return code and pass up to the caller of the rendering protocol user.

Steps To Reproduce

Due to this being an error handler issue and needing a vendor specific GOP with specific keyboard size and specific screen resolution to get the proper rounding error in the float math, it is very difficult to reproduce. Easiest way to see the error is to modify the SREActivateSurface function call in the RenderingEngine.c file to increase the FrameWidth parameter in the mParentGop->Blt calls to be 1 pixel past the X resolution.

Build Environment

- OS(s): Windows
- Tool Chain(s): VS2022
- Targets Impacted: All

Version Information

url = https://github.com/microsoft/mu_plus
branch = release/202302
SHA = 69d1c094ca61f6d12e8c8e172b07576120e6d259

Urgency

Medium

Are you going to fix this?

Someone else needs to fix it

Do you need maintainer feedback?

Maintainer feedback requested

Anything else?

Changes have been made to the current platform in development to implement a wrapper around each of the BLT calls to clip the offending pixel, but I would assume the MU team would prefer a better fix than a patch. Please contact me for the workaround if interested.

Is there an existing issue for this?

• I have searched existing issues

Current Behavior

Currently AdvLoggerPkg and probably others are not built in CI with AARCH64 because of the SUPPORTED_ARCHITECTURES, despite having AARCH64 specific code that needs CI.

Expected Behavior

Package that are used for AARCH64 should have CI builds.

Steps To Reproduce

N/A

Build Environment

- OS(s): Ubuntu
- Tool Chain(s): GCC
- Targets Impacted: CI

Version Information

N/A

Urgency

Medium

Are you going to fix this?

I will fix it

Do you need maintainer feedback?

No maintainer feedback needed

Anything else?

No response

Feature Overview

Add the ability to write to the early storage WHEA area when a PEI exception occurs.

Document what data is ultimately stored there so platforms know how to integrate the change.

Solution Overview

When a PEI exception occurs, it would be nice to have the ability to report that information through telemetry on the following boot. The subsequent boot might be able to alter the firmware boot path to avoid the issue and then send the data to telemetry.

For example, add the EIP (4 byte address on 32-bit PEI) to CMOS so it can be retrieved on the following boot.

Alternatives Considered

No response

Urgency

Low

Are you going to implement the feature request?

Someone else needs to implement the feature

Do you need maintainer feedback?

No maintainer feedback needed

Anything else?

We were previously talking about this offline since September.

These sections need to be filled in - https://github.com/microsoft/mu_plus/blob/release/202208/Readme.rst:

Breaking Changes-dev
None

Main Changes-dev
Bug Fixes-dev

Branched from 202202
Original sync Commit: fd357a1

Is there an existing issue for this?

• I have searched existing issues

Current Behavior

wasted execution time on a hot path comparing the debug level against the PCD at both levels.

Why does calling code just mask the bits rather than avoid the function call?

Expected Behavior

Expected to be as efficient as possible and require minimal code in lower layers.

Steps To Reproduce

Look at code

Build Environment

NA

Version Information

a3d53ef6296bc0b1309cf2654017eb394a726dd4

all versions.

Urgency

Medium

Are you going to fix this?

Someone else needs to fix it

Do you need maintainer feedback?

No maintainer feedback needed

Anything else?

May have impact on downstream/out-of-tree projects and their implementations.

Feature Overview

BaseLib contains both AsciiStrLen and AsciiStrnLenS. Currently advacned logger is just using AsciiStrLen, but switching ot the safe string version does not require any additional changes.

Solution Overview

Switch to using AsciiStrnLenS, with appropriate maximum string length parameters.

Alternatives Considered

No response

Urgency

Low

Are you going to implement the feature request?

I will implement the feature

Do you need maintainer feedback?

No maintainer feedback needed

Anything else?

No response

Is there an existing issue for this?

• I have searched existing issues

Current Behavior

As MsWheaEarlyStorageLib is written, PcdMsWheaReportEarlyStorageCapacity must include the offset of the MS WHEA early storage region. This expectation is unintuitive and can lead to configuration errors and underflow in MsWheaEarlyStorageGetMaxSize().

Expected Behavior

Instead of changing the PCD to not include the offset (and consequentially force existing platforms to update) add a check that the PCD is at least as large as the offset and ASSERTs if not. Also update MsWheaESGetMaxDataCount() to avoid underflow if PcdMsWheaReportEarlyStorageCapacity - MsWheaEsOffset - WheaHeaderSize is less than zero.

Steps To Reproduce

Set PcdMsWheaReportEarlyStorageCapacity to something less than 0x40

Build Environment

Not dependent on tool chain, OS, or target

Version Information

Commit: 7df685167abe8cc8f5015bb4da9e035f876a1466

Urgency

Medium

Are you going to fix this?

I will fix it

Do you need maintainer feedback?

No maintainer feedback needed

Anything else?

No response

This function leaves the box empty ant text is never set. Just add this:

StrnCpyS(this->m_EditBoxDisplayText, sizeof(this->m_EditBoxDisplayText) / sizeof(CHAR16), NewTextString, (UIT_EDITBOX_MAX_STRING_LENGTH - 1));

after StrnCpyS (this->m_EditBoxText...

on the line 322 in function SetCurrentTextString() in MsGraphics\Library\SimpleUIToolKit\EditBox.c to make it work.

Is there an existing issue for this?

• I have searched existing issues

Current Behavior

On 32-bit ARM DisplayEngineDxe will not compile because of a linking error caused by sqrt_d in MathLib.

Expected Behavior

DisplayEngineDxe to build without errors.

Steps To Reproduce

Compile a project with ARM target that has DisplayEngineDxe requirement.

Build Environment

- OS(s): Windows 11 with WSL2 Ubtuntu 20.04
- Tool Chain(s): CLANG with arm-linux-gnueabihf-
- Targets Impacted: ARM

Version Information

Tag: release/202302

Urgency

High

Are you going to fix this?

I will fix it

Do you need maintainer feedback?

Maintainer feedback requested

Anything else?

BUILDLOG_ExampleApplePkg.txt

GCC states Dummy and FakeCertificate may be used uninitialized since it is not assigned an initial value before being passed to functions in some tests.

Dummy Example:

INFO - /s/MfciPkg/MfciDxe/Test/MfciMultipleCertsHostTest.c:317:12: error: ‘Dummy’ may be used uninitialized [-Werror=maybe-uninitialized]
INFO -   317 |   Status = ValidateBlobWithXdrCertificates (&Dummy, sizeof (Dummy), NULL, sizeof (mCert_Trusted_CA_Root_xdr));
INFO -       |            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
INFO - /s/MfciPkg/MfciDxe/Test/MfciMultipleCertsHostTest.c:144:1: note: by argument 1 of type ‘const UINT8 *’ {aka ‘const unsigned char *’} to ‘ValidateBlobWithXdrCertificates’ declared here

FakeCertificate Example:

INFO - /s/MfciPkg/MfciDxe/Test/MfciMultipleCertsHostTest.c:358:12: error: ‘FakeCertificate’ may be used uninitialized [-Werror=maybe-uninitialized]
INFO -   358 |   Status = ValidateBlobWithXdrCertificates (&Dummy, sizeof (Dummy), &FakeCertificate, sizeof (FakeCertificate));
INFO -       |            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Full error output:

INFO - /home/vsts/work/1/s/MfciPkg/MfciDxe/Test/MfciMultipleCertsHostTest.c: In function ‘MfciMultipleCertificatesShouldCheckInputs’:
INFO - /home/vsts/work/1/s/MfciPkg/MfciDxe/Test/MfciMultipleCertsHostTest.c:317:12: error: ‘Dummy’ may be used uninitialized [-Werror=maybe-uninitialized]
INFO -   317 |   Status = ValidateBlobWithXdrCertificates (&Dummy, sizeof (Dummy), NULL, sizeof (mCert_Trusted_CA_Root_xdr));
INFO -       |            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
INFO - /home/vsts/work/1/s/MfciPkg/MfciDxe/Test/MfciMultipleCertsHostTest.c:144:1: note: by argument 1 of type ‘const UINT8 *’ {aka ‘const unsigned char *’} to ‘ValidateBlobWithXdrCertificates’ declared here
INFO -   144 | ValidateBlobWithXdrCertificates (
INFO -       | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
INFO - /home/vsts/work/1/s/MfciPkg/MfciDxe/Test/MfciMultipleCertsHostTest.c:315:15: note: ‘Dummy’ declared here
INFO -   315 |   UINT8       Dummy;
INFO -       |               ^~~~~
INFO - /home/vsts/work/1/s/MfciPkg/MfciDxe/Test/MfciMultipleCertsHostTest.c: In function ‘MfciMultipleCertificatesShouldCheckGeneralCertificates’:
INFO - /home/vsts/work/1/s/MfciPkg/MfciDxe/Test/MfciMultipleCertsHostTest.c:358:12: error: ‘Dummy’ may be used uninitialized [-Werror=maybe-uninitialized]
INFO -   358 |   Status = ValidateBlobWithXdrCertificates (&Dummy, sizeof (Dummy), &FakeCertificate, sizeof (FakeCertificate));
INFO -       |            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
INFO - /home/vsts/work/1/s/MfciPkg/MfciDxe/Test/MfciMultipleCertsHostTest.c:144:1: note: by argument 1 of type ‘const UINT8 *’ {aka ‘const unsigned char *’} to ‘ValidateBlobWithXdrCertificates’ declared here
INFO -   144 | ValidateBlobWithXdrCertificates (
INFO -       | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
INFO - /home/vsts/work/1/s/MfciPkg/MfciDxe/Test/MfciMultipleCertsHostTest.c:355:15: note: ‘Dummy’ declared here
INFO -   355 |   UINT8       Dummy;
INFO -       |               ^~~~~
INFO - /home/vsts/work/1/s/MfciPkg/MfciDxe/Test/MfciMultipleCertsHostTest.c:358:12: error: ‘FakeCertificate’ may be used uninitialized [-Werror=maybe-uninitialized]
INFO -   358 |   Status = ValidateBlobWithXdrCertificates (&Dummy, sizeof (Dummy), &FakeCertificate, sizeof (FakeCertificate));
INFO -       |            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
INFO - /home/vsts/work/1/s/MfciPkg/MfciDxe/Test/MfciMultipleCertsHostTest.c:144:1: note: by argument 3 of type ‘const UINT8 *’ {aka ‘const unsigned char *’} to ‘ValidateBlobWithXdrCertificates’ declared here
INFO -   144 | ValidateBlobWithXdrCertificates (
INFO -       | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
INFO - /home/vsts/work/1/s/MfciPkg/MfciDxe/Test/MfciMultipleCertsHostTest.c:356:15: note: ‘FakeCertificate’ declared here
INFO -   356 |   UINT8       FakeCertificate;
INFO -       |               ^~~~~~~~~~~~~~~
INFO - /home/vsts/work/1/s/MfciPkg/MfciDxe/Test/MfciMultipleCertsHostTest.c: In function ‘MfciMultipleCertificatesShouldCheckIndividualCertificate’:
INFO - /home/vsts/work/1/s/MfciPkg/MfciDxe/Test/MfciMultipleCertsHostTest.c:395:12: error: ‘Dummy’ may be used uninitialized [-Werror=maybe-uninitialized]
INFO -   395 |   Status = ValidateBlobWithXdrCertificates (&Dummy, sizeof (Dummy), FakeCertificate1, sizeof (FakeCertificate1));
INFO -       |            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
INFO - /home/vsts/work/1/s/MfciPkg/MfciDxe/Test/MfciMultipleCertsHostTest.c:144:1: note: by argument 1 of type ‘const UINT8 *’ {aka ‘const unsigned char *’} to ‘ValidateBlobWithXdrCertificates’ declared here
INFO -   144 | ValidateBlobWithXdrCertificates (
INFO -       | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
INFO - /home/vsts/work/1/s/MfciPkg/MfciDxe/Test/MfciMultipleCertsHostTest.c:387:15: note: ‘Dummy’ declared here
INFO -   387 |   UINT8       Dummy;
INFO -       |               ^~~~~
INFO - cc1: all warnings being treated as errors
INFO - make: *** [GNUmakefile:352: /home/vsts/work/1/s/Build/MfciPkg/NOOPT_GCC5/X64/MfciPkg/MfciDxe/Test/MfciMultipleCertsHostTest/OUTPUT/MfciMultipleCertsHostTest.obj] Error 1
INFO - 
INFO - 
INFO - build.py...
INFO -  : error 7000: Failed to execute command
INFO - 	make tbuild [/home/vsts/work/1/s/Build/MfciPkg/NOOPT_GCC5/X64/MfciPkg/MfciDxe/Test/MfciMultipleCertsHostTest]
INFO - 
INFO - 
INFO - build.py...
INFO -  : error F002: Failed to build module
INFO - 	/home/vsts/work/1/s/MfciPkg/MfciDxe/Test/MfciMultipleCertsHostTest.inf [X64, GCC5, NOOPT]

Is there an existing issue for this?

• I have searched existing issues

Current Behavior

Runs of the MemoryProtectionTestApp on GCC5 builds can cause an invalid opcode after returning from a cleared exception.

Expected Behavior

The MemoryProtectionTestApp should be able to clear the faults it intentionally triggers.

Steps To Reproduce

1. Build the test with GCC5 with an X64 target
2. Run the test on Q35

Build Environment

- OS(s): N/A
- Tool Chain(s): GCC5
- Targets Impacted: DEBUG

Version Information

N/A

Urgency

Low

Are you going to fix this?

I will fix it

Do you need maintainer feedback?

No maintainer feedback needed

Anything else?

No response

Request Description

The paging audit test app readme seems way out of date and with the introduction of new tests and "modes" to run the app in it needs docs to clearly explain.

Are you going to make the change?

Someone else needs to make the change

Do you need maintainer feedback?

No maintainer feedback needed

Anything else?

No response

Is there an existing issue for this?

• I have searched existing issues

Current Behavior

BootAuditTestApp attempts to write to various boot variables to check if they are write protected. There exists a sanity check which ensures that the set value makes sense, but BootAuditTestApp passes in garbage data causing the SetVariable() call to return Invalid Parameter.

Expected Behavior

BootAuditTestApp should be able to test all UEFI boot variables.

Steps To Reproduce

Run the test app on a platform with UefiVarCheckLib included.

Build Environment

- OS(s): Any
- Tool Chain(s): Any
- Targets Impacted: DEBUG

Version Information

Top of tree

Urgency

Medium

Are you going to fix this?

I will fix it

Do you need maintainer feedback?

No maintainer feedback needed

Anything else?

No response

Feature Overview

AdvancedLogger allows retrieval of UEFI boot logs on x86 devices in two fashions:

1. UefiLogs directory on EFI system partition or USB storage.
2. In-memory logs.

On ARM devices, only the first method (UefiLogs directory method) is available.

This request is for feature parity between x86 and ARM devices.

Solution Overview

Would like ARM platforms to have the ability to retrieve in-memory UEFI logs, similar to x86 devices.

The varstore methodology of storing logs may need to be revisited.

Alternatives Considered

No response

Urgency

Medium

Are you going to implement the feature request?

Someone else needs to implement the feature

Do you need maintainer feedback?

No maintainer feedback needed

Anything else?

No response

Is there an existing issue for this?

• I have searched existing issues

Current Behavior

Today the Advanced Logger Info structure has pointers to the LogBuffer and LogCurrent. It is inherently safer to use offsets here as these will always be allocated within the same buffer as the info structure.

Expected Behavior

See Current Behavior.

Steps To Reproduce

See code.

Build Environment

- OS(s):
- Tool Chain(s):
- Targets Impacted:
All

Version Information

Top of tree

Urgency

Medium

Are you going to fix this?

I will fix it

Do you need maintainer feedback?

No maintainer feedback needed

Anything else?

No response

Feature Overview

Once the buffer used for the AdvLoggerPkg is filled, any new messages are discarded. This make it impossible to get actionable logs on a long running system.

Solution Overview

The buffer should either be flushed to persistent storage when it is full / periodically or it should at least be circular so that the most recent (& likely most relevant) logs are always available.

Alternatives Considered

No response

Urgency

High

Are you going to implement the feature request?

Someone else needs to implement the feature

Do you need maintainer feedback?

No maintainer feedback needed

Anything else?

No response

Feature Overview

Add a UEFI application to verify that a UEFI variable implementation (i.e. publishes variable services in the Runtime Services table) can properly perform an append operation on the Secure Boot variables such as db, dbx, kek.

Solution Overview

The application should be written to accommodate automated regression testing. For example, being launched through a Startup.nsh file and reporting its results similar to other functional system shell test apps.

Alternatives Considered

No response

Urgency

Medium

Are you going to implement the feature request?

Someone else needs to implement the feature

Do you need maintainer feedback?

No maintainer feedback needed

Anything else?

No response

This issue is tracking numerous minor enhancements that can be made to the Audit tool to help it be more useful.

1. "Special Memory Usage" shows heap guard page guards.
   1. It doesn't show NullPtr (page 0) guard page.
   2. It doesn't show stack guard pages.
   3. Are there others. On QemuQ35 i see 4 guard pages. I expect that the two cases above cover at least 2 or 3 of them.

There are important files that Microsoft projects should all have that are not present in this repository. A pull request has been opened to add the missing file(s). When the pr is merged this issue will be closed automatically.

Microsoft teams can learn more about this effort and share feedback within the open source guidance available internally.

Merge this pull request

Feature Overview

This issue tracks integrating Rust support into the repo and testing the build with a simple library crate. The infrastructure will be reused elsewhere in Project Mu with less effort in the future.

Solution Overview

• Place reusable content in mu_devops
• Update the MuDevOpsWrapper used in most repos to provide a simple rust_build option to opt into Rust builds
• Verify the files that will be copied to Project Mu repos for Rust support build and test in mu_plus

Alternatives Considered

No response

Urgency

Medium

Are you going to implement the feature request?

I will implement the feature

Do you need maintainer feedback?

No maintainer feedback needed

Anything else?

No response

Is there an existing issue for this?

• I have searched existing issues

Current Behavior

Today AdvLogger uses EfiReservedMemoryType as the memory type for the advanced logger buffer. This does not allow the buffer to be marked as runtime for a runtime logger or PRM module to access.

Expected Behavior

This buffer should be marked EfiRuntimeServicesData to be accessible to runtime components.

Steps To Reproduce

Run code as is.

Build Environment

- OS(s):
- Tool Chain(s):
- Targets Impacted:
All

Version Information

HEAD

Urgency

Medium

Are you going to fix this?

I will fix it

Do you need maintainer feedback?

No maintainer feedback needed

Anything else?

No response

Feature Overview

Currently all firmware entities that supports advanced memory logging will dump messages into the memory buffer, without any distinguishable notations. Once the parsed log is retrieved from target, all prints are mushed together, making it hard to read.

The request is to add prefix for different instances of advance logging parties, making it easier to parse and locate logs.

Solution Overview

Adding an API for each instance that produces AdvancedLoggerGetLoggerInfo, call it AdvancedLoggerGetStringPrefix. This function will return a constant string and its size. This function will be invoked from AdvancedLoggerMemoryLoggerWrite, where the return will be copied to the front of each memory log message.

We should make the prefix string minimal, as it will bloat the memoy usage in the memory logging buffer.

Alternatives Considered

1. Create a static PCD for the prefix, so that each component type can use that PCD to prefix the messages.
   • This is a simpler solution by offloading the PCD config to platforms. However, the change will require in-depth analysis of the build configuration and could lead to integration errors.
2. Create a message entry v2. Instead of materializing the prefix into the memory logging buffer, add a field indicating the library instance (i.e. PEI core for 0, PEIM for 1, etc.) so that the parser can handle the prefix.
   • This is a more ideal solution, but the issue is that the parser application will need to be updated accordingly as this is introducing a breaking change, of which the impact is unknown.

Urgency

Medium

Are you going to implement the feature request?

I will implement the feature

Do you need maintainer feedback?

Maintainer feedback requested

Anything else?

No response