Releases: microsoft/mu_tiano_platforms
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
- fb39b5 GitHub Action: Bump actions/github-script from 6 to 7 (#180)
- 4ece5b Repo File Sync: synced file(s) with microsoft/mu_devops (#177)
- fa3856 Integration steps for [email protected]: Add Code coverage (#181)
- f58b70 ArmPkg/Drivers/CpuDxe: Use lower and upper attributes
- e42172 ArmPkg/Drivers/CpuD...
v4.7.0
What's Changed
-
QemuRunner.py: Allow a user specified QEMU path @makubacki (#762)
Change Details
## Description
On Linux, I build QEMU images with various features enabled. To more
easily enable users to use a custom QEMU image, this change
introduces a new variableQEMU_PATH
that will override the default
executable used from the system path if provided.- 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 packages with
QEMU_PATH
present and not present.
Integration Instructions
N/A - Instructions for usage are in Platforms/Docs/Common/building.md
- Impacts functionality?
🚀 Features & ✨ Enhancements
-
Add TPM Replay FW CFG Input Channel library instance @makubacki (#761)
Change Details
## Description
Adds a new library instance for QEMU platforms that allows a TPM
Replay event log to optionally be passed from the QEMU command
line.See https://github.com/microsoft/mu_plus/tree/HEAD/TpmTestingPkg/TpmReplayPei#input-channel-fw_cfg
for more information about passing a TPM Replay log through the
FW CFG interface.For reference, this readme has additional TPM Replay 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
- Passed FW CFG TPM event log through QemuQ35Pkg
- Verified library integrated without a log being passed uses
lower priority input channels as expected
Integration Instructions
N/A - The new input channel library instance for TPM Replay is integrated
in this change.
- Impacts functionality?
🛠️ Submodule Updates
-
Bump Common/MU\_TIANO from 2023020000.1.0 to 2023020000.1.1 @ProjectMuBot (#755)
Change Details
Bumps Common/MU_TIANO from `2023020000.1.0` to `2023020000.1.1`
Introduces 18 new commits in Common/MU_TIANO.
Commits
- 0d2455 GitHub Action: Bump actions/checkout from 3 to 4 (#176)
- 38869d pip: bump antlr4-python3-runtime from 4.13.0 to 4.13.1 (#178)
- d31ae9 pip: bump edk2-pytool-extensions from 0.24.0 to 0.24.1 (#180)
- 497efb Repo File Sync: Update CodeQL GitHub workflow (#181)
- 6153ca pip: bump edk2-pytool-library from 0.17.0 to 0.18.0 (#182)
- d5bc5d Repo File Sync: Add cargo ecosystem to dependabot config (#183)
- ab1a6a Repo File Sync: Update to Mu DevOps 6.5.1 (#184)
- 7ab59c pip: bump edk2-pytool-library from 0.18.0 to 0.18.1 (#185)
- 1bd1ad pip: bump edk2-pytool-library from 0.18.1 to 0.18.2 (#187)
- d7158f pip: bump regex from 2023.8.8 to 2023.10.3 (#186)
- 94f914 pip: bump edk2-pytool-library from 0.18.2 to 0.19.0 (#189)
- b7882a pip: bump edk2-pytool-extensions from 0.24.1 to 0.25.0 (#190)
- 207a4f Repo File Sync: Update to Mu DevOps v7.0.0 (#188)
- ec303c Repo File Sync: Update to Mu DevOps 7.0.1 (#191)
- 5c9676 pip: bump edk2-pytool-library from 0.19.0 to 0.19.1 (#192)
- bc81df pip: bump edk2-pytool-extensions from 0.25.0 to 0.25.1 (#193)
- 3e98f8 Repo File Sync: Include Rust Env Exclusions in CodeQL Workflow (#194)
- 64a814 SecurityPkg: Tcg2Smm: Inspect target address before usage (#195)
Signed-off-by: Project Mu Bot [email protected]
-
Bump MU\_BASECORE from 2023020007.2.0 to 2023020007.2.1 @ProjectMuBot (#754)
Change Details
Bumps MU_BASECORE from `2023020007.2.0` to `2023020007.2.1`
Introduces 2 new commits in MU_BASECORE.
Commits
- 34f18b BinToPcd.py: Update regex ...
v4.6.1
What's Changed
-
Add rust-ci scope to Qemu35Pkg and QemuSbsaPkg @makubacki (#745)
Change Details
## Description
Add this scope so Rust related CI plugins run since the packages are
already building Rust code.- 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 CI builds with the scope set
Integration Instructions
N/A - Affects plugins run in this repo
- Impacts functionality?
🛠️ Submodule Updates
-
Bump Common/MU from 2023020002.1.0 to 2023020003.0.0 @ProjectMuBot (#753)
Change Details
Bumps Common/MU from `2023020002.1.0` to `2023020003.0.0`
Introduces 3 new commits in Common/MU.
Commits
Signed-off-by: Project Mu Bot [email protected]
-
Bump MU\_BASECORE from 2023020007.1.3 to 2023020007.2.0 @ProjectMuBot (#752)
Change Details
Bumps MU_BASECORE from `2023020007.1.3` to `2023020007.2.0`
Introduces 4 new commits in MU_BASECORE.
Commits
- 963f6b BaseTools/Plugin: Add Rust Environment Check build plugin (#600)
- aec07a pip: update edk2-pytool-extensions requirement from ~=0.25.0 to ~=0.25.1 (#601)
- 135f26 BaseTools/Plugin: Add tool exclusion to RustEnvironmentCheck (#602)
- 6f4fd1 Repo File Sync: Include Rust Env Exclusions in CodeQL Workflow (#603)
Signed-off-by: Project Mu Bot [email protected]
-
Bump MU\_BASECORE from 2023020007.1.2 to 2023020007.1.3 [Rebase \& FF] @ProjectMuBot (#749)
Change Details
Bumps MU_BASECORE from `2023020007.1.2` to `2023020007.1.3`
Introduces 2 new commits in MU_BASECORE.
Signed-off-by: Project Mu Bot [email protected]
Full Changelog: v4.6.0...v4.6.1
v4.6.0
What's Changed
Note: Mouse support on Q35 was found to be broken (based on local testing) for
a while, covering at least several releases. It is verified to be functional in this release
(using the Rust based HID driver stack).
🚀 Features & ✨ Enhancements
-
QemuQ35Pkg: Update memory type information defaults [Rebase \& FF] @makubacki (#739)
Change Details
## Description
QemuQ35Pkg: Update memory type information defaults
Updates the default values for
PcdMemoryTypeEfiACPIReclaimMemory
andPcdMemoryTypeEfiReservedMemoryType
to prevent a runtime
adjustment to the memory bucket sizes.Based on the values calculated including buffer:
Memory Previous Current Minimum Next Type Pages Pages Pages Pages ====== ======== ======== ======== ======= 0A 00000080 00000026 00000000 00000080 09 00000010 00000012 00000000 00000016* 00 00000080 0000040D 00000000 00000510* 05 00000100 000000AF 00000000 00000100 06 00000100 00000100 00000000 00000100 Memory Type Information settings 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
- QemuQ35Pkg build and boot
Integration Instructions
N/A
- Impacts functionality?
-
Integrate Rust HID driver @makubacki (#738)
Change Details
## Description
Per integration instructions in microsoft/mu_plus#324,
UsbMouseAbsolutePointerDxe
is removed andUsbHidDxe
andUefiHidDxe
are
added to the build.The absolute pointer protocol will now be installed by the
AbsolutePointer
crate inHidPkg
linked against theUefiHidDxe
module.- 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 QemuQ35Pkg and QemuSbsaPkg build and boot to EFI shell
Integration Instructions
N/A
- Impacts functionality?
📖 Documentation Updates
-
Docs/Common/Featues: Add Front Page Instructions @makubacki (#742)
Change Details
## Description
Since there's a couple build variables that can influence which front
page is built and how it is loaded, this change updates the currently
empty front page feature document to include the relevant build
variable 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 build including markdownlint.
Integration Instructions
N/A
- Impacts functionality?
🛠️ Submodule Updates
-
Bump Features/CONFIG from 2.0.5 to 2.0.6 @ProjectMuBot (#747)
Change Details
Bumps Features/CONFIG from `2.0.5` to `2.0.6`
Introduces 6 new commits in Features/CONFIG.
Commits
- 392d21 pip: bump edk2-pytool-library from 0.18.2 to 0.19.0 (#261)
- 1f6d76 pip: bump edk2-pytool-extensions from 0.24.1 to 0.25.0 (#262)
- 04e6f1 Repo File Sync: Update to Mu DevOps v7.0.0 (#260)
- d40247 Add the default in switch implementation to prevent gcc build error (#263)
- c91a9f Repo File Sync: Update to Mu DevOps 7.0.1 (#264)
- decdc3 pip: bump edk2-pytool-library from 0.19.0 to 0.19.1 (#265)
Signed-off-by: Project Mu Bot [email protected]
-
Bump MU\_BASECORE from 2023020007.1.1 to 2023020007.1.2 @ProjectMuBot (#746)
Change Details
Bumps MU_BASECORE from `2023020007.1.1` to `2023020007.1.2`
Introduces 1 new commits in MU_BASECORE.
Commits
Signed-off-by: Project Mu Bot [email protected]
-
Bump Common/MU from 2023020002.0.4 to 2023020002.1.0 @ProjectMuBot (#744)
v4.5.3
What's Changed
-
Fixing multiple build instances usage on Linux environment @kuqin12 (#718)
Change Details
## Description
Current script will try to update the mcopy configuration file. After QEMU run, the build script will then try to open the virtual disk indicated in this configuration. When there are multiple building instances on the same Linux system, we could end up with various conflicts, either opening up the incorrect image file, or opened up a file from other build jobs.
This change attempts to fix it by initiating a configuration file for each build for reference and update the environment variable to set up the configuration.
- 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 both selfhost agents internal and here on the public pipeline builds.
Integration Instructions
N/A.
- Impacts functionality?
-
Fixing selfhosted agent on AARCH64 systems @kuqin12 (#710)
Change Details
# Preface
Please ensure you have read the contribution docs prior
to submitting the pull request. In particular,
pull request guidelines.Description
There has been build failures observed on selfhosted pipelines running on AARCH64 systems. It was due to the rust setup we recently added.
The failure on the surface was because the build process will try to install x86_64 toolchain on AARCH64 systems. This change will remove the extra steps for selfhosted agent runs as those environments should be preset properly.
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 on both internal and external pipelines.
Integration Instructions
N/A
- Impacts functionality?
🛠️ Submodule Updates
-
Bump Common/MU from 2023020001.5.1 to 2023020001.5.2 @ProjectMuBot (#725)
Change Details
Bumps Common/MU from `2023020001.5.1` to `2023020001.5.2`
Introduces 4 new commits in Common/MU.
Commits
Signed-off-by: Project Mu Bot [email protected]
-
Bump Features/CONFIG from 2.0.3 to 2.0.5 @ProjectMuBot (#726)
Change Details
Bumps Features/CONFIG from `2.0.3` to `2.0.5`
Introduces 4 new commits in Features/CONFIG.
Commits
Signed-off-by: Project Mu Bot [email protected]
-
Bump MU\_BASECORE from 2023020006.3.1 to 2023020007.0.0 @ProjectMuBot (#728)
Change Details
Bumps MU_BASECORE from `2023020006.3.1` to `2023020007.0.0`
Introduces 3 new commits in MU_BASECORE.
Commits
Signed-off-by: Project Mu Bot [email protected]
-
Bump Features/CONFIG from 2.0.2 to 2.0.3 @ProjectMuBot (#720)
Change Details
Bumps Features/CONFIG from `2.0.2` to `2.0.3`
Introduces 3 new commits in Features/CONFIG.
v4.5.2
What's Changed
-
Update MU\_BASECORE, Remove VariablePolicyFuncTestApp Test Exemption @TaylorBeebe (#708)
Change Details
## Description
VariablePolicyFuncTestApp now passes on Q35 and SBSA.
- 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 the CI pipelines
Integration Instructions
N/A
- Impacts functionality?
🛠️ Submodule Updates
-
Bump MU\_BASECORE from 2023020006.2.1 to 2023020006.2.2 @ProjectMuBot (#704)
Change Details
Bumps MU_BASECORE from `2023020006.2.1` to `2023020006.2.2`
Introduces 1 new commits in MU_BASECORE.
Signed-off-by: Project Mu Bot [email protected]
Full Changelog: v4.5.1...v4.5.2
v4.5.1
What's Changed
-
Clean-up Q35 and Sbsa PlatformBuild.py @antklein (#702)
Change Details
## Description
- Update Sbsa PlatformBuild.py
- Pull in changes from Q35 PlatformBuild.py
- Remove redundant code
- Update import order and function comments in Q35 package.
- 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
- Validated the Sbsa package builds and boots to UEFI shell.
Integration Instructions
N/A
- Update Sbsa PlatformBuild.py
🐛 Bug Fixes
-
QemuQ35Pkg/PlatformBuild.py: Make workspace root stable @makubacki (#705)
Change Details
## Description
The root is currently determined using
cwd()
which can cause the
root to be relative to the directory where the stuart command is
invoked from. It should always return the same absolute path so
cwd()
is removed.- 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 build from the root directory and subdirectories.
Integration Instructions
N/A
- Impacts functionality?
🛠️ Submodule Updates
-
Bump MU\_BASECORE from 2023020006.1.1 to 2023020006.2.1 @ProjectMuBot (#703)
Change Details
Bumps MU_BASECORE from `2023020006.1.1` to `2023020006.2.1`
Introduces 9 new commits in MU_BASECORE.
Commits
- 4996fa PolicyServicePkg/PolicyLib.h: Add missing include guard (#556)
- d29ec9 [CHERRY-PICK] MdePkg/Library/BaseRngLib: Fix include guard
- eacdde [CHERRY-PICK] MdePkg/Library/TdxLib: Remove unnecessary comparison
- 776244 [CHERRY-PICK] ShellPkg/UefiShellNetwork2CommandsLib: Check array index before access
- d73eb1 [CHERRY-PICK] MdeModulePkg/BootMaintenanceManagerUiLib: Check array index before access
- ec8d17 Enable new CodeQL queries (17 total)
- dc6a46 pip: update edk2-pytool-extensions requirement from ~=0.24.0 to ~=0.24.1 (#563)
- 205d4e Fix Redefined Callback (#566)
- b8d178 Add support for initializing Max Payload Size during PCIe enumeration (#562)
Signed-off-by: Project Mu Bot [email protected]
-
Bump MU\_BASECORE from 2023020006.1.0 to 2023020006.1.1 @ProjectMuBot (#699)
Change Details
Bumps MU_BASECORE from `2023020006.1.0` to `2023020006.1.1`
Introduces 5 new commits in MU_BASECORE.
Commits
- 1b5101 MdeModulePkg/VariablePolicyLib: Use wildcard character constant (#554)
- a431ad RepoDetails.md: Fix markdownlint errors
- 3b65a2 Move Rust documentation to Project Mu repo
- 4e2717 GitHub Action: Bump actions/checkout from 3 to 4 (#551)
- c4bdfe pip: bump antlr4-python3-runtime from 4.13.0 to 4.13.1 (#553)
Signed-off-by: Project Mu Bot [email protected]
Full Changelog: v4.5.0...v4.5.1
v4.5.0
What's Changed
🚀 Features & ✨ Enhancements
-
Add CodeQL Filtering and GitHub Workflow Support [Rebase \& FF] @makubacki (#692)
Change Details
## Description
CodeQL was previously enabled in the repo to the point that it could
be run locally with the--codeql
flag. It was not enabled in CI
because the pre-existing CodeQL GitHub workflow did not support platform
builds.This change hooks
PlatformBuild.py
into the newerstuart_codeql
helper
functionality, adds proper filtering support, and a platform workflow that
allows CodeQL to run in this repo on every PR.Running CodeQL at a "platform" level is advantageous because it can catch
similar CodeQL violations found when building physical platform code.Note:
codeql-platform.yml
is directly checked into the repo here as it has
been tested and it is more clearly explained attached to this PR. In the
future, it will be synced from mu_devops.
There is some similarity with the pre-existing CodeQL CI workflow but those
are relatively simple tasks not expected to change much and may be converged
in the future but that is not a goal right now.Note: CodeQL is only enabled for
QemuQ35Pkg
as the CodeQL extractor fails
on Linux for edk2 style builds andQemuSbsaPkg
does not build on Windows/
Visual Studio at this time.
pip: bump edk2-pytool-extensions from 0.24.0 to 0.24.1
Includes the
edk2toolext.codeql
functions needed in upcoming
changes.
QemuQ35Pkg/PlatformBuild.py: Add CodeQL filtering support
Makes a number of adjustments in PlatformBuild.py as outlined below.
The main improvement is adding support to recursively gather CodeQL
filter files within the repo.- Remove unused imports at the top of the file.
- Use the CodeQL functions newly added to
edk2-pytool-extensions
. - Replace local functionality with common implementation in the
codeql
module. - Remove trailing whitespace throughout the file.
Add CodeQL platform GitHub workflow
Adds a new GitHub workflow that allows CodeQL to run against platform
builds. Previously, only a "CI" CodeQL workflow existed that did not
support platform builders.This file is being added directly to the repo as it is paired with
other changes that it has been tested alongside. In the future, it
will automatically be synced from mu_devops.Nothing about the file is specific to mu_tiano_platforms or any
particular platform. It works by discovering all buildable platforms
in a repo before any dependencies are cloned and then verifying
the build files in the platform package directory support platform
build. If they do, it is checked if they support CodeQL. Only
platforms that meet all of these conditions are actually built via
a dynamic platform package matrix.This allows the workflow to scale across platform repos and
automatically pick up new platforms as they onboard support for
CodeQL.
- 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
- Ran the
QemuQ35Pkg
CodeQL build locally - Ran the
CodeQL - Platform
GitHub workflow- Verified successful detection and build of
QemuQ35Pkg
- Verified successful detection and build of
Integration Instructions
Moving forward, it is recommended to run CodeQL locally when making C source
code changes inQemuQ35Pkg
. Also, CodeQL success will become a required
status check in mu_tiano_platforms CI forQemuQ35Pkg
. See the following
CodeQL plugin documentation for more info.
🛠️ Submodule Updates
-
Bump Common/MU\_TIANO from 2023020000.0.4 to 2023020000.1.0 @ProjectMuBot (#697)
Change Details
Bumps Common/MU_TIANO from `2023020000.0.4` to `2023020000.1.0`
Introduces 2 new commits in Common/MU_TIANO.
Commits
Signed-off-by: Project Mu Bot [email protected]
-
Bump Common/MU from 2023020001.4.1 to 2023020001.5.0 @ProjectMuBot (#698)
Change Details
Bumps Common/MU from `2023020001.4.1` to `2023020001.5.0`
Introduces 2 new commits in Common/MU.
Commits
Signed-off-by: Project Mu Bot [email protected]
-
Bump MU\_BASECORE from 2023020006.0.0 to 2023020006.1.0 @ProjectMuBot (#696)
Change Details
Bumps MU_BASECORE from `2023020006.0.0` to `2023020006.1.0`
Introduces 1 new commits in MU_BASECORE.
Signed-off-by: Project Mu Bot [email protected]
Full Changelog: v4.4.1...v4.5.0
v4.4.1
What's Changed
-
Remove Unused Environment Variables @os-d (#695)
Change Details
## Description
There are several errors produced when building QemuQ35Pkg and QemuSbsaPkg indicating that some relative paths cannot be converted to absolute paths. This is because these paths do not exist in the code tree anymore.
This patch removes the unused env vars.
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
Still builds without these.
Integration Instructions
N/A.
- Impacts functionality?
🐛 Bug Fixes
-
QemuQ35Pkg/SmmAccess: Add missing include guard @makubacki (#691)
Change Details
## Description
All header files should have include guards.
See the following for more info:
https://codeql.github.com/codeql-query-help/cpp/cpp-missing-header-guard/- 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 build
- Ran CodeQL with
cpp-missing-header-guard
enabled
Integration Instructions
N/A
- Impacts functionality?
-
QemuRunner: Prevent virtual drive unknown image format warning @makubacki (#686)
Change Details
## Description
The virtual drive image is passed with the following parameter:
-hdd <VirtualDrivePath>
This results in the following warning:
WARNING: Image format was not specified for 'VirtualDrive.img' and probing guessed raw. Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted. Specify the 'raw' format explicitly to remove the restrictions.
This passes the image using
-drive
to resolve the warning.- 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 and QemuSbsaPkg build and run
Integration Instructions
N/A
- Impacts functionality?
🔐 Security Impacting
-
Remove physical presence from Q35 and SBSA @TaylorBeebe (#687)
Change Details
## Description
The physical presence check is a poor way to determine if a user is actually physically present at the machine. Because some security checks can be bypassed with physical presence, set physical presence to FALSE.
- 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 Features/CONFIG from 1.0.1 to 2.0.0 @ProjectMuBot (#694)
Change Details
Bumps Features/CONFIG from `1.0.1` to `2.0.0`
Introduces 12 new commits in Features/CONFIG.
Commits
- c608e2 Repo File Sync: Update to Mu DevOps 5.0.6 and Ubuntu container 3bf70b5 (#222)
- a8adde pip: bump edk2-pytool-extensions from 0.23.9 to 0.23.10 (#223)
- 861ed2 pip: bump xmlschema from 2.3.1 to 2.4.0 (#225)
- a78277 SetupDataPkg/Tools/KnobService.py: Fix flake8 6.1.0 error
- 34e9b7 pip: bump flake8 from 6.0.0 to 6.1.0
- 5e9478 pip: bump edk2-pytool-library from 0.15.3 to 0.16.1 (#227)
- 523836 pip: bump regex from 2023.6.3 to 2023.8.8 (#226)
- 2d26e7 pip: bump edk2-pytool-lib...
v4.4.0
What's Changed
🚀 Features & ✨ Enhancements
-
Add Rust support and DXE Rust driver to boot [Rebase \& FF] @makubacki (#688)
Change Details
## Description
Includes changes to add Rust build support to the repo, include a Rust
DXE driver (HelloWorldRustDxe
) in theQemuQ35Pkg
andQemuSbsaPkg
build and boot, and associated pipeline changes.Change summary:
Add repo Rust infrastructure support
Adds files to support:
- A cargo-make makefile
- Default Rust toolchain version
- Rust formatting configuration
- Rust host-based unit test CI execution
Bump Common/MU from 2023020001.3.1 to 2023020001.4.0
Add HelloWorldRustDxe to QemuQ35Pkg and QemuSbsaPkg
Adds the driver to both packages to demonstrate a Rust based UEFI
DXE driver executing during boot on a X64 and AARCH64 system.A workspace Cargo.toml file is added for cargo make. Since this repo
is the "leaf of a dependency chain" in that it builds binaries that
are integrated into the platform build, theCargo.lock
file is
checked in per the guidance in:
https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries
.azurepipelines: Add Rust support
Updates the repo pipelines to support Rust 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
- Verified CI and Platform builds locally and in CI
- Verified QemuQ35Pkg and QemuSbsaPkg builds
- Verified HelloWorldRustDxe dispatches during boot and prints
the expected debug messages
Integration Instructions
N/A
Note: The
MU_BASECORE
submodule will be updated after microsoft/mu_basecore#545 completes.
Full Changelog: v4.3.1...v4.4.0