Releases: microsoft/mu_basecore
Release list
v2025110002.0.13
What's Changed
-
MdeModulePkg: Print unknown error code instead of asserting Chris Fernald (@cfernald) (#1855)
Change Details
## Description
DumpUicCmdExecResult is called to dump the result of UIC commands after a failure. Depending on the nature of the failure, not all information may have been properly initialized. This is already handled in callers with existing retry logic, but the assert in the dump command can cause a crash in debug builds for due to hardware race conditions on first attempt.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested
Testing on internal hardware
Integration Instructions
N/A
-
[CHERRY-PICK] MdePkg/AdapterInformation: Add CDAT adapter information type BoscoChen (@v-boscochen) (#1854)
Change Details
## Description
Define EFI_ADAPTER_INFO_CDAT_TYPE_GUID and EFI_ADAPTER_INFO_CDAT_TYPE_TYPE
for exposing Coherent Device Attribute Table (CDAT) data via
EFI_ADAPTER_INFORMATION_PROTOCOL. Register gEfiAdapterInfoCdatTypeGuid in
MdePkg.dec.Ref: UEFI spec 2.11 sec 11.12
https://uefi.org/specs/UEFI/2.11/11_Protocols_UEFI_Driver_Model.html#efi-adapter-information-protocol-information-typesSigned-off-by: Abdul Lateef Attar AbdulLateef.Attar@amd.com
(cherry picked from commit 0bc238d)- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested
Verify Build validate
Integration Instructions
N/A
Full Changelog: v2025110002.0.12...v2025110002.0.13
v2025110002.0.12
What's Changed
-
[Cherry-Pick] BaseTools: Enable 4k alignment for tool chains Aaron (@apop5) (#1845)
Change Details
## Description
Reordering x64 toolchain defines (GCCS) to use a DLINK_XIPFLAGS to set common-page-size to 0x40. Otherwise use default align (0x1000 for x64).
Reorder CLANGDWARF toolchain defines to use DLINK_XIPFLAGS to set common-page-size to 0x40 (matching existing behavior) and otherwise use default linker value (0x1000 for x64). Required modifying build_rule.template to support CLANGDWARF build family for SEC, PEI_CORE, PEIM type files.
(cherry picked from commit 87e486f)
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested
Local builds under linux to verify 4k alignment for x64, and 0x40 alignment for ia32
Integration Instructions
This may increase the size of compiled images.
If platforms choose to opt out of 4k alignment, they can do so with a DLINK override in their platform DSC file.
-
[REBASE\&FF] SecurityPkg: Add Google Test MockSecureBootVariableLib Joey Vagedes (@Javagedes) (#1852)
Change Details
Description
Cherry-pick from edk2: tianocore/edk2@3fec625
Add Google Test Mock library header and implementation for SecureBootVariableLib to allow simple mocking for host based unit tests that utilize the Google Test framework.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested
N/A
Integration Instructions
N/A
Full Changelog: v2025110002.0.11...v2025110002.0.12
v2025110002.0.11
What's Changed
-
[release/202511] Update BaseTools ext dep to v2025110002.0.10 @[mu-automation[bot]](https://github.com/apps/mu-automation) (#1851)
Change Details
This PR updates the BaseTools external dependency to version v2025110002.0.10.
Full Changelog: v2025110002.0.10...v2025110002.0.11
v2025110002.0.10
What's Changed
🐛 Bug Fixes
-
[CHERRY-PICK] BaseTools/GenFv: Preserve legacy rebase behavior when Xip is unused Oliver Smith-Denny (@os-d) (#1849)
Change Details
## Description
[CHERRY-PICK] BaseTools/GenFv: Preserve legacy rebase behavior when Xip is unused
Add XipFileCount to FV_INFO to track how many files have the ,XIP
suffix. Update FfsRebase() to only apply selective XIP rebase when
XipFileCount > 0. When no files have the ,XIP suffix (XipFileCount
== 0), preserve the legacy ForceRebase=TRUE behavior of rebasing all
files. This maintains backward compatibility for existing platforms
that use FvForceRebase=TRUE without any Xip rules.(cherry picked from commit 0347d3b)
[CHERRY-PICK] BaseTools/Tests: Update TC6 for backward-compatible rebase behavior
Update the test decision matrix and TC6 expected result to reflect
the backward-compatible ForceRebase logic: when ForceRebase=TRUE and
no files have the ,XIP suffix (XipFileCount==0), all files are
rebased using the legacy behavior rather than skipping all files.(cherry picked from commit ae023db)
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested
Tested by original reporter that backwards compat was broken.
Integration Instructions
N/A.
</blockquote> <hr> </details>
Full Changelog: v2025110002.0.9...v2025110002.0.10
v2025110002.0.9
What's Changed
-
[release/202511] Update BaseTools ext dep to v2025110002.0.8 @[mu-automation[bot]](https://github.com/apps/mu-automation) (#1839)
Change Details
This PR updates the BaseTools external dependency to version v2025110002.0.8.
-
BaseTools/Trim.py: Strip "#pragma once" from inlined ASL content Michael Kubacki (@makubacki) (#1840)
Change Details
## Description
The pragma once changes in edk2 were not made until the end of February and are first released in the edk2-stable202605 tag. However, some Mu platforms have moved ahead with pragma once changes in code outside of Mu. The main issue reported with doing so is compiling ASL where some of the header files in subprojects are using pragma once.
A change was upstreamed to edk2 for this that is in review (PR 12667). The change there has been tested against several likely scenarios.
This PR introduces the change to Mu first so the platforms that need this support now can have it and confirm the change with their platform build. There is not impact to existing use cases that do not use pragma once in header files included in ASL builds.
Note: If a broader move to pragma once is needed before the 202605 stable tag is released in Mu, that needs to be requested in a GitHub issue and will require additional changes.
Original PR Description From the edk2 PR
Note: I've made this description verbose because (1) I'm not sure everyone is familiar with the details and nuances of this flow and (2) I tried to balance a simple solution versus practical concerns and I want that to be obvious for feedback on the approach. TLDR is this addresses a potential warning in some C preprocessors if
#pragma onceis used in header files included in certain ways in ASL source files.
When
Trimprocesses an ASL file (--asl-file), it textually inlines the body of everyInclude()'d file directly into the constructed preprocessor input, once per include site.Its has duplicate protection in the form of a circular-include stack (
gIncludedAslFile), that prevents A->B->A cycles. But, as far as the script is concerned, eachInclude()is a unique include site.Various combinations of includes and file types are possible and handled slightly differently.
Starting with file types as defined in BaseTools\Conf\build_rule.template:
.aslc,.actfiles fall underAcpi-Table-Code-Fileand are compiled, linked, and processed bygenfw..asl,.Asl, and.ASLfiles fall inAcpi-Source-Language-Fileand are processed byTrim:Trim --asl-fileto produce a single combined .i file with includes inlined.ASLPP(ASL preprocessor, a C preprocessor) on the output ofTrimto produce a .iii file with all macros expanded and conditional branches resolved. AutoGen.h is also included and processed here to resolve fixed PCD values if needed.Trim --source-codewhich takes the pre-processed .iii file and produces a .iiii file with content like linemarkers cleaned up.- The ACPI compiler compiles the .iiii file to produce AML bytecode in a .aml file.
Because the
.aslc/.actfiles are directly passed to normal C processing tools, they are not part of theTrimchange made in this commit and the remainder of this message focuses on the ACPI Source Language File case.ASL files can use either an ASL
Include()directive or a C-style#includedirective. In addition, different file types may be included such as a.aslfile or a.hfile.Trimhandles these cases differently:- For ASL
Include()directives,Triminlines the content of the included file directly into the output at the include site. This is done for all included ASL files regardless of their extension. The inlining is purely textual and does not attempt to resolve or preserve any preprocessor directives such as#pragma onceor include guards. - For C-style
#includedirectives,Trimchecks the file extension of the included file. If the file is an ASL file (.aslor.asi),Trimtreats the file the same as theInclude()case. Otherwise,Trimpasses the directive through verbatim to the output, allowing the downstream C preprocessor (ASLPP) to handle it according to normal C preprocessor rules.
This creates a situtation in which the resulting
.imight include:- Inlined file content (from a
.aslor.hfile) depending on the include type and file extension. - Verbatim
#includedirectives for non-ASL files which will be processed by the C preprocessor.
Focusing on the "inlined" case, historically
.hfiles would have traditional C include guards (#ifndef/#define,#endif). However, files might also include#pragma onceas a guard.In that case, the inlined content of the
.ifile could contain multiple#pragma oncedirectives, one per include site. When the C preprocessor (ASLPP) processes the.ifile, it sees multiple#pragma oncedirectives in what it considers the main file, and could emit a warning like the following from gcc:warning: '#pragma once' in main file [-Wpragma-once-outside-header]
The remainder of this commit message describes the change made to address this warning.
This change strips "#pragma once" lines on the ASL content path in
DoInclude()inTrim.pyso the directive is removed before it reaches the C preprocessor.- "#include" directives for non-ASL files are still passed through verbatim for the C preprocessor to resolve where the contents of those .h files might contain "#pragma once" or traditional guards.
- Traditional include guards are untouched and continue to behave as before where multiple include sites might inline the same content in the .i file before reaching the C preprocessor.
The change:
In the case that a file is inlined with a
#pragma oncedirective, the directive is stripped from the inlined content which prevents the warning.This is considered acceptable because it only removes the
#pragma oncedirective from the inlined content for these specific cases. So, the.ifile might contain multiple inlined copies of the same header content (like always in this inline case) but without the#pragma oncedirectives. Because actual C content was already not processed or trimmed out (e.g.typedef struct) duplicate content that could cause multiple symbol definitions is not considered to be a problem (#definemultiple times is not a problem for the C preprocessor).
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested
- edk2/Mu CI
- Platform build with no pragma once in header files
- Look at the output (
.i,.iiifiles, etc.) of Trim.py and C preprocessor output with gcc and MSVC linkers. - Test against platforms using complex variations of include types including the inlining case with
#pragma oncein .h files.
Integration Instructions
- N/A
Full Changelog: v2025110002.0.8...v2025110002.0.9
v2025110002.0.8
What's Changed
-
[REBASE \& FF] [CHERRY-PICK] Cherry-Pick PEI Memory Bins Commits Oliver Smith-Denny (@os-d) (#1838)
Change Details
## Description
PEI memory bins has been merged in edk2. This reverts the Mu changes and pulls in the edk2 commits. It also cherry-picks some other related commits that had been upstreamed to edk2 but not pulled down to Mu related to memory bins.
Finally, the resource descriptor HOB v2 change needed to be reverted and reapplied so the logic would go in the correct spot with the PEI memory bins changes.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested
Booting patina-qemu to shell and confirming PEI memory bins worked and are inherited in DXE.
Integration Instructions
N/A.
</blockquote> <hr> </details>
Full Changelog: v2025110002.0.7...v2025110002.0.8
v2025110002.0.7
What's Changed
-
SecurityPkg: Introduce Dynamic TCG Log Scaling V2 Raymond-MS (#1805)
Change Details
## Description
Implemented dynamic TCG log scaling in Tcg2Dxe. When the log would become truncated it instead now dynamically scales doubling the size each time. An ERROR log is reported that an increase to your base log size should occur such that scaling is not necessary. This is a precaution against platforms that log a lot and the addition of new hashing algorithms for PQC. The log is allocated in BootServices memory. Tests were added via TcgLogTest which includes a DXE driver and a UEFI shell UnitTest app. The DXE driver handles pre-ReadyToBoot tests while the TestApp handles post-ReadyToBoot tests as well as gathering the test results from the DXE driver. Markdown documents were created to detail the changes.
This version of dynamic scaling never sets the ACPI table LAML/LASA which means the table is never published with the log information. As such the only way to access the event log is through the Tcg2Protocol published by Tcg2Dxe. The LAML/LASA fields are OPTIONAL and when not set are removed from the table.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested
Tested via TcgLogTest included in the reference QEMU ARM VIRT platform with TPM enabled. Confirmed the UnitTest results. All tests report PASS.
Integration Instructions
Include the TcgLogTest .inf's to your platform .dsc and .fdf files. You will need to include both the TcgLogTestDxe and TcgLogTestApp for full functionality.
-
ArmPkg/SmmuDxe: Set cacheability attributes in the Stage-2 page table leaf-level entries Eeshan Londhe (@eeshanl) (#1837)
Change Details
## Description
ArmPkg/SmmuDxe: Set cacheability attributes in the Stage-2 page table leaf-level entries
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested
Tested on physical Arm platform and ArmVirtPkg.
Tested with BlockIoPerfTest and noted the performance gain from adding the cacheability attributes.
Tested high throughput scenario of windows hibernate/resume.
Integration Instructions
N/A
-
[Rebase \& FF] Fix Partition ID being used for FFA\_RUN calls kuqin12 (#1827)
Change Details
## Description
The current implementation of FFA run invocation always uses the original partition ID as the input for FFA_RUN. However, this is problematic when the partitions are chain loading the direct request 2 functions and the partitions are interruptible. In that case, the caller should FFA_RUN to the partition specified in w1.
Then the w1 information was eaten in the case of direct request calls, because we only exposed the payload to the callers.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested
This is tested on ARM virt and physical platform.
Integration Instructions
N/A
Full Changelog: v2025110002.0.6...v2025110002.0.7
v2025110002.0.6
What's Changed
-
[CHERRY-PICK] FatPkg: Clean any volume caches during exit boot services Chris Fernald (@cfernald) (#1832)
Change Details
## Description
The current implementation assumes the the caller will perform the necessary cleanup before exiting boot services. This has been observed to drop some cached file writes that occur even before the application calling exit boot services is launched.
This commit adds a per-volume pre-ExitBootServices event to flush any dirty caches and perform other cleanup the volume to ensure all write data is persisted and consistent. After the flush, caching will be disabled for the volume in the future to ensure that all subsequent access persists.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested
Tested on QEMU with one-off shell test and boot to OS
Integration Instructions
N/A
</blockquote> <hr> </details>
-
[CHERRY-PICK] MdeModulePkg/Core/Dxe/Gcd: make persistent override special-purpose Sureshkumar Ponnusamy (@sureshkumarpMSFT) (#1834)
Change Details
MdeModulePkg/Core/Dxe/Gcd: make persistent override special-purpose
Fix the GCD memory type selection logic in DXE GCD initialization so persistent memory correctly takes precedence over special-purpose memory when both attributes are present.
The existing code/comment said persistent should win, but the condition order allowed special-purpose to overwrite persistent. This change swaps the checks so behavior matches the intended precedence and comment.
(cherry picked from commit e03fb69)
Description
Fix the GCD memory type selection logic in DXE GCD initialization so persistent memory correctly takes precedence over special-purpose memory when both attributes are present.
The existing code/comment said persistent should win, but the condition order allowed special-purpose to overwrite persistent. This change swaps the checks so behavior matches the intended precedence and comment.
Signed-off-by: Sureshkumar Ponnusamy sponnusamy@microsoft.com
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested
Validated on target system with a Resource Descriptor HOB containing both EFI_RESOURCE_ATTRIBUTE_PERSISTENT and EFI_RESOURCE_ATTRIBUTE_SPECIAL_PURPOSE.
Confirmed resulting GCD memory type is EfiGcdMemoryTypePersistent
Integration Instructions
N/A
</blockquote> <hr> </details>
Full Changelog: v2025110002.0.5...v2025110002.0.6
v2025110002.0.5
What's Changed
-
ArmPkg: Handle FFA\_BUSY response for MM communication Chris Fernald (@cfernald) (#1825)
Change Details
## Description
MM communicate is used at runtime, and the secure partition it is communicating with may provide services access through other means then the UEFI runtime services. As such, the MM communication library must not assume that the partition will be in the waiting state. Instead, it must handle the case where the partition is busy and retry the communication to some limit.
Observed issue
This specifically resolves a bugcheck observed booting to Windows on multiple platforms where the variable services are access through the runtime services at the same time that the TPM PPI is invoking StMM to access the PPI variables. This causes a busy response in the runtime services, which are not currently handled. The inverse is already handled as the ACPI FFH opregion handling for FF-A already accounts for busy responses.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested
- Boot to OS on ArmVirt
- Boot to OS on physical platform
Integration Instructions
N/A
</blockquote> <hr> </details>
-
[release/202511] Update BaseTools ext dep to v2025110002.0.4 @[mu-automation[bot]](https://github.com/apps/mu-automation) (#1831)
Change Details
This PR updates the BaseTools external dependency to version v2025110002.0.4.
Full Changelog: v2025110002.0.4...v2025110002.0.5
v2025110002.0.4
What's Changed
-
[CHERRY-PICK] [REBASE \& FF] Cherry-Pick BaseTools XIP Changes Oliver Smith-Denny (@os-d) (#1830)
Change Details
## Description
This cherry-picks a set of BaseTools changes from edk2 to support only rebasing XIP modules in an FV.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested
See edk2 PR.
Integration Instructions
This is marked as a breaking change because
FvForceRebase = TRUEwill change behavior to only rebase XIP modules. It is not believe this is currently used. The standard case ofFvForceRebasenot set or set to FALSE will not change in behavior.Current platforms using
FvForceRebase = TRUEeither should remove the keyword to maintain the same behavior (rebase everything in an FV) or use the new mechanism to only rebase XIP modules.</blockquote> <hr> </details>
-
[release/202511] Update BaseTools ext dep to v2025110002.0.3 @[mu-automation[bot]](https://github.com/apps/mu-automation) (#1828)
Change Details
This PR updates the BaseTools external dependency to version v2025110002.0.3.
Full Changelog: v2025110002.0.3...v2025110002.0.4