What's Changed

Microsoft Open Source Security Bot (@OssSecurityBot)

What's Changed

Pin GitHub Actions to full-length commit SHAs Microsoft Open Source Security Bot (@OssSecurityBot) (#932)
Change Details
## Summary
This PR pins GitHub Actions to full-length commit SHAs for improved security and reproducibility and adds a 7 day cooldown to Dependabot configuration for GitHub Actions.

Why?

Pinning actions to commit SHAs prevents supply-chain attacks where a tag could be moved to point to malicious code. This is a recommended security best practice per the GitHub Actions security hardening guide.

This change mitigates the risk of tag retargeting to malicious code as seen in incidents like the tj-actions/changed-files action compromise or codfish/semantic-release-action compromise and improves the integrity and reproducibility of the CI/CD pipeline.

What changed?

Action pinning: Third-party action references in .github/workflows/ that used mutable tag-based references (e.g., actions/checkout@v4) have been updated to full-length commit SHAs with a version comment (e.g., actions/checkout@<sha> # v4) using the pinact tool. References that were already pinned to a SHA, or that used immutable release tags, were left unchanged.

Dependabot configuration: .github/dependabot.yml has been updated to ensure a github-actions package-ecosystem section is present with a cooldown configuration (default-days: 7). This groups Dependabot PRs for GitHub Actions and enforces a minimum 7-day cooldown between updates. If the file did not exist, it was created. If a github-actions section already existed, only the cooldown block was added or its default-days value was increased to 7 if it was lower. The 7-day cooldown provides a window for the community to detect and report compromised releases before they are automatically proposed as updates, reducing exposure to supply-chain attacks via newly published malicious versions.

Is this safe to merge?

Yes. The pinned SHAs correspond to the same commits that the existing tags pointed to. No behavioral changes are introduced. You can verify the pinned SHA value using the GitHub REST API (e.g., the commit hash for actions/checkout@v7 can be found in the sha property in the JSON response for GET https://api.github.com/repos/actions/checkout/commits/v7).

_{For more information, visit https://aka.ms/action-pinning}
```
  </blockquote>
  <hr>
</details>
```

UefiTestingPkg: SmmuV3 DMA Protection Audit Tests Eeshan Londhe (@eeshanl) (#811)
Change Details
## Description
Add SmmuV3 DMA Protection Audit Tests

Extends the DMA Protection Audit suite (previously VT-d and IVRS only) with an AArch64 DMASmmuProtectionUnitTestApp that plugs SMMUv3-specific implementations into the existing shared test entry point. The app parses the IORT (EFI_ACPI_6_0_IO_REMAPPING_TABLE_SIGNATURE) to enumerate SMMUv3 nodes and their Reserved Memory Range (RMR) associations, then registers three test cases:
1. CheckIOMMUEnabled - IOMMU.StatusRegister
  For each SMMUv3 unit discovered in the IORT, verifies the unit is in a DMA-safe state.
  If translation is on (CR0.SMMUEN == 1), the test additionally confirms:
  CR0.CMDQEN == 1 (command queue enabled)
  CR0.EVTQEN == 1 (event queue enabled)
  STRTAB_BASE != 0 (stream table configured)
  GERROR == 0 (no global errors)
2. CheckExcludedRegions - IOMMU.ExcludedRangeTest
  SMMU equivalent of the VT-d / IVRS "excluded regions" check. Walks every RMR node in the IORT and, for each one, verifies:
  An EFI memory map descriptor fully encompasses the RMR's [BaseAddress, BaseAddress + Length) range, and
  That descriptor's memory type is EfiReservedMemoryType.
  An RMR that is missing from the memory map, or is present but marked with a non-reserved type, fails the test. Platforms with no RMRs in the IORT pass trivially.
3. CheckBMETeardown - IOMMU.BMETeardown (shared)
  Unchanged behavior - the existing "bus mastering disabled at ExitBootServices" test is reused as-is. Test registration order was adjusted so this reboot-triggering test runs last, and a PASSED log line was added on the success path.
For details on how to complete these options and their meaning refer to CONTRIBUTING.md.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested

Tested on physical ARM device

Integration Instructions

N/A

Full Changelog: v2025110003.0.2...v2025110003.0.3

Michael Kubacki (@makubacki)

What's Changed

🐛 Bug Fixes

UefiTestingPkg: Allow DxePagingAuditTestApp to be renamed Michael Kubacki (@makubacki) (#927)
Change Details
## Description
Fixes: #926

Currently, if the application file name is changed or it is placed in a non-root directory, an assert occurs with no console-visible output.

This change locates the SFS protocol on the device handle instead of iterating across all SFS protocols to locate an instance with a file present that matches the hardcoded application file name.

It also closes the SFS handle after dumping the paging info, which was previously left open.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested
- Run DxePagingAuditTestApp.efi -r
- Run DxePagingAuditTestApp.efi -d from the volume root (FS0:)
- Run DxePagingAuditTestApp.efi -d from a subdirecotry (e.g. /somedir)
- Verify files are written in the same directory as the application and it does not assert.
Integration Instructions
- N/A
There are some style and miscellaneous changes unrelated to this functional change I might make in a future PR, but I didn't do so here to avoid scope creep.
- Note: DxePagingAuditDriver still uses OpenVolumeSFS() which does a more generic search.

UefiTestingPkg: Fix memory info database dump Michael Kubacki (@makubacki) (#925)
Change Details
## Description
Fixes: #924

Memory info is stored in mMemoryInfoDatabaseBuffer. The code first calculates how large of a buffer is needed. A "dry run" is performed to compute that. It calls each dump handler with AllowAllocation=FALSE, to get the size of the data that would be written.

However, the call to LoadedImageTableDump() during this phase, sets AllowAllocation=TRUE. mMemoryInfoDatabaseOffset is still NULL, then AppendMemoryInfoDatabase() sees that and allocates a buffer.

Now, mMemoryInfoDatabaseSize is advanced. Other dump handlers after write to the buffer now that it exists.

Eventually, DumpPagingInfo() allocates the real (intended) buffer. Because of what happened earlier, the "accidental" buffer is leaked and mMemoryInfoDatabaseSize is non-zero which causes mMemoryInfoDatabaseBuffer[mMemoryInfoDatabaseSize] to write past the beginning of the buffer:
```
  // Copy the new string to the end of the buffer and update the size.
  if (!EFI_ERROR (Status)) {
    CopyMem (&mMemoryInfoDatabaseBuffer[mMemoryInfoDatabaseSize], DatabaseString, NewStringSize);
    mMemoryInfoDatabaseSize = NewDatabaseSize;
  }
```
This change sets AllowAllocation=FALSE in that call and resets mMemoryInfoDatabaseSize to zero before the real allocation as a precaution.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested
1. Before - Reproduce the problem:
  (venv) paging>python PagingReportGenerator.py -i ..\collection_data -o report1.html Traceback (most recent call last): File "paging\PagingReportGenerator.py", line 312, in <module> retcode = main() File "paging\PagingReportGenerator.py", line 294, in main spt.Parse() ~~~~~~~~~^^ File "paging\PagingReportGenerator.py", line 79, in Parse self.MemoryRangeInfo.extend(ParseInfoFile(info)) ~~~~~~~~~~~~~^^^^^^ File "paging\BinaryParsing.py", line 38, in ParseInfoFile MemoryRanges.append(MemoryRange(row[0], *row[1:])) ~~~~~~~~~~~^^^^^^^^^^^^^^^^^^ File "paging\MemoryRangeObjects.py", line 126, in __init__ raise RuntimeError("Unknown type '%s' found!" % self.RecordType) RuntimeError: Unknown type 'MemoryMap' found!
2. After - Verify the problem no longer exists:
  python Windows\PagingReportGenerator.py -i ../collection_data -o report1.html
Integration Instructions
- N/A

Full Changelog: v2025110003.0.1...v2025110003.0.2

Oliver Smith-Denny (@os-d)

What's Changed

🐛 Bug Fixes

AdvLoggerPkg: Default PcdAdvancedLoggerHdwPortOsRuntimeDisable to TRUE Oliver Smith-Denny (@os-d) (#918)
Change Details
## Description
1d1b4db changed the behavior of runtime AdvLogger prints to always print to the serial port. This breaks platforms who give up control of the serial port to an OS after ExitBootServices.

cea5d2a followed on to fix this behavior by introducing
PcdAdvancedLoggerHdwPortOsRuntimeDisable to allow returning to the original behavior and disabling the hardware port logging during runtime.

However, this commit set the PCD default to FALSE, which left the breaking change behavior in place, which quietly gets picked up by platforms.

This commit flips the PCD default to return to the original behavior and not log to the hardware port at runtime by default. Platforms may set this PCD to FALSE if it is safe to do so on their implementation.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested

Tested on a platform where it is not safe to write to the serial port at runtime. It crashed before this change and boots after it.

Integration Instructions

Platforms will continue to work as they did before 1d1b4db. Platforms who wish to have serial logging at runtime can set PcdAdvancedLoggerHdwPortOsRuntimeDisable|TRUE in their DSC.

Full Changelog: v2025110003.0.0...v2025110003.0.1

Oliver Smith-Denny (@os-d)

What's Changed

[REBASE \& FF] AdvLoggerPkg: PeiCore Instance: Use Local PeiMain.h Oliver Smith-Denny (@os-d) (#909)
Change Details
## Description
The PEI Core AdvLoggerLib instance relies on PeiMain.h which defines the PEI_CORE_INSTANCE structure. A special PlatformBlob is added there to use stack space for the adv logger info pointer. This avoids a HOB lookup for every log.

However, edk2's PeiMain.h has been updated to use a private header in PeiMain.h. This is pulled into mu_basecore, which then breaks building this library because it doesn't have access to the private header.

Using PEI_CORE_INSTANCE to host the advanced logger pointer has always been a hack; it will be separately addressed and removed, but in the meantime, this library needs to continue to work.

This copies PeiMain.h, removes the use of the private header, and consumes it in the PeiCore instance of AdvLoggerLib.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested

Booting patina-qemu to shell with the PEI memory bin changes cherry-picked.

Integration Instructions

N/A.
```
  </blockquote>
  <hr>
</details>
```

Full Changelog: v2025110002.0.0...v2025110002.0.1

Oliver Smith-Denny (@os-d)

What's Changed

AdvLoggerPkg: PeilessArm: Check if Buffer Is Already Valid Oliver Smith-Denny (@os-d) (#911)
Change Details
## Description
PeilessArm currently assumes it is setting up the adv logger buffer. However, an earlier phase may have initialized the buffer, such as StMM running before SEC is started.

This adds a check to see if the buffer is already valid and just inherits it if so.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested

Tested on a platform where StMM initializes the log buffer and runs before SEC.

Integration Instructions

N/A.
```
  </blockquote>
  <hr>
</details>
```

⚠️ Breaking Changes

[REBASE \& FF] AdvLoggerPkg: PeiCore Instance: Update Override Tag And Apply SecDebugAgent Fix Oliver Smith-Denny (@os-d) (#912)
Change Details
## Description
Update the override tag in PeiMain.h as it has been updated in basecore v2025110002.0.8.

Also, SecDebugAgent was missed when using the local header, update it.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested

N/A.

Integration Instructions

This is marked as a breaking change because the build will break if mu_basecore v2025110002.0.8 is not updated to (or later) at the same time by consumers.
```
  </blockquote>
  <hr>
</details>
```

Full Changelog: v2025110002.0.1...v2025110003.0.0

Michael Kubacki (@makubacki)

What's Changed

Drop mu\_pi and mu\_rust\_helpers crate dependencies (and fix build due to incoming r-efi v7) [Rebase \& FF] Michael Kubacki (@makubacki) (#907)
Change Details
## Description
A series of commits with two goals:
1. mu_rust_helpers moved to r-efi v7 in eefef09. The minor version was updated which caused many crates depending on mu_rust_helpers to pick up the change automatically per semantic versioning while there other dependencies stayed on r-efi v6. This could lead to type mismatches (and did in this repo). So, this prevents that.
2. Support the longer-term goal of deprecating mu_rust_helpers and mu_pi (as described in #906) by removing their usage in this repo.
MuTelemetryHelperLib: Fix r-efi v7 GUID constant conflict

mu_rust_helpers re-exports mu_uefi_guid, which updated to r-efi v7.

Its guid::ZERO and guid::CALLER_ID constants are compiled against
r-efi v7, while patina (and the rest of the tree) remain on r-efi v6,
producing mismatched-type errors when those constants are used in v6
contexts.

This makes the move to the patina crate's GUID constants. The patina
version used here is still on r-efi v6, so its patina::guids::ZERO
and patina::guids::CALLER_ID constants are compiled against r-efi
v6.

This is also a step toward removing the mu_rust_helpers dependency
from this crate.

MuTelemetryHelperLib: Use patina instead of mu_pi

Replaces the mu_pi status code types and error-code constants with the
equivalent definitions from the patina crate (patina::pi::status_code
and patina::pi::protocols::status_code).

This removes the mu_pi dependency from the crate and the workspace.

MsWheaPkg: Remove mu_rust_helpers dependency

Makes the remaining changes needed to replace mu_rust_helpers with
the patina crate. This is part of the effort to remove mu_rust_helpers
as it is being deprecated.

Remove mu_rust_helpers as a workspace dependency

Makes the remaining changes needed in UefiHidDxeV2 to use
patina::function instead of mu_rust_helpers::function so the
crate dependency can be removed from the workspace.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested
- Run cargo make tasks
- CI
Integration Instructions
- N/A - Replace mu_rust_helpers and mu_pi functionality with equivalent functionality from the patina crate. The patina crate was already a dependency.

AdvLoggerPkg: Gate hardware port writes at OS runtime KaiJI (@chaokai-ching) (#902)
Change Details
## Description
AdvancedLoggerWrite unconditionally wrote debug output to the hardware serial
port at both boot time and OS runtime (after ExitBootServices). Some platforms'
serial implementations cannot be safely called at OS runtime.

This change adds an opt-in FeatureFlag PCD
PcdAdvancedLoggerHdwPortRuntimeDisable (default FALSE):
- Default (FALSE): behavior is unchanged — hardware port writes remain
  enabled at runtime, so existing platforms are unaffected.
- TRUE: a platform whose serial cannot be safely called after
  ExitBootServices restricts hardware port writes to boot time only, while
  early-boot and boot-time serial output is preserved.
Runtime is detected via the logger info block's AtRuntime field when
available. The DXE runtime AdvancedLoggerLib instance clears its logger info
pointer at ExitBootServices, so it consults a module-scoped
ADVANCED_LOGGER_RUNTIME build flag plus a gAdvancedLoggerAtRuntime flag to
distinguish post-EBS runtime from early boot when the logger info block is NULL.
- Impacts functionality? Only when the new PCD is set TRUE (default FALSE = no change)
- Impacts security?
- Breaking change? No — default preserves existing behavior
- Includes tests? Not included; hardware-port gating path has no existing host-test coverage. Can add a GoogleTest if desired.
- Includes documentation? PCD documented in AdvLoggerPkg.dec
How This Was Tested

Built an ARM AARCH64 platform (DEBUG); all AdvancedLoggerLib instances
compile. Verified on ARM AARCH64 hardware with a temporary driver that forces a
serial write on the first post-SetVirtualAddressMap runtime call:
- PCD default (FALSE): the firmware faults on the runtime serial write
  (reproduces the unsafe-at-runtime behavior).
- PCD TRUE: the runtime write is suppressed and the system boots cleanly,
  while boot-time serial output is unaffected.
Integration Instructions

None required by default. Platforms whose serial implementation cannot be
called safely at OS runtime should set
gAdvLoggerPkgTokenSpaceGuid.PcdAdvancedLoggerHdwPortRuntimeDisable to TRUE.

[REBASE\&FF] .azurepipelines: Add CLANGPDB CI Joey Vagedes (@Javagedes) (#896)
Change Details
## Description
Add CI that specifically builds each package in DEBUG and RELEASE with CLANGPDB on both Windows and Linux. Applies necessary changes to compile all packages with CLANGPDB.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested

Windows: https://dev.azure.com/projectmu/mu/_build/results?buildId=111589&view=results
Linux: https://dev.azure.com/projectmu/mu/_build/results?buildId=111590&view=results

Integration Instructions

N/A

.github: Switch Mu PR Validation workflow to main branch Michael Kubacki (@makubacki) (#897)
Change Details
## Description
These workflow files were previously using a dedicated branch for development of the Mu PR Validation workflow. It has been stable for a couple of months now, so we can switch back to using the main branch which has the latest changes.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested
- Compare branch content (main <-> add_mu_pr_val_workflow_e2e_val)
Integration Instructions
- N/A. Only affects GitHub repo workflow.

⚠️ Breaking Changes

Patina 22.1.0 integration (r-efi 7) [Rebase \& FF] Michael Kubacki (@makubacki) (#908)
Change Details
## Description
Two commits to integrate the latest patina v22.1.0 (and fix the build).

Cargo.toml: Add AdvLoggerPkg/Crates/RustAdvancedLoggerDxe as a member

Library crates are currently being listed in the members section, so
the line about binary crates is removed.

RustAdvancedLoggerDxe is currently being built as a dependency, but
this commit adds it as a member for consistency with other crates.

Bump r-efi to 7 to match patina's update

patina 22.1.0 moved its r-efi dependency up to version 7, but the
workspace was still pinned to ^6.

Cargo then pulled in both r-efi 6 and 7 at the same time, and since
types from different major versions don't unify, that broke
cargo make check and cargo make test.

This moves the workspace to r-efi 7.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested
- cargo make tasks
- Repo CI
Integration Instructions
- If library crates are used from this repo, it is recommended to move to r-efi 7.

🐛 Bug Fixes

MsCorePkg: Fix double components specifier for AARCH64 Michael Kubacki (@makubacki) (#901)
Change Details
## Description
[Components.AARCH64, Components.AARCH64] should just be [Components.AARCH64] in MsCorePkg.dsc.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested
- Local MsCorePkg CI build
Integration Instructions
- N/A

MsCorePkg: Remove the non-existent header files in aarch64 XiaoYeZi (@qaz6750) (#899)
Change Details
## Description
As stated in #895, this header file no longer exists, and the issue has been fixed in X64. However, Aarch64 was overlooked, so it should be applied to AArch64 as well.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested

N/A

Integration Instructions

...

Vineel Kovvuri[MSFT] (@vineelko)

What's Changed

Migrate to R-EFI 6.0 Vineel Kovvuri[MSFT] (@vineelko) (#892)
Change Details
## Description
This PR consumed the major branch changes done in Patina as part of R-EFI 6.0 migration(release as version 22).
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested

cargo make all

Integration Instructions

Will merge this once OpenDevicePartnership/patina#1548 is merged and patina release 22 is made.

UefiHidDxeV2: Add keystroke repeat functionality John Schock (@joschock) (#883)
Change Details
## Description
Implement keyboard repeat for held keys, matching the behavior of the
legacy C HidKeyboardDxe driver:
- 500ms initial delay before repeat begins
- 20ms repeat rate (~50 keys/sec) while key is held
- Modifier keys, toggle keys, and non-spacing (dead) keys are excluded
- Last newly pressed repeatable key wins in multi-key reports
- Timer cancelled on key release or keyboard reset
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested

Included unit tests, tested on hardware at UEFI shell and confirmed expected repeat behavior.

Integration Instructions

None.

Fix missing UefiLib dependency in MfciPolicyParsingUnitTestApp GiriMohanNaidu (#887)
Change Details
## Description
Added the missing UefiLib library class dependency to MfciPolicyParsingUnitTestApp.inf. The module uses UefiLib APIs but did not declare the dependency in its [LibraryClasses] section, causing build failures when the library was not implicitly pulled in by the platform DSC.
The module uses AsciiPrint() from UefiLib but did not declare the dependency in its LibraryClasses section.
- Impacts functionality? No — build fix only; no logic changes.
- Impacts security?
- Breaking change?
- Includes tests? N/A — fixes the test app itself so it builds correctly.
- Includes documentation?
How This Was Tested

Built MfciPkg/UnitTests/MfciPolicyParsingUnitTest/MfciPolicyParsingUnitTestApp.inf and confirmed the build completes without missing library errors.

Integration Instructions

N/A — consumers of MfciPkg do not need any changes; this only affects the unit test app build.
```
  </blockquote>
  <hr>
</details>
```

Migrate mu\_plus from mu\_uefi\_boot\_services crate to patina crate Vineel Kovvuri[MSFT] (@vineelko) (#881)
Change Details
## Description
- mu_uefi_boot_services is not maintained and its functionality is moved into patina.
- The mu_uefi_boot_services's crates.io point to non-existent repo.
- This cleanup is needed to move mu_plus's r-efi dependency to 6.0
Next, Once Patina is updated to r-efi 6.0 we can migrate mu_plus to patina vnext and r-efi to 6.0
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested

cargo make all worked. Will be tested in internal repos once r-efi 6.0 migration is done.

Integration Instructions

NA

AdvLoggerPkg/AdvancedLoggerLib: Print to HW if logger info is not available Michael Kubacki (@makubacki) (#876)

Change Details

## Description
In the course of testing advanced logger changes with edk2 Standalone MM on OVMF, there was a change needed in MmPlatformHobProducerLibOvmf in OvmfPkg to account for gAdvancedLoggerHobGuid in the HOBs that are passed to the MM environment.

Prior to this change, the system appeared to hang entering that environment:
INFO - Loading PEIM at 0x00005B95000 EntryPoint=0x00005B95340 StandaloneMmIplPei.efi
INFO - StandaloneMM IPL loading MM Core at MMRAM address 7FF0000
INFO - MmCoreImageBase  - 0x0000000007FF0000
INFO - MmCoreImageSize  - 0x0000000000010000
INFO - StandaloneMM IPL calling Standalone MM Core at MMRAM address - 0x0000000007FF1000
After the change, the issue is clearly printed to serial output: ("MmCore AdvancedLoggerGetLoggerInfo: Advanced Logger Hob not found")
INFO - Loading PEIM at 0x00005B94000 EntryPoint=0x00005B94340 StandaloneMmIplPei.efi
INFO - StandaloneMM IPL loading MM Core at MMRAM address 7FF0000
INFO - MmCoreImageBase  - 0x0000000007FF0000
INFO - MmCoreImageSize  - 0x0000000000010000
INFO - StandaloneMM IPL calling Standalone MM Core at MMRAM address - 0x0000000007FF1000
INFO - MmCore AdvancedLoggerGetLoggerInfo: Advanced Logger Hob not found
INFO - MmMain - 0x5B11000
INFO - MmramRangeCount - 0x4
INFO - MmramRanges[0]: 0x0000000006000000 - 0x1000
INFO - MmramRanges[1]: 0x0000000006001000 - 0xE000
INFO - MmramRanges[2]: 0x000000000600F000 - 0x1FE1000
INFO - MmramRanges[3]: 0x0000000007FF0000 - 0x10000
INFO - MmInitializeMemoryServices
INFO - MmAddMemoryRegion 2 : 0x000000000600F000 - 0x0000000001FE1000
INFO - HobSize - 0x538
INFO - MmHobStart - 0x7FEE810
INFO - MmInstallConfigurationTable For HobList
INFO - ASSERT [StandaloneMmCore] AdvancedLoggerLib.c(164): mLoggerInfo != ((void *) 0)
This change allows writes to proceed to hardware output if enabled even if the logger info is not available, to make information such as this available for debugging purposes.

Impacts functionality?

Impacts security?

Breaking change?

Includes tests?

Includes documentation?

How This Was Tested

Test MM entry with and without gAdvancedLoggerHobGuid in the HOB list.

Integration Instructions

N/A

⚠️ Breaking Changes

Delete HelloWorldRustDxe Component Vineel Kovvuri[MSFT] (@vineelko) (#882)
Change Details
## Description
HelloWorldRustDxe Component is currently being compiled for 32 bit causing PR gates to fail when dependent Rust packages do not compile(by design) for 32 bit. This PR deletes it completely.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested

cargo make all

Integration Instructions

NA

🚀 Features & ✨ Enhancements

AdvancedLoggerPkg/MmCoreArm: Initialize LoggerInfo if not already set by earlier firmware phase Sureshkumar Ponnusamy (@sureshkumarpMSFT) (#886)
Change Details
## Description
In the MmCoreArm instance of AdvancedLoggerLib, AdvancedLoggerGetLoggerInfo() previously assumed that an earlier firmware phase (e.g. BL31 prior to StandaloneMM) had already initialized the ADVANCED_LOGGER_INFO header at PcdAdvancedLoggerBase. On ARM boot flows where StandaloneMM is the first phase to touch this buffer, the signature check in subsequent logger calls fails and no log records are written.

This change adds a one-time, in-place initialization of the ADVANCED_LOGGER_INFO header inside AdvancedLoggerGetLoggerInfo() when the signature is not already valid:
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested

Verified on an ARM platform where no pre-StandaloneMM entity initializes the AdvancedLogger buffer

Integration Instructions

N/A

🐛 Bug Fixes

Fix SWM init retry when SRE is not ready Armando Ferreira (@mikitl) (#888)
Change Details
## Description
GopRegisteredCallback sets mGop when it finds GOP but exits early if SRE is not available yet. Because mGop remains set, the callback never retries on subsequent GOP notifications, so SWM never initializes.

Reset mGop to NULL when SRE is not found so the callback can retry.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested

Tested on:
- ARM64 platform with GPU driver that installs GOP during early display enumeration, before GopOverrideDxe and SRE have processed it
- Verified SWM callback retries and completes Stage2 initialization after SRE becomes available
- Confirmed Front Page and on-screen keyboard render correctly
- Verified no regression when GOP and SRE appear simultaneously (standard boot path)
Integration Instructions

N...

Michael Kubacki (@makubacki)

What's Changed

Skip Mu PR validation for PRs targeting non-default branches Michael Kubacki (@makubacki) (#872)
Change Details
## Description
Because mu-pr-validation.yml is in the default branch (release/202511) and runs on a workflow_run trigger for the CodeQL workflow where the CodeQL workflow runs for all release branches, the Mu PR Validation workflow will run for all PRs targeting any release branch.

Because mu_tiano_platforms is only compatible with default branches, we want to skip Mu PR Validation targeting those non-default branches.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested

Verified for PRs against the default on non-default branch on my fork.

Non-Default Case (Skip)

Default Case (Run)

Integration Instructions
- N/A

MsGraphicsPkg/SwmDialogsLib: Show OSK after dialog rendering completes Michael Kubacki (@makubacki) (#866)
Change Details
## Description
Moves the ShowKeyboard() call after the canvas Draw() call in the KEYFOCUS handling block of PasswordDialog and SemmUserAuthDialog.

Previously, the on-screen keyboard was displayed before the dialog finished rendering at its shifted position.

By deferring ShowKeyboard() until after Draw() completes, the dialog is fully painted in its final position before the keyboard appears.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested
1. Go to the "Security -> UEFI password" page
2. In the "Enter password" screen, touch the blank area on the screen
3. Watch the on-screen keyboard load
Integration Instructions
- N/A

mu-pr-validation-pending.yml: Temporarily disable commit status updates Michael Kubacki (@makubacki) (#870)
Change Details
## Description
The Mu Automation GitHub app requires a permission update to be accepted by a microsoft org admin. Until that happens, disable the calling the GitHub API to update the commit status.

This will still run validation and post PR comments. The pass/fail result just won't be reported in the status check area of the PR until the permission is allowed.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested
- N/A
Integration Instructions
- N/A

.github: Add Mu PR Validation workflow Michael Kubacki (@makubacki) (#865)
Change Details
## Description
Adds workflows to run QEMU-based platform validation on pull requests to mu_plus. This includes:
- mu-pr-validation.yml: The main workflow that performs the actual QEMU validation, including building and booting.
- mu-pr-validation-pending.yml: A workflow that posts an immediate "pending" notification on a pull request when it's pushed, indicating that QEMU validation is waiting for CI to complete. This is broken out to its own workflow to use the pull_request_target trigger (access to secrets on PRs from public forks) while minimizing the amount of code that runs with those elevated permissions.
- mu-pr-validation-post.yml: A workflow that posts the results of the QEMU validation run to the pull request once the validation is complete.
Notes

This workflow differs slightly from the Mu Basecore equivalent file in that it is triggered by the CodeQL workflow instead of the CLANGPDB Package CI workflow used there. The reason is that the CLANGPDB Package CI workflow was not added to mu_plus since mu_plus requires Rust code to be built and that workflow doesn't include Rust build support. The CodeQL workflow in mu_plus serves a similar purpose by verifying local package compilation prior to attempting a mu_tiano_platforms build with the changes.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested

Ran the workflow under various conditions on my mu_plus fork.

Note that the "boot times" are not precise. They are the total time for the --flashonly step to run including stuart overhead. However, they are not too far off from the boot time and provide the ability to get a relative sense of perf impact.

PENDING STATE (when the workflow is waiting for CI to finish)

IN PROGRESS (building / booting QEMU FW with the change)

Granular status updates (see ending text):

SUCCESS

Integration Instructions
- N/A - Only impacts PR validation in this repo

Full Changelog: v2025110000.0.3...v2025110000.0.4

Michael Kubacki (@makubacki)

What's Changed

[2502] MsGraphicsPkg/SwmDialogsLib: Show OSK after dialog rendering completes Michael Kubacki (@makubacki) (#871)
Change Details
## Description
Moves the ShowKeyboard() call after the canvas Draw() call in the KEYFOCUS handling block of PasswordDialog and SemmUserAuthDialog.

Previously, the on-screen keyboard was displayed before the dialog finished rendering at its shifted position.

By deferring ShowKeyboard() until after Draw() completes, the dialog is fully painted in its final position before the keyboard appears.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested
1. Go to the "Security -> UEFI password" page
2. In the "Enter password" screen, touch the blank area on the screen
3. Watch the on-screen keyboard load
Integration Instructions
- N/A

[2502] MsGraphicsPkg: Prevent TPL inversion in SRESetMode() Michael Kubacki (@makubacki) (#847)
Change Details
## Description
It has been observed on some platforms that SRESetMode() is invoked at a TPL greater than TPL_CALLBACK, which leads to TPL inversion when SRESetMode() unconditionally raises the TPL to TPL_CALLBACK.

The platform behavior seems reasonable given there are no apparent caller restrictions on GOP so it would default to <= TPL_NOTIFY.

I believe that the better solution is to change this code to raise to TPL_NOTIFY instead of TPL_CALLBACK.

That is not done for a couple of reasons:
1. SRESetMode() is the RenderingEngineDxe wrapper around the real GOP SetMode(). Because many GOP implementations are closed source, it is difficult to determine what the impact would be to raise to TPL_NOTIFY. For example, they could similarly raise to TPL_CALLBACK (though unlikely), and this would move the TPL inversion to the GOP driver.
2. Every other SRE function raises to TPL_NOTIFY. Doing so here would provide consistent TPL expectations in the implementation. However, this leads me to believe this specific call was raised to TPL_CALLBACK intentionally, so I am hesitant to change it without more background on why it was done.
In the end, this change balances the risk of not breaking existing implementations while addressing the TPL inversion issue by simply maintaining the same behavior as before conditionally to avoid TPL inversion.

Note: GOP SetMode() implementations can raise to TPL >TPL_CALLBACK to actually protect its critical section before and after this change.

This is not a recent regression, SRESetMode() has always been implemented this way.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested
- Qemu Q35 and SBSA boot to shell
- Boot Intel physical platform that encountered TPL inversion with the change
Integration Instructions
- N/A

Remove crate versioning from local cargo.toml srilatha sridharan (@srilathasridharan) (#834)
Change Details
## Description
Remove crate versioning for mockall from module level cargo.toml
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested

Moved the versioning to root level cargo.toml and cargo tests run fine.

Integration Instructions

N/A

Full Changelog: v2025020003.0.3...v2025020003.0.4

Oliver Smith-Denny (@os-d)

What's Changed

[REBASE \& FF] Copy FltUsedLib to MsCorePkg Oliver Smith-Denny (@os-d) (#864)
Change Details
## Description
FltUsedLib is a library that has a single line, adding a reference to _fltused, which is needed by MSVC and clang when building floating point code.

FltUsedLib is only used in mu_plus, so in order to reduce deltas from edk2, it is moved to mu_plus. This commit then updates references in mu_plus to this new library.

A PR will be put up to mu_basecore to drop the library after this merges.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested

Build testing.

Integration Instructions

Platforms should update to FltUsedLib|MsCorePkg/Library/FltUsedLib/FltUsedLib.inf in their DSCs. This change is not a breaking change, but the removal in mu_basecore will be.
```
  </blockquote>
  <hr>
</details>
```

Global: Remove backport workflow. Aaron (@apop5) (#859)
Change Details
Description

The switch from dev/release to just relase left the backport workflow in the repo. Though it will
not be triggered, dependabot will continue
to attempt to update the github actions used.

Remove the workflow to reduce unused workflows and to prevent dependabot from attempting to update.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested

N/A

Integration Instructions

N/A

Full Changelog: v2025110000.0.2...v2025110000.0.3

Uh oh!

Releases: microsoft/mu_plus

Release list

v2025110003.0.3

What's Changed

Why?

What changed?

Is this safe to merge?

How This Was Tested

Integration Instructions

Contributors

Uh oh!

v2025110003.0.2

What's Changed

🐛 Bug Fixes

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

Contributors

Uh oh!

v2025110003.0.1

What's Changed

🐛 Bug Fixes

How This Was Tested

Integration Instructions

Contributors

Uh oh!

v2025110002.0.1

What's Changed

How This Was Tested

Integration Instructions

Contributors

Uh oh!

v2025110003.0.0

What's Changed

How This Was Tested

Integration Instructions

⚠️ Breaking Changes

How This Was Tested

Integration Instructions

Contributors

Uh oh!

v2025110002.0.0

What's Changed

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

⚠️ Breaking Changes

How This Was Tested

Integration Instructions

🐛 Bug Fixes

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

Contributors

Uh oh!

v2025110001.0.0

What's Changed

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

⚠️ Breaking Changes

How This Was Tested

Integration Instructions

🚀 Features & ✨ Enhancements

How This Was Tested