microsoft/mu_basecore v2025020003.0.5

v2025020003.0.5

Repository: microsoft/mu_basecore

Tag: v2025020003.0.5

Published: 2026-03-04T17:35:58Z

Prerelease: no

Release notes:

What's Changed

[FF-A] Remove ArmFfaLibBase @Raymond-MS (#1670)

Change Details

Description

Remove ArmFfaLibBase, it will no longer be used as the C partition is being removed and replaced with a RUST implementation. Plans to go back and revisit this library in the future to have a true base instance.

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

How This Was Tested

Built and ran QEMU SBSA with TPM Enabled and the RUST partition updated to include the new RUST TPM service with the C partition removed from Features/FFA.

Integration Instructions

N/A

[2502][REBASE \& FF] Port CLANGPDB AARCH64 Support to 2502 @os-d (#1669)

Change Details

Description

In order to facilitate platforms moving from MSVC AARCH64 to CLANGPDB AARCH64, port CLANGPDB AARCH64 support to 2502.

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

How This Was Tested

N/A.

Integration Instructions

N/A.

MdeModulePkg/VariableSmmRuntimeDxe: Fix EFI\_UNSUPPORTED leak from InitVariableCache @garybeihl (#1667)

Change Details

Description

When PcdMigrateVariableRuntimeCacheBufferAllocation is TRUE (or before the PCD was added, unconditionally), InitVariableCache() calls MmUnblockMemoryRequest() for each relocated runtime cache buffer. On platforms using MmUnblockMemoryLibNull, these calls return EFI_UNSUPPORTED.

The code correctly tolerates EFI_UNSUPPORTED for the AllRtBufferAllocationsSucceeded flag (lines 1638-1648, 1660-1670, etc.), but fails to reset the Status variable before returning. This causes the caller (SmmVariableReady) to see EFI_UNSUPPORTED as the return value from InitVariableCache(), which: 1. Skips the call to SendRuntimeVariableCacheContextToSmm() 2. Triggers ASSERT_EFI_ERROR(Status) at line ~1912

This affects all platforms that link MmUnblockMemoryLibNull (the majority of platforms, including all that don't use Standalone MM memory unblocking).

The fix resets Status = EFI_SUCCESS at the beginning of the AllRtBufferAllocationsSucceeded success path, since at that point all allocations and unblock requests have been processed successfully (with EFI_UNSUPPORTED from MmUnblockMemoryRequest being an expected/tolerated return value).

Introduced by: #1519 (eee3687b62) Not fixed by: #1588 (c7ea0e10af) — the PCD workaround avoids the code path but doesn't fix the Status leak when the feature is enabled.

• [x] Impacts functionality?
• [ ] Impacts security?
• [ ] Breaking change?
• [ ] Includes tests?
• [ ] Includes documentation?

How This Was Tested

Tested on Intel Birch Stream (Granite Rapids) platform under Simics simulation:

• Before fix: ASSERT_EFI_ERROR (Status = Unsupported) at VariableSmmRuntimeDxe.c:1912

immediately after "Runtime variable cache buffers successfully relocated"

• After fix: Boot proceeds normally through DXE/BDS to OS

Platform uses MmUnblockMemoryLibNull (confirmed via DSC library class resolution).

Integration Instructions

N/A — drop-in bug fix, no integration changes needed.

🐛 Bug Fixes

[2502] NetworkPkg: Ip4Dxe/Ip6Dxe: Set SB notify to NULL after event close @makubacki (#1661)

Change Details

Description

Ip4StartAutoConfig() and Ip6ConfigStartStatefulAutoConfig() close the DHCP service binding notify event when the service child is successfully created, but do not NULL the instance field afterward.

On re-entry, the stale handle passes the non-NULL condition and is closed a second time, which results in a page fault with memory protections enabled.

This change sets the event field to NULL immediately after CloseEvent() so that subsequent calls skip attempting to close the event again.

Code design issue in original implementation. Not a regression.

• [x] Impacts functionality?
• [ ] Impacts security?
• [ ] Breaking change?
• [ ] Includes tests?
• [ ] Includes documentation?

How This Was Tested

PXE boot with a specific Kensington USB HUB and memory protections enabled.

Repro snippets from debug log:

[CoreCreateEventInternal]: EVENT CREATED. D6A2CB7F-6A18-4E2F-B43B-9920A733700A
...
[Ip4StartAutoConfig]: EVENT CLOSED. 9FB1A1F3-3B71-4324-B39A-745CBB015FFF
[CoreCloseEvent]: EVENT CLOSED. D6A2CB7F-6A18-4E2F-B43B-9920A733700A
...
[Ip4StartAutoConfig]: EVENT CLOSED. 9FB1A1F3-3B71-4324-B39A-745CBB015FFF
[CoreCloseEvent]: EVENT CLOSED. D6A2CB7F-6A18-4E2F-B43B-9920A733700A

Integration Instructions

N/A

[2502] NetworkPkg/UefiPxeBcDxe: Add missing Token.Context initialization @makubacki (#1656)

Change Details

Description

Adds missing Token.Context = Private initialization in two MTFTP write-file functions. Without this, the Context field passed to the MTFTP WriteFile callback was uninitialized, which could lead to a page fault when the callback attempted to access the Private driver context. The corresponding read-file functions already set this field correctly.

This has been an issue since the initial implementation of NetworkPkg (2010).

• [x] Impacts functionality?
• [ ] Impacts security?
• [ ] Breaking change?
• [ ] Includes tests?
• [ ] Includes documentation?

How This Was Tested

Test file write to TFTP server with memory protections enabled.

Integration Instructions

• N/A

Full Changelog: https://github.com/microsoft/mu_basecore/compare/v2025020003.0.4...v2025020003.0.5