microsoft/mu_basecore v2025020002.1.0

v2025020002.1.0

Repository: microsoft/mu_basecore

Tag: v2025020002.1.0

Published: 2025-10-31T18:39:16Z

Prerelease: no

Release notes:

What's Changed

[CHERRY-PICK] NetworkPkg/SnpDxe: Update SnpDxe SNP\_DRIVER struct out of DMA-able memory @eeshanl (#1548)

Change Details

Description

CPB, DB, and CDB structs to use DMA-able memory.

Updates the overall SNP_DRIVER allocation to use AllocatePool() instead of PciIo->AllocateBuffer(). This moves this struct out of DMA-able memory. Allocates the PXE_CDB struct as a pointer instead, using PciIo->AllocateBuffer() for DMA-able memory.

End result: CPB, DB, and CDB are allocated with individual PciIo->AllocateBuffer() calls with a size of 4096 for CPB and DB. and sizeof(PXE_CDB) for CDB. Each of these members point to locations within the Allocated Buffer, and all of these pointers are at-least 8-Byte aligned. SNP_DRIVER is allocated with AllocatePool() In the SNP_DRIVER structure, the PXE_CDB member is changed to a pointer so we can allocate it with PciIo->AllocateBuffer()

This PR is cherry-picking https://github.com/tianocore/edk2/commit/302cc88ab36ffb96622987a55f4abc22a4751fed

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 device

Integration Instructions

N/A

🚀 Features & ✨ Enhancements

Add Repo Remote Check Plugin @makubacki (#1546)

Change Details

Description

Adds a plugin that is not active by default but can be opted into that validates git repositories against remote commit criteria before the build starts. It allows you to define rules that check whether the current HEAD commit in specified repositories is present or absent in specified remote URLs.

This is useful for enforcing that your local repositories are using commits from the correct upstream sources, and not from incompatible forks or remotes. For example, some workspaces might use a "public" and an "internal" upstream and need to verify that both work as expected and are set to the appropriate upstream when used for a given platform build.

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

How This Was Tested

• Verify that the plugin does not run unless the scope is set
• Verify JSON and YAML files can be parsed
• Verify repo check logic returns expected results

Integration Instructions

• See the plugin readme file

MdeModulePkg: Add gEdkiiNonDiscoverableDeviceUniqueIdProtocolGuid for deterministic UniqueId support in NonDiscoverablePciDeviceDxe @eeshanl (#1547)

Change Details

Description

MdeModulePkg: Add gEdkiiNonDiscoverableDeviceUniqueIdProtocolGuid for deterministic UniqueId support in NonDiscoverablePciDeviceDxe

With this new protocol, a platform can register a UniqueId to be used to identify the PciIo location. For example, if a device registers with the NonDiscoverableDeviceRegistrationLib, they can also publish this new protocol on the same EFI_HANDLE as RegisterNonDiscoverableMmioDevice. NonDiscoverablePciDeviceDxe will consume this UniqueId if found and the device's UniqueId to this value. If not found, it will back up to the prior method of assigning the UniqueId via a static counter. The platform must ensure all UniqueIds assigned are unique across the firmware.

Platforms may need to define their own UniqueIds through this method because the current UniqueId that gets used in NonDiscoverablePciDeviceDxe is a static counter, which can lead to non-deterministic value's being returned by PciIo->GetLocation(). In order to have a deterministic UniqueId returned by PciIo->GetLocation(), this protocol can be used to specify a specific UniqueId for a given Handle. For example, if a platform needs to Locate a specific NonDiscoverable PciIo protocol, they could use the determinstic UniqueId assigned through this protocol to find the expected PciIo instance. This protocol allows us to have a 1-1 defined mapping between a platform defined UniqueId and the NonDiscoverable PciIo protocol instance.

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

How This Was Tested

Tested on physical device

Integration Instructions

When assigning a unique ID via this protocol, the platform should ensure that the ID is unique across all instances of this protocol across the platform. The UniqueId must be in the range of: MAX_NON_DISCOVERABLE_PCI_DEVICE_ID/2 Revision = NON_DISCOVERABLE_DEVICE_UNIQUE_ID_PROTOCOL_REVISION; UniqueIdProtocol->UniqueId = 0x1000; // MAX_NON_DISCOVERABLE_PCI_DEVICE_ID/2 InstallMultipleProtocolInterfaces (&Handle, &gEdkiiNonDiscoverableDeviceUniqueIdProtocolGuid, UniqueIdProtocol, NULL);

## 🐛 Bug Fixes


Adding check for underflow/overflow when iterating through resource descriptor hobs @kuqin12 (#1549)


Change Details


## Description

During DXE core memory service initialization, the system would check available resource descriptor hobs against the memory top from PHIT hob.

However, it is possible that a given resource descriptor hob will not be larger than the cover the memory top, causing the Length calculation to underflow. Or the hob is not properly prepared and cause the calculation to overflow.

This change adds a check for potential underflow/overflow before performing the subtraction.

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

## How This Was Tested

This change was tested on QEMU SBSA and booted to both UEFI shell and Windows VOS.

## Integration Instructions

N/A


Xhci DMA buffer Allocation fix @eeshanl (#1539)


Change Details


## Description

Changes Pool allocations to use the PciIo interface's AllocateBuffer routine

DMA buffers should be page aligned and always allocated with the appropriate PciIo interface.

On some platforms, where IoMmu is enabled it is possible that if two allocations occur within the same page, and one gets unmapped via PciIo->Unmap, it will also unmap the other allocated address.

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

## How This Was Tested...