Releases: microsoft/mu_tiano_platforms
v7.0.1
What's Changed
-
Add `bochs` VGA binary to QEMU release @kuqin12 (#950)
Change Details
## Description
This change added an extra binary from QEMU builds to support QEMU-SBSA platform graphic operations.
- Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
- Security - Does the change have a direct security impact on an application,
flow, or firmware? - Examples: Crypto algorithm change, buffer overflow fix, parameter
validation improvement, ...
- Security - Does the change have a direct security impact on an application,
- Breaking change?
- Breaking change - Will anyone consuming this change experience a break
in build or boot behavior? - Examples: Add a new library class, move a module to a different repo, call
a function in a new library class in a pre-existing module, ...
- Breaking change - Will anyone consuming this change experience a break
- Includes tests?
- Tests - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
- Documentation - Does the change contain explicit documentation additions
outside direct code modifications (and comments)? - Examples: Update readme file, add feature readme file, link to documentation
on an a separate Web page, ...
- Documentation - Does the change contain explicit documentation additions
How This Was Tested
This was tested locally by running QEMU-SBSA with the platform release UEFI binaries and booted to UEFI shell properly.
Integration Instructions
N/A
- Impacts functionality?
-
Add Advanced Logger PRM to Q35 @os-d (#935)
Change Details
## Description
The Advanced Logger PRM was added to Advanced Logger. This PR gives an example of integrating it and using it.
- Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
- Security - Does the change have a direct security impact on an application,
flow, or firmware? - Examples: Crypto algorithm change, buffer overflow fix, parameter
validation improvement, ...
- Security - Does the change have a direct security impact on an application,
- Breaking change?
- Breaking change - Will anyone consuming this change experience a break
in build or boot behavior? - Examples: Add a new library class, move a module to a different repo, call
a function in a new library class in a pre-existing module, ...
- Breaking change - Will anyone consuming this change experience a break
- Includes tests?
- Tests - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
- Documentation - Does the change contain explicit documentation additions
outside direct code modifications (and comments)? - Examples: Update readme file, add feature readme file, link to documentation
on an a separate Web page, ...
- Documentation - Does the change contain explicit documentation additions
How This Was Tested
Tested by booting Q35 to Windows and fetching the log via the variable interface and the PRM interface and confirming the log is the same.
Integration Instructions
Follow this example to integrate into another platform.
- Impacts functionality?
-
Add NETWORK\_ENABLE option @makubacki (#940)
Change Details
## Description
Simplifies network enabling by using a dedicated flag for enabling.
Preserves existing behavior where networking is disabled by default.
Networking was hardcoded to off in the QemuSbsaPkg runner, that is
not modified in this change.- Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
- Security - Does the change have a direct security impact on an application,
flow, or firmware? - Examples: Crypto algorithm change, buffer overflow fix, parameter
validation improvement, ...
- Security - Does the change have a direct security impact on an application,
- Breaking change?
- Breaking change - Will anyone consuming this change experience a break
in build or boot behavior? - Examples: Add a new library class, move a module to a different repo, call
a function in a new library class in a pre-existing module, ...
- Breaking change - Will anyone consuming this change experience a break
- Includes tests?
- Tests - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
- Documentation - Does the change contain explicit documentation additions
outside direct code modifications (and comments)? - Examples: Update readme file, add feature readme file, link to documentation
on an a separate Web page, ...
- Documentation - Does the change contain explicit documentation additions
How This Was Tested
- Run without flag set and verify networking is disabled.
- Run with flag and verify networking is enabled.
Integration Instructions
N/A
- Impacts functionality?
-
Use MdeModulePkg BaseRngLibTimerLib instance @makubacki (#939)
Change Details
## Description
The BaseRngLibTimerLib instance was moved to MdeModulePkg as noted in
https://bugzilla.tianocore.org/show_bug.cgi?id=4504.That move was made because some algorithm GUIDs were added to the
GetRngGuid() interface that were not in the UEFI Specification.tianocore/edk2@e934684
adds a deprecation message to the older MdePkg instance.This change updates all paths in this repo to use the MdeModulePkg
instance.- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested
- QemuQ35Pkg and QemuSbsaPkg built and boot to EFI shell
Integration Instructions
N/A
-
Update QEMU external dependency @kuqin12 (#926)
Change Details
## Description
The latest QEMU v9.0.0 is updated in the platform release v7.0.0. This change is to pick it up.
- Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
- Security - Does the change have a direct security impact on an application,
flow, or firmware? - Examples: Crypto algorithm change, buffer overflow fix, parameter
validation improvement, ...
- Security - Does the change have a direct security impact on an application,
- Breaking change?
- Breaking change - Will anyone consuming this change experience a break
in build or boot behavior? - Examples: Add a new library class, move a module to a different repo, call
a function in a new library class in a pre-existing module, ...
- Breaking change - Will anyone consuming this change experience a break
- Includes tests?
- Tests - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
- Documentation - Does the change contain explicit documentation additions
outside direct code modifications (and comments)? - Examples: Update readme file, add feature readme file, link to documentation
on an a separate Web page, ...
- Documentation - Does the change contain explicit documentation additions
How This Was Tested
This change is tested on QEMU Q35 as well as SBSA and booted to UEFI shell.
Integration Instructions
N/A
- Impacts functionality?
🐛 Bug Fixes
-
Added exception handling when `GetConsoleMode` API fails @kuqin12 (#929)
Change Details
## Description
This change fixes a pipeline break after moving to QEMU v9.0.0 by adding a try-except routine to handle the case on the server builds.
- Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
- Security - Does the change have a direct security impact on an application,
flow, or firmware? - Examples: Crypto algorithm change, buffer overflow fix, parameter
validation improvement, ...
- Security - Does the change have a direct security impact on an application,
- Breaking change?
- Breaking change - Will anyone consuming this change experience a break
in build or boot behavior? - Examples: Add a new library class, move a module to a different repo, call
a function in a new library class in a pre-existing module, ...
- Breaking change - Will anyone consuming this change experience a break
- Includes tests?
- Tests - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
- Documentation - Does the change contain explicit documentation additions
outside direct code modifications (and comments)? - Examples: Update readme file, add feature readme file, link to documentation
on an a separate Web page, ...
- Documentation - Does the change contain explicit documentation additions
How This Was Tested
This change was tested locally and on the pipeline build.
Integ...
- Impacts functionality?
v7.0.0
What's Changed
-
Upgrade default QEMU to v9.0.0 @kuqin12 (#901)
Change Details
## Description
v9.0.0 fixed a few known issues blocking us from upgrading to QEMU of later than v7.2.0.
This change is made to upgrade the default QEMU to v9.0.0 to intake the latest release.
- Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
- Security - Does the change have a direct security impact on an application,
flow, or firmware? - Examples: Crypto algorithm change, buffer overflow fix, parameter
validation improvement, ...
- Security - Does the change have a direct security impact on an application,
- Breaking change?
- Breaking change - Will anyone consuming this change experience a break
in build or boot behavior? - Examples: Add a new library class, move a module to a different repo, call
a function in a new library class in a pre-existing module, ...
- Breaking change - Will anyone consuming this change experience a break
- Includes tests?
- Tests - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
- Documentation - Does the change contain explicit documentation additions
outside direct code modifications (and comments)? - Examples: Update readme file, add feature readme file, link to documentation
on an a separate Web page, ...
- Documentation - Does the change contain explicit documentation additions
How This Was Tested
This change is tested locally on Windows and WSL environment.
Integration Instructions
Existing clones will need to perform
PlatformBuild.py --update
to download the latest version of QEMU.
- Impacts functionality?
-
Integrate TF-A v2.10 @kuqin12 (#920)
Change Details
# Preface
Please ensure you have read the contribution docs prior
to submitting the pull request. In particular,
pull request guidelines.Description
The TF-A v2.10 updated the footprint of images drastically and supported extra CPU models, causing the existing flash map not able to suit the BL1.
This change updated the flash map and improved the patching routine in post-build to fail the build next time.
For each item, place an "x" in between
[
and]
if true. Example:[x]
.
(you can also check items in the GitHub UI)- Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
- Security - Does the change have a direct security impact on an application,
flow, or firmware? - Examples: Crypto algorithm change, buffer overflow fix, parameter
validation improvement, ...
- Security - Does the change have a direct security impact on an application,
- Breaking change?
- Breaking change - Will anyone consuming this change experience a break
in build or boot behavior? - Examples: Add a new library class, move a module to a different repo, call
a function in a new library class in a pre-existing module, ...
- Breaking change - Will anyone consuming this change experience a break
- Includes tests?
- Tests - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
- Documentation - Does the change contain explicit documentation additions
outside direct code modifications (and comments)? - Examples: Update readme file, add feature readme file, link to documentation
on an a separate Web page, ...
- Documentation - Does the change contain explicit documentation additions
How This Was Tested
This is tested functional on QEMU SBSA with max CPU model.
Integration Instructions
N/A
</blockquote> <hr> </details>
- Impacts functionality?
-
Refresh Paging Audit Test App CI Exemption @TaylorBeebe (#919)
Change Details
## Description
The DXE paging audit test app was updated to check for Enhanced Memory
Protection compliance. Project Mu is currently being updated to pass to
pass the remaining two checks (RP on free memory and RP on GCD
nonexistent regions). This PR updates the exemption date for
SBSA and Q35 so test failures don't block CI gates.- Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
- Security - Does the change have a direct security impact on an application,
flow, or firmware? - Examples: Crypto algorithm change, buffer overflow fix, parameter
validation improvement, ...
- Security - Does the change have a direct security impact on an application,
- Breaking change?
- Breaking change - Will anyone consuming this change experience a break
in build or boot behavior? - Examples: Add a new library class, move a module to a different repo, call
a function in a new library class in a pre-existing module, ...
- Breaking change - Will anyone consuming this change experience a break
- Includes tests?
- Tests - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
- Documentation - Does the change contain explicit documentation additions
outside direct code modifications (and comments)? - Examples: Update readme file, add feature readme file, link to documentation
on an a separate Web page, ...
- Documentation - Does the change contain explicit documentation additions
How This Was Tested
Tested in CI pipelines
Integration Instructions
N/A
- Impacts functionality?
-
qemu\_extdep: Remove the linux extdep @Javagedes (#915)
Change Details
## Description
Removes the qemu external dependency for linux and instead uses the qemu that is directly installed on the system.
Note: I've opted to keep the github action that produces the linux external dependency in-case we opt to switch back to using it, or as an example to anyone that needs to build it locally.
- Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
- Security - Does the change have a direct security impact on an application,
flow, or firmware? - Examples: Crypto algorithm change, buffer overflow fix, parameter
validation improvement, ...
- Security - Does the change have a direct security impact on an application,
- Breaking change?
- Breaking change - Will anyone consuming this change experience a break
in build or boot behavior? - Examples: Add a new library class, move a module to a different repo, call
a function in a new library class in a pre-existing module, ...
- Breaking change - Will anyone consuming this change experience a break
- Includes tests?
- Tests - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
- Documentation - Does the change contain explicit documentation additions
outside direct code modifications (and comments)? - Examples: Update readme file, add feature readme file, link to documentation
on an a separate Web page, ...
- Documentation - Does the change contain explicit documentation additions
How This Was Tested
N/A
Integration Instructions
N/A
</blockquote> <hr> </details>
- Impacts functionality?
-
Enable MU Debugger Package for Q35 \& SBSA @cfernald (#910)
Change Details
## Description
Ingests the MU_FEATURE_DEBUGGER repo and enabled the software debugger for both Q35 and SBSA through the build flag
BLD_*_DEBUGGER_ENABLED=TRUE
to debug over the serial port specified by the runtime flagSERIAL_PORT=####
.Creates a debug transport for Q35 that wraps the IO port serial port lib implementation but swaps the UART port address before calling to allow the debugger to run on a separate port then the debug output.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested
Locally tested on both SBSA and Q35.
Integration Instructions
N/A
</blockquote> <hr> </details>
⚠️ Breaking Changes
-
Update MU\_BASECORE to v2023110004.0.0, MM\_SUPV to v11.0.1 and MU\_PLUS to v2023110000.0.5 @kuqin12 (#911)
Change Details
## Description
This change updates the MU_BASECORE, MM_SUPV and MU_PLUS submodules and fixes integration errors:
Submodule Version MU_BASECORE v2023110004.0.0 MM_SUPV v11.0.1 MU_PLUS v2023110000.0.5 - Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
- Security - Does the change have a direct security impact on an application,
flow, or firmware? - Examples: Crypto algorithm change, buffer overflow fix, parameter
validation improvement, ...
- Security - Does the change have a direct security impact on an application,
- Breaking change?
- **Break...
- Impacts functionality?
v6.0.0
What's Changed
-
Add HTTP and acpiview commands to UEFI shell @kuqin12 (#902)
Change Details
# Preface
Please ensure you have read the contribution docs prior
to submitting the pull request. In particular,
pull request guidelines.Description
Current QEMU platforms do not support needed cmdlets for system status inspection.
This change added a few command options to the UEFI shell to further support necessary tests in the future.
For each item, place an "x" in between
[
and]
if true. Example:[x]
.
(you can also check items in the GitHub UI)- Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
- Security - Does the change have a direct security impact on an application,
flow, or firmware? - Examples: Crypto algorithm change, buffer overflow fix, parameter
validation improvement, ...
- Security - Does the change have a direct security impact on an application,
- Breaking change?
- Breaking change - Will anyone consuming this change experience a break
in build or boot behavior? - Examples: Add a new library class, move a module to a different repo, call
a function in a new library class in a pre-existing module, ...
- Breaking change - Will anyone consuming this change experience a break
- Includes tests?
- Tests - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
- Documentation - Does the change contain explicit documentation additions
outside direct code modifications (and comments)? - Examples: Update readme file, add feature readme file, link to documentation
on an a separate Web page, ...
- Documentation - Does the change contain explicit documentation additions
How This Was Tested
This was tested on QEMU Q35 and SBSA in UEFI shell environments.
Integration Instructions
N/A
</blockquote> <hr> </details>
- Impacts functionality?
-
Fix console after returning from QEMU @kuqin12 (#900)
Change Details
# Preface
Please ensure you have read the contribution docs prior
to submitting the pull request. In particular,
pull request guidelines.Description
The fix is enlightened by the original QEMU thread here: https://gitlab.com/qemu-project/qemu/-/issues/1674.
The change fixed the garbled command prompt after returning from QEMU v8+ on Windows platforms.
For each item, place an "x" in between
[
and]
if true. Example:[x]
.
(you can also check items in the GitHub UI)- Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
- Security - Does the change have a direct security impact on an application,
flow, or firmware? - Examples: Crypto algorithm change, buffer overflow fix, parameter
validation improvement, ...
- Security - Does the change have a direct security impact on an application,
- Breaking change?
- Breaking change - Will anyone consuming this change experience a break
in build or boot behavior? - Examples: Add a new library class, move a module to a different repo, call
a function in a new library class in a pre-existing module, ...
- Breaking change - Will anyone consuming this change experience a break
- Includes tests?
- Tests - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
- Documentation - Does the change contain explicit documentation additions
outside direct code modifications (and comments)? - Examples: Update readme file, add feature readme file, link to documentation
on an a separate Web page, ...
- Documentation - Does the change contain explicit documentation additions
How This Was Tested
This was tested on QEMU v9.0.0-rc1 on Windows and confirmed it fixes the command prompt after returning from QEMU runner.
Integration Instructions
N/A
</blockquote> <hr> </details>
- Impacts functionality?
-
Remove UEFI Ext as it has moved to mu\_feature\_debugger @cfernald (#894)
Change Details
## Description
the UEFI windbg Extension has moved to https://github.com/microsoft/mu_feature_debugger.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested
N/A
Integration Instructions
N/A
</blockquote> <hr> </details>
-
Create Memory Allocation HOB Entry for QEMU FDT Blob @TaylorBeebe (#876)
Change Details
## Description
The flattened device tree blob is placed in memory at the address specified by PcdDeviceTreeInitialBaseAddress. This PR creates a memory allocation HOB entry for the pages spanning the start and end of the FDT so it cannot be allocated during boot.
- Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
- Security - Does the change have a direct security impact on an application,
flow, or firmware? - Examples: Crypto algorithm change, buffer overflow fix, parameter
validation improvement, ...
- Security - Does the change have a direct security impact on an application,
- Breaking change?
- Breaking change - Will anyone consuming this change experience a break
in build or boot behavior? - Examples: Add a new library class, move a module to a different repo, call
a function in a new library class in a pre-existing module, ...
- Breaking change - Will anyone consuming this change experience a break
- Includes tests?
- Tests - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
- Documentation - Does the change contain explicit documentation additions
outside direct code modifications (and comments)? - Examples: Update readme file, add feature readme file, link to documentation
on an a separate Web page, ...
- Documentation - Does the change contain explicit documentation additions
How This Was Tested
Tested by running SBSA and reviewing the memory allocation HOBs
Integration Instructions
N/A
</blockquote> <hr> </details>
- Impacts functionality?
-
Update Virtual Drive Manager File Collection and mu\_plus Subrepo @TaylorBeebe (#886)
Change Details
## Description
The PDE.dat file is no longer produced by the paging audit, so the get_file call will fail.
- Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
- Security - Does the change have a direct security impact on an application,
flow, or firmware? - Examples: Crypto algorithm change, buffer overflow fix, parameter
validation improvement, ...
- Security - Does the change have a direct security impact on an application,
- Breaking change?
- Breaking change - Will anyone consuming this change experience a break
in build or boot behavior? - Examples: Add a new library class, move a module to a different repo, call
a function in a new library class in a pre-existing module, ...
- Breaking change - Will anyone consuming this change experience a break
- Includes tests?
- Tests - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
- Documentation - Does the change contain explicit documentation additions
outside direct code modifications (and comments)? - Examples: Update readme file, add feature readme file, link to documentation
on an a separate Web page, ...
- Documentation - Does the change contain explicit documentation additions
How This Was Tested
Tested by running the paging audit on Q35 and SBSA
Integration Instructions
N/A
- Impacts functionality?
-
Add SSE4.1 Instructions to Q35 @os-d (#882)
Change Details
## Description
Windows requires both the SSE4.1 and SSE4.2 instructions to boot. Add these to the Q35 QEMU cmdline so that the VM has these available.
For each item, place an "x" in between
[
and]
if true. Example:[x]
.
(you can also check items in the GitHub UI)- Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
- Security - Does the change have a direct security impact on an application,
flow, or firmware? - Examples: Crypto algorithm change, buffer overflow fix, parameter
validation improvement, ...
- Security - Does the change have a direct security impact on an application,
- Breaking change?
- Breaking change - Will anyone consuming this change experience a break
in build or boot behavior? - Examples: Add a new library class, move a module to a different repo, call
a function in...
- Breaking change - Will anyone consuming this change experience a break
- Impacts functionality?
v5.1.2
What's Changed
-
.github/workflows/publish-qemu-bin.yml: reliability updates @Javagedes (#880)
Change Details
## Description
Updates release pipeline for the qemu binary to release qemu v7.2.0 as a external dependency and to also provide the following roms:
-
efi-e1000e.rom
-
efi-virtio.rom
-
Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
-
Impacts security?
- Security - Does the change have a direct security impact on an application,
flow, or firmware? - Examples: Crypto algorithm change, buffer overflow fix, parameter
validation improvement, ...
- Security - Does the change have a direct security impact on an application,
-
Breaking change?
- Breaking change - Will anyone consuming this change experience a break
in build or boot behavior? - Examples: Add a new library class, move a module to a different repo, call
a function in a new library class in a pre-existing module, ...
- Breaking change - Will anyone consuming this change experience a break
-
Includes tests?
- Tests - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
-
Includes documentation?
- Documentation - Does the change contain explicit documentation additions
outside direct code modifications (and comments)? - Examples: Update readme file, add feature readme file, link to documentation
on an a separate Web page, ...
- Documentation - Does the change contain explicit documentation additions
How This Was Tested
Verified Terminal was not in an invalid state after exiting qemu, and that the above roms were successfully found at runtime.
Integration Instructions
Perform a release and update the qemu external dependency inside mu_tiano_platforms
</blockquote> <hr> </details>
-
Full Changelog: v5.1.1...v5.1.2
v5.1.1
What's Changed
-
Add E1000 rom to QEMU ext dep @cfernald (#874)
Change Details
## Description
The e1000 NIC is useful for OS debugging and general "real hardware"-like network access.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested
N/A
Integration Instructions
N/A
</blockquote> <hr> </details>
-
Add SSE4.2 to q35 QEMU runner CPU features @cfernald (#873)
Change Details
## Description
The Instruction Set Extension, specifically SSE4.2, is standard and used by Windows. This adds it to the default QEMU configuration for Q35.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested
Tested local Windows boot.
Integration Instructions
N/A
</blockquote> <hr> </details>
-
Set PcdFixedDebugPrintErrorLevel in QemuSbsaPkg to Improve Boot Time @TaylorBeebe (#871)
Change Details
## Description
There's a large slowdown during GCD sync when the syncing logic debug dumps the GCD map thousands of times. I updated the syncing logic to skip the dump process if the GCD debug verbosity level is not set. Checking the verbosity is done via a call to DebugPrintLevelEnabled() in DebugLib which checks the fixed debug print PCD.
This PR sets the FixedAtBuild PCD to be the same as the PatchableInModule PCD so the map dump function is skipped.
- Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
- Security - Does the change have a direct security impact on an application,
flow, or firmware? - Examples: Crypto algorithm change, buffer overflow fix, parameter
validation improvement, ...
- Security - Does the change have a direct security impact on an application,
- Breaking change?
- Breaking change - Will anyone consuming this change experience a break
in build or boot behavior? - Examples: Add a new library class, move a module to a different repo, call
a function in a new library class in a pre-existing module, ...
- Breaking change - Will anyone consuming this change experience a break
- Includes tests?
- Tests - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
- Documentation - Does the change contain explicit documentation additions
outside direct code modifications (and comments)? - Examples: Update readme file, add feature readme file, link to documentation
on an a separate Web page, ...
- Documentation - Does the change contain explicit documentation additions
How This Was Tested
Tested by booting SBSA and observing the improved boot time.
Integration Instructions
N/A
</blockquote> <hr> </details>
- Impacts functionality?
-
Use qemu external dependency @Javagedes (#851)
Change Details
## Description
Use an external dependency for qemu rather than relying on it being installed by the user.
- Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
- Security - Does the change have a direct security impact on an application,
flow, or firmware? - Examples: Crypto algorithm change, buffer overflow fix, parameter
validation improvement, ...
- Security - Does the change have a direct security impact on an application,
- Breaking change?
- Breaking change - Will anyone consuming this change experience a break
in build or boot behavior? - Examples: Add a new library class, move a module to a different repo, call
a function in a new library class in a pre-existing module, ...
- Breaking change - Will anyone consuming this change experience a break
- Includes tests?
- Tests - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
- Documentation - Does the change contain explicit documentation additions
outside direct code modifications (and comments)? - Examples: Update readme file, add feature readme file, link to documentation
on an a separate Web page, ...
- Documentation - Does the change contain explicit documentation additions
How This Was Tested
Ensured Boot to shell and Boot to windows using the Windows and Linux qemu external dependencies. Verified TPM Replay functionality continued to work as expected.
Integration Instructions
N/A
</blockquote> <hr> </details>
- Impacts functionality?
🔐 Security Impacting
-
Update Subrepos to Sync Stack Cookie Changes @TaylorBeebe (#870)
Change Details
## Description
The StackCheckLib instances have been updated in all subrepos. Thi PR updates all subrepos and the StackCheckLib instances for SBSA and Q35.
- Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
- Security - Does the change have a direct security impact on an application,
flow, or firmware? - Examples: Crypto algorithm change, buffer overflow fix, parameter
validation improvement, ...
- Security - Does the change have a direct security impact on an application,
- Breaking change?
- Breaking change - Will anyone consuming this change experience a break
in build or boot behavior? - Examples: Add a new library class, move a module to a different repo, call
a function in a new library class in a pre-existing module, ...
- Breaking change - Will anyone consuming this change experience a break
- Includes tests?
- Tests - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
- Documentation - Does the change contain explicit documentation additions
outside direct code modifications (and comments)? - Examples: Update readme file, add feature readme file, link to documentation
on an a separate Web page, ...
- Documentation - Does the change contain explicit documentation additions
How This Was Tested
Tested in pipelines
Integration Instructions
N/A
</blockquote> <hr> </details>
- Impacts functionality?
🛠️ Submodule Updates
-
Bump MU\_BASECORE from 2023110001.0.2 to 2023110001.1.0 @ProjectMuBot (#865)
Change Details
Bumps MU_BASECORE from `2023110001.0.2` to `2023110001.1.0`
Introduces 5 new commits in MU_BASECORE.
Commits
Signed-off-by: Project Mu Bot mubot@microsoft.com
-
[Rebase \&\& FF] Bump MU\_BASECORE from 2023110001.0.1 to 2023110001.0.2 @ProjectMuBot (#858)
Change Details
Bumps MU_BASECORE from `2023110001.0.1` to `2023110001.0.2`
Introduces 1 new commits in MU_BASECORE.
Signed-off-by: Project Mu Bot mubot@microsoft.com
-
Bump Common/MU\_TIANO from 2023110000.0.2 to 2023110000.0.3 @ProjectMuBot (#862)
Change Details
Bumps Common/MU_TIANO from `2023...
v5.1.0
What's Changed
-
Add qemu binary release workflow: @Javagedes (#852)
Change Details
## Description
Add a new workflow that will build and prepare qemu binaries for both Windows and Linux. This workflow has three triggers:
-
A pull request to the main branch, which will only trigger when either the workflow itself, or the qemu version file is updated. This workflow will upload the binaries as an artifact to the workflow.
-
A release, which will upload the binaries as an artifact to the associated release
-
A manual trigger, which allows for testing the workflow on a custom branch. This will upload the binaries as an artifact to the workflow.
- Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
- Security - Does the change have a direct security impact on an application,
flow, or firmware? - Examples: Crypto algorithm change, buffer overflow fix, parameter
validation improvement, ...
- Security - Does the change have a direct security impact on an application,
- Breaking change?
- Breaking change - Will anyone consuming this change experience a break
in build or boot behavior? - Examples: Add a new library class, move a module to a different repo, call
a function in a new library class in a pre-existing module, ...
- Breaking change - Will anyone consuming this change experience a break
- Includes tests?
- Tests - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
- Documentation - Does the change contain explicit documentation additions
outside direct code modifications (and comments)? - Examples: Update readme file, add feature readme file, link to documentation
on an a separate Web page, ...
- Documentation - Does the change contain explicit documentation additions
How This Was Tested
A release was performed using this github action on a personal branch (v0.1.9), and was used as an external dependency on a mu_tiano_platforms Draft PR, which is passing, and will be merged once this PR has been merged and a release has been executed.
Integration Instructions
N/A
</blockquote> <hr> </details>
-
-
Install the Hash 2 Service Binding Protocol @makubacki (#857)
Change Details
## Description
Links the non-NULL instance of DxeHash2CryptoLib to QemuQ35Pkg and
QemuSbsaPkg so the Hash 2 Service Binding protocol is installed.This can be used as a dynamic hashing interface by other modules.
- Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
- Security - Does the change have a direct security impact on an application,
flow, or firmware? - Examples: Crypto algorithm change, buffer overflow fix, parameter
validation improvement, ...
- Security - Does the change have a direct security impact on an application,
- Breaking change?
- Breaking change - Will anyone consuming this change experience a break
in build or boot behavior? - Examples: Add a new library class, move a module to a different repo, call
a function in a new library class in a pre-existing module, ...
- Breaking change - Will anyone consuming this change experience a break
- Includes tests?
- Tests - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
- Documentation - Does the change contain explicit documentation additions
outside direct code modifications (and comments)? - Examples: Update readme file, add feature readme file, link to documentation
on an a separate Web page, ...
- Documentation - Does the change contain explicit documentation additions
How This Was Tested
Verified Hash 2 Service Binding protocol is installed by MuCryptoDxe.
Integration Instructions
N/A
- Impacts functionality?
🚀 Features & ✨ Enhancements
-
Add RT DXE Shared Crypto @makubacki (#855)
Change Details
## Description
- Updates QemuQ35Pkg to use the RT DXE shared crypto driver and use
the RuntimeDxeCryptLib instance for RT DXE drivers. - Removes a binary VariableRuntimeDxe EFI image checked in (with
crypto statically linked) that was an intermediate solution while
RT DXE shared crypto was developed. - Updates paths that refer to shared crypto use the build variable
SHARED_CRYPTO_PATH
that is set by the ext dep. This allows the
path to resolve to the ext dep regardless of where it is placed
in the code tree. - 960ebde updated QemuQ35Pkg to resolve DSC parser warnings for a
suspicious expression comparison warning. This change also fixes
the warning for QemuSbsaPkg.
Updates some Mu submodules to their latest releases. The MU_BASECORE
update is required for these changes.- MU_BASECORE: v2023110001.0.1 (76b62eb)
- CryptoPkg/RuntimeDxeCryptLib: Make globals static
- BaseTools/GenFds: Resolve absolute workspace INF paths
- MU_BASECORE: v2023110001.0.0 (0dd0d48)
- CryptoPkg/Driver: Remove directory
- .pytool/Plugin/DscCompleteCheck: Allow git ignore syntax
- pip: update edk2-pytool-library requirement from ~=0.21.2 to ~=0.21.3
- CryptoPkg: Add RT DXE shared crypto library instance
- Remove static initialization of gMmst for MM Core Lib
- Repo File Sync: Improve inline documentation in CodeQL workflow
- pip: update edk2-pytool-library requirement from ~=0.20.0 to ~=0.21.2
- Repo File Sync: synced file(s) with microsoft/mu_devops
- Common/MU: v2023110000.0.1 (c3b9b01)
- pip: bump edk2-pytool-library from 0.21.2 to 0.21.3
- remove edk2-basetools
- Remove AdvancedLogger MmCoreArm dependence on global variables.
- Switch MmCoreArm advanced logger to use updated MMU functions
- Repo File Sync: Improve inline documentation in CodeQL workflow
- pip: bump edk2-pytool-library from 0.20.0 to 0.21.2
- Repo File Sync: synced file(s) with microsoft/mu_devops
- Common/MU_TIANO: v2023110000.0.2 (f7e2628)
- pip: bump edk2-pytool-library from 0.21.2 to 0.21.3
- remove edk2-basetools
- Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
- Security - Does the change have a direct security impact on an application,
flow, or firmware? - Examples: Crypto algorithm change, buffer overflow fix, parameter
validation improvement, ...
- Security - Does the change have a direct security impact on an application,
- Breaking change?
- Breaking change - Will anyone consuming this change experience a break
in build or boot behavior? - Examples: Add a new library class, move a module to a different repo, call
a function in a new library class in a pre-existing module, ...
- Breaking change - Will anyone consuming this change experience a break
- Includes tests?
- Tests - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
- Documentation - Does the change contain explicit documentation additions
outside direct code modifications (and comments)? - Examples: Update readme file, add feature readme file, link to documentation
on an a separate Web page, ...
- Documentation - Does the change contain explicit documentation additions
How This Was Tested
- QemuQ35Pkg SMM and SMM_DISABLED build and boot to EFI shell and Windows OS
- QemuSbsaPkg boot to EFI shell
Integration Instructions
N/A - Affects crypto used in this repo.
- Updates QemuQ35Pkg to use the RT DXE shared crypto driver and use
🔐 Security Impacting
-
Add RT DXE Shared Crypto @makubacki (#855)
Change Details
## Description
- Updates QemuQ35Pkg to use the RT DXE shared crypto driver and use
the RuntimeDxeCryptLib instance for RT DXE drivers. - Removes a binary VariableRuntimeDxe EFI image checked in (with
crypto statically linked) that was an intermediate solution while
RT DXE shared crypto was developed. - Updates paths that refer to shared crypto use the build variable
SHARED_CRYPTO_PATH
that is set by the ext dep. This allows the
path to resolve to the ext dep regardless of where it is placed
in the code tree. - 960ebde updated QemuQ35Pkg to resolve DSC parser warnings for a
suspicious expression comparison warning. This change also fixes
the warning for QemuSbsaPkg.
Updates some Mu submodules to their latest releases. The MU_BASECORE
update is required for these changes.- MU_BASECORE: v2023110001.0.1 (76b62eb)
- CryptoPkg/RuntimeDxeCryptLib: Make globals static
- BaseTools/GenFds: Resolve absolute workspace INF paths
- **...
- Updates QemuQ35Pkg to use the RT DXE shared crypto driver and use
v5.0.0
What's Changed
📢 This release moves to Mu 202311 branches.
-
QemuQ35Pkg: Define SMM\_CRYPTO\_ARCH @Javagedes (#840)
Change Details
## Description
defines SMM_CRYPTO_ARCH in QemuQ35Pkg.dsc to resolve parser warnings regarding suspicious expressions that occur because $(SMM_CRYPTO_ARCH) is not replaced with a value (because a value is not defined).
Prints multiple of the following parser warning:
INFO - Parser... INFO - c:\src\mu_tiano_platforms\MU_BASECORE\CryptoPkg\Driver\Bin\Crypto.pcd.TINY_SHA.inc.dsc(112): warning: Suspicious expression: == Comparison between Operand of string type and Boolean/Number Type always return False. INFO - !if $(SMM_CRYPTO_ARCH) == X64
- Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
- Security - Does the change have a direct security impact on an application,
flow, or firmware? - Examples: Crypto algorithm change, buffer overflow fix, parameter
validation improvement, ...
- Security - Does the change have a direct security impact on an application,
- Breaking change?
- Breaking change - Will anyone consuming this change experience a break
in build or boot behavior? - Examples: Add a new library class, move a module to a different repo, call
a function in a new library class in a pre-existing module, ...
- Breaking change - Will anyone consuming this change experience a break
- Includes tests?
- Tests - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
- Documentation - Does the change contain explicit documentation additions
outside direct code modifications (and comments)? - Examples: Update readme file, add feature readme file, link to documentation
on an a separate Web page, ...
- Documentation - Does the change contain explicit documentation additions
How This Was Tested
Built with and without SMM_CRYPTO_ARCH being defined, and verified the parser warning was removed when it was defined.
Integration Instructions
N/A
- Impacts functionality?
-
Update pytool dependency @Javagedes (#827)
Change Details
## Description
Updates edk2-pytool-extensions to v0.27.0 and edk2-pytool-library to v0.20.0, which moves Edk2DB away from using sqlite3 directly, instead using a ORM to manage the database schema and querying functionlity. Applies the necessary changes to convert Edk2DB querying from raw SQL queries to sqlalchemy (ORM) queries.
- Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
- Security - Does the change have a direct security impact on an application,
flow, or firmware? - Examples: Crypto algorithm change, buffer overflow fix, parameter
validation improvement, ...
- Security - Does the change have a direct security impact on an application,
- Breaking change?
- Breaking change - Will anyone consuming this change experience a break
in build or boot behavior? - Examples: Add a new library class, move a module to a different repo, call
a function in a new library class in a pre-existing module, ...
- Breaking change - Will anyone consuming this change experience a break
- Includes tests?
- Tests - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
- Documentation - Does the change contain explicit documentation additions
outside direct code modifications (and comments)? - Examples: Update readme file, add feature readme file, link to documentation
on an a separate Web page, ...
- Documentation - Does the change contain explicit documentation additions
How This Was Tested
PlatformTest for QemuQ35Pkg and QemuSbsaPkg continues to work, and produces the same information.
Integration Instructions
N/A
- Impacts functionality?
-
Refresh Paging Audit Test App CI Exemption @TaylorBeebe (#821)
Change Details
## Description
The DXE paging audit test app was updated to check for Enhanced Memory Protection compliance. Project Mu is currently being updated to pass to the currently failing checks. This PR updates the exemption date for SBSA and Q35 so test failures don't block CI gates.
- Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
- Security - Does the change have a direct security impact on an application,
flow, or firmware? - Examples: Crypto algorithm change, buffer overflow fix, parameter
validation improvement, ...
- Security - Does the change have a direct security impact on an application,
- Breaking change?
- Breaking change - Will anyone consuming this change experience a break
in build or boot behavior? - Examples: Add a new library class, move a module to a different repo, call
a function in a new library class in a pre-existing module, ...
- Breaking change - Will anyone consuming this change experience a break
- Includes tests?
- Tests - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
- Documentation - Does the change contain explicit documentation additions
outside direct code modifications (and comments)? - Examples: Update readme file, add feature readme file, link to documentation
on an a separate Web page, ...
- Documentation - Does the change contain explicit documentation additions
How This Was Tested
Tested in pipelines
Integration Instructions
N/A
- Impacts functionality?
-
.git-blame-ignore-revs: Ignore Line Ending and Uncrustify only commits @makubacki (#819)
Change Details
## Description
Adds commits that only applied Uncrustify formatting or converted
line endings to a .git-blame-ignore-revs file so they are ignored
by git blame. This is supported by GitHub:
https://github.blog/changelog/2022-03-24-ignore-commits-in-the-blame-view-beta/This helps clean up git blame by filtering out these changes.
Note: This file needs to be updated on rebase branches. Processes
like filter-branch can automatically update relevant SHAs.
Commits cover
OvmfPkg
. Although the package no longer exists, it is still in
the history of many files in derived packages.- Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
- Security - Does the change have a direct security impact on an application,
flow, or firmware? - Examples: Crypto algorithm change, buffer overflow fix, parameter
validation improvement, ...
- Security - Does the change have a direct security impact on an application,
- Breaking change?
- Breaking change - Will anyone consuming this change experience a break
in build or boot behavior? - Examples: Add a new library class, move a module to a different repo, call
a function in a new library class in a pre-existing module, ...
- Breaking change - Will anyone consuming this change experience a break
- Includes tests?
- Tests - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
- Documentation - Does the change contain explicit documentation additions
outside direct code modifications (and comments)? - Examples: Update readme file, add feature readme file, link to documentation
on an a separate Web page, ...
- Documentation - Does the change contain explicit documentation additions
How This Was Tested
git blame
Integration Instructions
N/A
- Impacts functionality?
⚠️ Breaking Changes
-
Integrate 202311 release branches @kuqin12 (#809)
Change Details
## Description
This change updates all submodules to point to 202311 based MU submodules.
Code change specifically applicable to QEMU Q35:
tianocore/edk2@dea6002
tianocore/edk2@24e6daa
tianocore/edk2@12d3d60Specifically, the submodules are updated to:
Submodule Version MU_BASECORE v2023110000.0.1 MU_PLUS v2023110000.0.0 MU_OEM_SAMPLE v2023110000.0.0 MU_TIANO_PLUS v2023110000.0.0 MM_SUPV v9.0.0 MU_SILICON_ARM v2023110000.0.0 - Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
- Security - Does the change have a direct security impact on an application,
flow, or firmware? - Examples: Crypto algorithm change, buffer overflow fix, parameter
validation improvement, ...
- Security - Does the change have a direct security impact on an application,
- Breaking change?
- Breaking change - Will anyone consuming this change experience a break
in build or boot behavior? - Examples: Add a new library class, move a module to a different repo, call
a function in a new library class in a pre-existing module, ...
- Breaking change - Will anyone consuming this change experience a break
- Includes tests?
- Tests - Does the change...
- Impacts functionality?
v4.7.3
What's Changed
-
iasl external dependency update @Javagedes (#812)
Change Details
## Description
Updates the iasl external dependency to 20230628.0.1 for both QemuQ35Pkg and QemuSbsaPkg.
- Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
- Security - Does the change have a direct security impact on an application,
flow, or firmware? - Examples: Crypto algorithm change, buffer overflow fix, parameter
validation improvement, ...
- Security - Does the change have a direct security impact on an application,
- Breaking change?
- Breaking change - Will anyone consuming this change experience a break
in build or boot behavior? - Examples: Add a new library class, move a module to a different repo, call
a function in a new library class in a pre-existing module, ...
- Breaking change - Will anyone consuming this change experience a break
- Includes tests?
- Tests - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
- Documentation - Does the change contain explicit documentation additions
outside direct code modifications (and comments)? - Examples: Update readme file, add feature readme file, link to documentation
on an a separate Web page, ...
- Documentation - Does the change contain explicit documentation additions
How This Was Tested
CI Pipelines
Integration Instructions
N/A
- Impacts functionality?
-
Add Advanced logger for Non DXE phases @kuqin12 (#801)
Change Details
## Description
This change introduces non DXE advanced logger, which should enable us to verify the advanced logger related changes better. Resolves #522.
- Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
- Security - Does the change have a direct security impact on an application,
flow, or firmware? - Examples: Crypto algorithm change, buffer overflow fix, parameter
validation improvement, ...
- Security - Does the change have a direct security impact on an application,
- Breaking change?
- Breaking change - Will anyone consuming this change experience a break
in build or boot behavior? - Examples: Add a new library class, move a module to a different repo, call
a function in a new library class in a pre-existing module, ...
- Breaking change - Will anyone consuming this change experience a break
- Includes tests?
- Tests - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
- Documentation - Does the change contain explicit documentation additions
outside direct code modifications (and comments)? - Examples: Update readme file, add feature readme file, link to documentation
on an a separate Web page, ...
- Documentation - Does the change contain explicit documentation additions
How This Was Tested
This change was tested on both QEMU Q35 and SBSA packages and verified bootable to UEFI shell.
Integration Instructions
N/A
- Impacts functionality?
-
Build-UefiExt.yml: Bump actions/upload-artifact from 3 to 4 @makubacki (#808)
Change Details
## Description
Bumps actions/upload-artifact from 3 to 4.
Release notes
Sourced from actions/upload-artifact's releases.
v4.0.0
What's Changed
The release of upload-artifact@v4 and download-artifact@v4 are major changes to the backend architecture of Artifacts. They have numerous performance and behavioral improvements.
For more information, see the
@actions/artifact
documentation.New Contributors
@vmjoseph
made their first contribution in actions/upload-artifact#464
Full Changelog: actions/upload-artifact@v3...v4.0.0
v3.1.3
What's Changed
- chore(github): remove trailing whitespaces by
@ljmf00
in actions/upload-artifact#313 - Bump
@actions/artifact
version to v1.1.2 by@bethanyj28
in actions/upload-artifact#436
Full Changelog: actions/upload-artifact@v3...v3.1.3
v3.1.2
- Update all
@actions/*
NPM packages to their latest versions- #374 - Update all dev dependencies to their most recent versions - #375
v3.1.1
- Update actions/core package to latest version to remove
set-output
deprecation warning #351
v3.1.0
What's Changed
- Bump
@actions/artifact
to v1.1.0 (actions/upload-artifact#327)- Adds checksum headers on artifact upload (actions/toolkit#1095) (actions/toolkit#1063)
Commits
c7d193f
Merge pull request #466 from actions/v4-beta13131bb
licensed cache4a6c273
Merge branch 'main' into v4-betaf391bb9
Merge pull request #465 from actions/robherley/v4-documentation9653d03
Apply suggestions from code review875b630
add limitations sectionecb2146
add compression example5e7604f
trim some repeated infod6437d0
naming1b56155
s/v4-beta/v4/g- Additional commits viewable in compare view
- Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
- Security - Does the change have a direct security impact on an application,
flow, or firmware? - Examples: Crypto algorithm change, buffer overflow fix, parameter
validation improvement, ...
- Security - Does the change have a direct security impact on an application,
- Breaking change?
- Breaking change - Will anyone consuming this change experience a break
in build or boot behavior? - Examples: Add a new library class, move a module to a different repo, call
a function in a new library class in a pre-existing module, ...
- Breaking change - Will anyone consuming this change experience a break
- Includes tests?
- Tests - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
- Documentation - Does the change contain explicit documentation additions
outside direct code modifications (and comments)? - Examples: Update readme file, add feature readme file, link to documentation
on an a separate Web page, ...
- Documentation - Does the change contain explicit documentation additions
How This Was Tested
CI
Integration Instructions
N/A - Local repo workflow
Note: Peeled off from #804 since
the usage of the action in CodeQL workflows falls under its breaking change and ...
v4.7.2
What's Changed
-
Pull mu\_plus, Run DxeMemoryProtectionTestApp in SBSA CI pipelines @TaylorBeebe (#794)
Change Details
# Description
A recent mu_plus commit splits MemoryProtectionTestApp into SMM and DXE versions. Now that they are split, we can run the DXE version of the test on SBSA. This PR adds the new test instances and adds the DXE test to the SBSA CI pipelines.
- Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
- Security - Does the change have a direct security impact on an application,
flow, or firmware? - Examples: Crypto algorithm change, buffer overflow fix, parameter
validation improvement, ...
- Security - Does the change have a direct security impact on an application,
- Breaking change?
- Breaking change - Will anyone consuming this change experience a break
in build or boot behavior? - Examples: Add a new library class, move a module to a different repo, call
a function in a new library class in a pre-existing module, ...
- Breaking change - Will anyone consuming this change experience a break
- Includes tests?
- Tests - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
- Documentation - Does the change contain explicit documentation additions
outside direct code modifications (and comments)? - Examples: Update readme file, add feature readme file, link to documentation
on an a separate Web page, ...
- Documentation - Does the change contain explicit documentation additions
How This Was Tested
Tested in pipelines
Integration Instructions
N/A
- Impacts functionality?
-
Minor Platform cleanup @Javagedes (#792)
Change Details
## Description
Resolves syntax warnings in each platform's PlatformBuild.py, which was introduced in python 3.12, responsible for catching invalid escape sequences.
Additionally updates the conditional for including VsIntrinsicLib.inf when building with VS build tools. It uses the macro $(FAMILY), which contains a list families that are being built (Intel, MSFT, GCC, etc). As seen in tools_def.txt, the family is set to MSFT when building with any of the non-EBC Visual studio toolchains. This prevents the need to update this conditional every time a new Visual Studio compiler is introduced.
- Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
- Security - Does the change have a direct security impact on an application,
flow, or firmware? - Examples: Crypto algorithm change, buffer overflow fix, parameter
validation improvement, ...
- Security - Does the change have a direct security impact on an application,
- Breaking change?
- Breaking change - Will anyone consuming this change experience a break
in build or boot behavior? - Examples: Add a new library class, move a module to a different repo, call
a function in a new library class in a pre-existing module, ...
- Breaking change - Will anyone consuming this change experience a break
- Includes tests?
- Tests - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
- Documentation - Does the change contain explicit documentation additions
outside direct code modifications (and comments)? - Examples: Update readme file, add feature readme file, link to documentation
on an a separate Web page, ...
- Documentation - Does the change contain explicit documentation additions
How This Was Tested
- Verified syntax warnings dissapeared when building with both platforms
- Verified VsIntrinsicLib is compiled when building with QemuQ35Pkg and
BLD_*_ENABLE_SHARED_CRYPTO=FALSE
Integration Instructions
N/A
- Impacts functionality?
🔐 Security Impacting
-
Use secureboot binary blob external dependency @Javagedes (#790)
Change Details
## Description
Use secureboot binary blobs generated from
https://github.com/microsoft/secureboot_objects for the PK, KeK, Db, Dbx, and 3PDb. The secureboot binary blobs are downloaded as an external dependency, which enables the contents of the secureboot variables to be strongly versioned and easily tracked.This change uses a new version of SecureBootKeyStoreLib (from MsCorePkg), which consumes the secureboob binary values from PCDs and a new helper plugin (BuildSecurebootPcds) generates these PCDs on each build.
- Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
- Security - Does the change have a direct security impact on an application,
flow, or firmware? - Examples: Crypto algorithm change, buffer overflow fix, parameter
validation improvement, ...
- Security - Does the change have a direct security impact on an application,
- Breaking change?
- Breaking change - Will anyone consuming this change experience a break
in build or boot behavior? - Examples: Add a new library class, move a module to a different repo, call
a function in a new library class in a pre-existing module, ...
- Breaking change - Will anyone consuming this change experience a break
- Includes tests?
- Tests - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
- Documentation - Does the change contain explicit documentation additions
outside direct code modifications (and comments)? - Examples: Update readme file, add feature readme file, link to documentation
on an a separate Web page, ...
- Documentation - Does the change contain explicit documentation additions
How This Was Tested
Verified QemuPkg and QemuSbsaPkg continue to boot and can have secureboot enabled.
Integration Instructions
N/A
- Impacts functionality?
-
Update All Submodules, Update Package DSC Files to Use New Stack Cookie Library @TaylorBeebe (#784)
Change Details
## Description
All submodules have been updated to top of tree to ingest the stack cookie library transition commits. The packages in this repo were updated to use the new stack cookie library.
- Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
- Security - Does the change have a direct security impact on an application,
flow, or firmware? - Examples: Crypto algorithm change, buffer overflow fix, parameter
validation improvement, ...
- Security - Does the change have a direct security impact on an application,
- Breaking change?
- Breaking change - Will anyone consuming this change experience a break
in build or boot behavior? - Examples: Add a new library class, move a module to a different repo, call
a function in a new library class in a pre-existing module, ...
- Breaking change - Will anyone consuming this change experience a break
- Includes tests?
- Tests - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
- Documentation - Does the change contain explicit documentation additions
outside direct code modifications (and comments)? - Examples: Update readme file, add feature readme file, link to documentation
on an a separate Web page, ...
- Documentation - Does the change contain explicit documentation additions
How This Was Tested
Tested on Q35 and SBSA
Integration Instructions
N/A
- Impacts functionality?
🛠️ Submodule Updates
-
Bump Common/MU from 2023020004.0.3 to 2023020004.0.4 @ProjectMuBot (#797)
-
Bump Features/DFCI from 4.0.2 to 4.0.3 @ProjectMuBot (#793)
Change Details
Bumps Features/DFCI from `4.0.2` to `4.0.3`
Introduces 2 new commits in Features/DFCI.
v4.7.1
What's Changed
-
Add platform host-based unit tests and code coverage @Javagedes (#729)
Change Details
## Description
Adds a
PlatformTest.py
per platform package which:- self verifies the platform host-based unit test dsc is up to date (no new hosted-based test INFs have been added locally or from a submodule that test source used by the platform).
- Compiles the host-based unit tests.
- Executes the host-based unit tests.
- Optionally generates code coverage data.
Adds additional pipeline jobs to run the host-based tests and generate code coverage information.
- Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
- Security - Does the change have a direct security impact on an application,
flow, or firmware? - Examples: Crypto algorithm change, buffer overflow fix, parameter
validation improvement, ...
- Security - Does the change have a direct security impact on an application,
- Breaking change?
- Breaking change - Will anyone consuming this change experience a break
in build or boot behavior? - Examples: Add a new library class, move a module to a different repo, call
a function in a new library class in a pre-existing module, ...
- Breaking change - Will anyone consuming this change experience a break
- Includes tests?
- Tests - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
- Documentation - Does the change contain explicit documentation additions
outside direct code modifications (and comments)? - Examples: Update readme file, add feature readme file, link to documentation
on an a separate Web page, ...
- Documentation - Does the change contain explicit documentation additions
How This Was Tested
CI
Integration Instructions
CI
-
Cargo.toml: Optimize dev profile binary size @makubacki (#767)
Change Details
## Description
By default, the dev profile is used. The default build settings for the dev profile are documented here:
https://doc.rust-lang.org/cargo/reference/profiles.html#devUnmodified dev profile settings result in extraordinarily large binaries relative to UEFI FW. This especially impacts
DEBUG
builds which already have less optimized C code resulting in overall greater space occupation.Without a change, the binaries are simply too large and will continue to push the limits of firmware volumes (on a real system constrained by flash size) over time.
Therefore, the below setting enables optimization level
3
(all optimizations) that is used by the release profile by default. This greatly reduces the overall binary size.[profile.dev.package."*"]
is specified to apply the opt-level for all dependencies (but not a workspace member). This emphasizes debuggability of workspace code but optimizes dependencies. An individual dependency can be overridden by specifying the named package instead of"*"
. For example:[profile.dev.package.foo] opt-level = 0
That will likely allow the overall build to still fit in the FV, since other code is still optimized, but remove optimizations from an individual package that needs to be debugged.
- Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
- Security - Does the change have a direct security impact on an application,
flow, or firmware? - Examples: Crypto algorithm change, buffer overflow fix, parameter
validation improvement, ...
- Security - Does the change have a direct security impact on an application,
- Breaking change?
- Breaking change - Will anyone consuming this change experience a break
in build or boot behavior? - Examples: Add a new library class, move a module to a different repo, call
a function in a new library class in a pre-existing module, ...
- Breaking change - Will anyone consuming this change experience a break
- Includes tests?
- Tests - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
- Documentation - Does the change contain explicit documentation additions
outside direct code modifications (and comments)? - Examples: Update readme file, add feature readme file, link to documentation
on an a separate Web page, ...
- Documentation - Does the change contain explicit documentation additions
How This Was Tested
- Verified build size of several config combinations (including the chosen one).
-
[profile.dev] opt-level = 'z'
- DXE FV: 11643648 (0xb1ab00) used (size opt of all packages)
-
[profile.dev.package."*"] opt-level = 'z'
- DXE FV: 12365056 (0xbcad00) used (size opt of dependencies)
-
[profile.dev.package."*"] opt-level = 3
- DXE FV: 12431104 (0xbdaf00) used (level 3 opt of dependencies)
-
Integration Instructions
N/A - Affects packages built in this workspace
- Impacts functionality?
🐛 Bug Fixes
-
VirtualDriveManager: Fix incremental usage on Linux @makubacki (#780)
Change Details
## Description
Currently,
FlashRomImage()
inPlatformBuild.py
checks if the
virtual drive file (VirtualDrive.img
) exists. If so,make_drive()
is not called which is the only function that currently sets the
MTOOLSRC
environment variable to themtool.conf
file path which
is consumed bymtools
.Typical
mtool.conf
file contents as used inVirtualDriveManager
:drive+ a: file="/w/m/Build/QemuSbsaPkg/DEBUG_GCC5/VirtualDrive.img" exclusive
This means if
VirtualDrive.img
already exists (i.e. on an
incremental Linux build with theVIRTUAL_DRIVE
parameter present),
theMTOOLSRC
variable is not available tomtools
resulting in the
following error:INFO - Can't open /dev/fd0: No such file or directory INFO - Cannot initialize 'A:' INFO - Bad target a:
This change sets
MTOOLSRC
on incremental builds so the existing
virtual drive can be used.
A separate commit also removes trailing whitespace from
VirtualDriveManager.py
since there is a lot throughout the file.
- Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
- Security - Does the change have a direct security impact on an application,
flow, or firmware? - Examples: Crypto algorithm change, buffer overflow fix, parameter
validation improvement, ...
- Security - Does the change have a direct security impact on an application,
- Breaking change?
- Breaking change - Will anyone consuming this change experience a break
in build or boot behavior? - Examples: Add a new library class, move a module to a different repo, call
a function in a new library class in a pre-existing module, ...
- Breaking change - Will anyone consuming this change experience a break
- Includes tests?
- Tests - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
- Documentation - Does the change contain explicit documentation additions
outside direct code modifications (and comments)? - Examples: Update readme file, add feature readme file, link to documentation
on an a separate Web page, ...
- Documentation - Does the change contain explicit documentation additions
How This Was Tested
- With
VIRTUAL_DRIVE
parameter given:- Linux build with VirtualDrive.img missing (clean build)
- Linux build with VirtualDrive.img present (incremental build)
- Previously failed
- Linux build with VirtualDrive.img present and mtool.conf missing
- Unexpected state but possible
Integration Instructions
N/A
- Impacts functionality?
🛠️ Submodule Updates
-
Bump Silicon/Arm/MU\_TIANO from 2023020000.1.2 to 2023020000.1.3 @ProjectMuBot (#781)
Change Details
Bumps Silicon/Arm/MU_TIANO from `2023020000.1.2` to `2023020000.1.3`
Introduces 5 new commits in Silicon/Arm/MU_TIANO.
Commits