Skip to content

Releases: microsoft/mu_basecore

v2025110002.0.13

Choose a tag to compare

@mu-automation mu-automation released this 22 Jul 16:46
f18bff2

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




Full Changelog: v2025110002.0.12...v2025110002.0.13

v2025110002.0.12

Choose a tag to compare

@mu-automation mu-automation released this 21 Jul 23:20

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

Choose a tag to compare

@mu-automation mu-automation released this 16 Jul 18:48

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

Choose a tag to compare

@mu-automation mu-automation released this 16 Jul 16:08

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

Choose a tag to compare

@mu-automation mu-automation released this 13 Jul 21:20
df95605

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 once is used in header files included in certain ways in ASL source files.


    When Trim processes an ASL file (--asl-file), it textually inlines the body of every Include()'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, each Include() 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, .act files fall under Acpi-Table-Code-File and are compiled, linked, and processed by genfw.
    • .asl, .Asl, and .ASL files fall in Acpi-Source-Language-File and are processed by Trim:
      1. Trim --asl-file to produce a single combined .i file with includes inlined.
      2. ASLPP (ASL preprocessor, a C preprocessor) on the output of Trim to 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.
      3. Trim --source-code which takes the pre-processed .iii file and produces a .iiii file with content like linemarkers cleaned up.
      4. The ACPI compiler compiles the .iiii file to produce AML bytecode in a .aml file.

    Because the .aslc/.act files are directly passed to normal C processing tools, they are not part of the Trim change 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 #include directive. In addition, different file types may be included such as a .asl file or a .h file.

    Trim handles these cases differently:

    • For ASL Include() directives, Trim inlines 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 once or include guards.
    • For C-style #include directives, Trim checks the file extension of the included file. If the file is an ASL file (.asl or .asi), Trim treats the file the same as the Include() case. Otherwise, Trim passes 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 .i might include:

    • Inlined file content (from a .asl or .h file) depending on the include type and file extension.
    • Verbatim #include directives for non-ASL files which will be processed by the C preprocessor.

    Focusing on the "inlined" case, historically .h files would have traditional C include guards (#ifndef/#define, #endif). However, files might also include #pragma once as a guard.

    In that case, the inlined content of the .i file could contain multiple #pragma once directives, one per include site. When the C preprocessor (ASLPP) processes the .i file, it sees multiple #pragma once directives 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() in Trim.py so 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 once directive, the directive is stripped from the inlined content which prevents the warning.

    This is considered acceptable because it only removes the #pragma once directive from the inlined content for these specific cases. So, the .i file might contain multiple inlined copies of the same header content (like always in this inline case) but without the #pragma once directives. 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 (#define multiple 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, .iii files, 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 once in .h files.

    Integration Instructions

    • N/A


Full Changelog: v2025110002.0.8...v2025110002.0.9

v2025110002.0.8

Choose a tag to compare

@mu-automation mu-automation released this 26 Jun 15:52

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

Choose a tag to compare

@mu-automation mu-automation released this 25 Jun 22:08

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

Choose a tag to compare

@mu-automation mu-automation released this 24 Jun 00:26

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

Choose a tag to compare

@mu-automation mu-automation released this 23 Jun 14:54

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

Choose a tag to compare

@mu-automation mu-automation released this 22 Jun 21:25

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 = TRUE will change behavior to only rebase XIP modules. It is not believe this is currently used. The standard case of FvForceRebase not set or set to FALSE will not change in behavior.

    Current platforms using FvForceRebase = TRUE either 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