Releases: microsoft/mu_basecore
v2023020000.1.0
What's Changed
-
Explicitly make Linux binaries executable and create Basetools tar file. @cfernald (#427)
Change Details
## Description
This change address two issues related to executable files in the basetools zip.
-
The artifacts published from the build stage of the basetools pipelines will lose their executable attributes when downloaded in the published phase. This change explicitly makes the binaries executable as part of the publishing job for linux binaries. This could also be done by zipping the binaries in the first stage of the pipeline, but the added steps add little value over the simple chmod fix.
-
The python implementation of zipfile does not set the executable filemode attributes when decrompressing a zip archive, so any zip extdep with executable files will not be executable when downloaded in extracted. Tar files do not have this same issue so this creates a tarfile version of the basetools package to allow a work-around to this issue. This is being tracked in pytools-extensions by tianocore/edk2-pytool-extensions#579.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested
Tested on a forked release, and locally confirmed with an updated extdep.
Integration Instructions
N/A
</blockquote> <hr> </details>
-
-
REBASE: Re-remove the codeql workflow @kenlautner (#417)
Change Details
## Description
Removed CodeQL workflows that were accidentally included in the rebase
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
N/A
Integration Instructions
N/A
</blockquote> <hr> </details>
- Impacts functionality?
🚀 Features & ✨ Enhancements
-
Enable crypto binaries for 202302 @kenlautner (#419)
Change Details
## Description
Enabled crypto binaries and points them to the newly created binaries for 202302.
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
Built and booted on Intel physical platforms.
Integration Instructions
If you are already ingesting our crypto binaries or you don't want to use them then there is no additional integration necessary.
If you want to use them but haven't used them in the past please reference the readme at CryptoPkg/Driver/Readme.md
- Impacts functionality?
-
Add support for IAD-style USB input devices in ConPlatform @joschock (#420)
Change Details
## Description
Some multi-function input devices (e.g. combo keyboard and mouse) present as IAD-style devices (see: https://learn.microsoft.com/en-us/windows-hardware/drivers/usbcon/usb-interface-association-descriptor). Historically, multi-function devices would report a DeviceClass of 0, indicating that interface matching should be done on the interface descriptor rather than the global device descriptor.
IAD-style devices us DeviceClass of 0xEF, so they don't match MatchUsbClass() for keyboard (DeviceClass=3, SubClass=1, Proto=1). If they are treated as if they had a DeviceClass of zero, which is more traditional for legacy multi-function devices, then the interface descriptors are used instead and these types of devices will "just work" without needing to add a custom USB device path to ConIn.
For each item, place an "x" in between
[
and]
if true. Example:[x]
.
(you can also check items in the GitHub UI)- Impacts functionality?
- IAD-style devices will now use interface descriptor matching rather than device descriptor matching when evaluating ConIn contents. Mostly this means that composite input devices that didn't used to work without ConIn customization in UEFI will now work out of the box.
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested
Verified this with an arduino-based test device that exposes an IAD-style descriptor with keyboard and mouse HID interfaces. Prior to this change, device keyboard input was not usable in FP or shell because it didn't match the default ConIn USB input descriptor. After this change, the keyboard input worked as expected.
Integration Instructions
No integration required.
- Impacts functionality?
🔐 Security Impacting
-
Enable crypto binaries for 202302 @kenlautner (#419)
Change Details
## Description
Enabled crypto binaries and points them to the newly created binaries for 202302.
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
Built and booted on Intel physical platforms.
Integration Instructions
If you are already ingesting our crypto binaries or you don't want to use them then there is no additional integration necessary.
If you want to use them but haven't used them in the past please reference the readme at CryptoPkg/Driver/Readme.md
- Impacts functionality?
Full Changelog: v2023020000.0.0...v2023020000.1.0
v2023020000.0.0
What's Changed
This is the first Mu Basecore 202302 release 🎉
The previous Mu Basecore branch was 202208.
These versions correspond to edk2 stable release tags that the Mu Basecore code is based upon.
Since edk2 makes a release every 3 months, two stable tags were actually picked up in this release:
Review those release notes to understand the changes coming in from edk2. In addition, Mu repos highlight important changes in their Readme files. Review the Mu Basecore 202302 Readme before you move code to this branch to understand major changes.
-
CHERRY-PICK: Add a pull request build for basetools pipeline and directory changes… @cfernald (#416)
Change Details
… (#413)
Description
-
Adds a pull request run of the basetools pipeline for the pipeline file and basetools directory.
-
Adds an update to resolve missing package lists in ubuntu pipeline image.
-
Impacts functionality?
-
Impacts security?
-
Breaking change?
-
Includes tests?
-
Includes documentation?
How This Was Tested
N/A
Integration Instructions
N/A
-
-
[CHERRY-PICK] Take changes from 202208 into 202302 [Rebase \& FF] @kenlautner (#414)
Change Details
## Description
Cherry-picked the commits that have gone into 202208 that haven't made it into 202302.
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
Build on a physical platform.
Integration Instructions
N/A
</blockquote> <hr> </details>
- Impacts functionality?
⚠️ Breaking Changes
-
Fix some miscellaneous issues in cryptopkg. @kenlautner (#407)
Change Details
## Description
Fixed some miscellaneous issues in cryptopkg including the x509 test causing a page fault and the version for the crypto files being the incorrect version. Changing the crypto version makes this a breaking 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
Built and tested on QemuQ35 including the basecrypto tests.
Integration Instructions
Update to the latest basecore commit.
- Impacts functionality?
Full Changelog: v2022080002.0.2...v2023020000.0.0
v2022080002.0.2
What's Changed
-
[CHERRY-PICK] Stop USB enumeration in case a malformed descriptor is found (#410) @os-d (#412)
Change Details
## Description
This is a cherry-pick of commit 714d41b to release/202208.
When parsing interface descriptors for an attached USB device, the USB bus driver correctly handles cases where a device has a malformed interface .
UsbParseInterfaceDesc
returnsNULL
in such cases.UsbParseConfigDesc
which parses interface descriptors, stops parsing in caseUsbParseInterfaceDesc
returns NULL but still returnsEFI_SUCCESS
along with a partially filledUSB_CONFIG_DESC
structure.This causes access exceptions when attempts are made subsequently to communicate with the downstream device (for e.g. during endpoint configuration) as the driver does not have valid interface descriptor structures associated with the device.
To fix this,
UsbParseConfigDesc
should take the error path in cases whereUsbParseInterfaceDesc
returns NULL and abandon enumerating the device. This will allow a platform to boot instead of crashing when a buggy USB device is attached to it.- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested
Tested on a platform with a USB keyboard that returns a malformed USB interface descriptor. The platform fails to boot with an access violation exception without this fix.
Integration Instructions
Updating to the latest MU_BASECORE will automatically include this fix if the UsbBus DXE driver is included in the fdf/dscs.
Preface
Please ensure you have read the contribution docs prior
to submitting the pull request. In particular,
pull request guidelines.Description
<Please include a description of the change and why this change was made.>
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
<Please describe the test(s) that were run to verify the changes.>
Integration Instructions
<Describe how these changes should be integrated. Use N/A if nothing is required.>
</blockquote> <hr> </details>
-
pip: update edk2-pytool-extensions requirement from ~=0.23.2 to ~=0.23.3 @dependabot (#406)
Change Details
Updates the requirements on [edk2-pytool-extensions](https://github.com/tianocore/edk2-pytool-extensions) to permit the latest version.
Release notes
Sourced from edk2-pytool-extensions's releases.
v0.23.3
What's Changed
- Revert skip verification by
@Javagedes
in tianocore/edk2-pytool-extensions#541 - uefi_build: missing env error handling by
@Javagedes
in tianocore/edk2-pytool-extensions#545 - edk2_logging: add gcc fatal error regex by
@Javagedes
in tianocore/edk2-pytool-extensions#547
Other Changes
- Transition to Ruff [REBASE&FF] by
@Javagedes
in tianocore/edk2-pytool-extensions#524 - readme: make documentation url more visible by
@Javagedes
in tianocore/edk2-pytool-extensions#548 - pyproject.toml: update readme content-type by
@Javagedes
in tianocore/edk2-pytool-extensions#527 - documentation: remove requirements.txt by
@Javagedes
in tianocore/edk2-pytool-extensions#529 - MANFIEST.in: additional excludes by
@Javagedes
in tianocore/edk2-pytool-extensions#528 - tests.integration: update directory by
@Javagedes
in tianocore/edk2-pytool-extensions#543
Dependency Updates
- build(deps-dev): bump mkdocs-awesome-pages-plugin from 2.9.0 to 2.9.1 by
@dependabot
in tianocore/edk2-pytool-extensions#532 - build(deps-dev): bump mkdocstrings-python from 0.10.1 to 1.0.0 by
@dependabot
in tianocore/edk2-pytool-extensions#544 - build(deps-dev): bump mkdocs from 1.4.2 to 1.4.3 by
@dependabot
in tianocore/edk2-pytool-extensions#531 - build(deps-dev): bump mkdocs-material from 9.1.11 to 9.1.12 by
@dependabot
in tianocore/edk2-pytool-extensions#546 - build(deps-dev): bump ruff from 0.0.265 to 0.0.267 by
@dependabot
in tianocore/edk2-pytool-extensions#551
Full Changelog: tianocore/edk2-pytool-extensions@v0.23.2...v0.23.3
Commits
67a4660
readme: make documentation url more visible (#548)ff20497
build(deps-dev): bump ruff from 0.0.265 to 0.0.267 (#551)ee1b117
edk2_logging: add gcc fatal error regex (#547)b42ef3d
build(deps-dev): bump mkdocs-material from 9.1.11 to 9.1.12 (#546)dddb582
uefi_build: missing env error handling (#545)b3212b2
build(deps-dev): bump mkdocs from 1.4.2 to 1.4.3 (
- Revert skip verification by
v2022080002.0.1
What's Changed
-
Revert "Converge on 4k Section Alignment for AARCH64 Builds (#352)" @os-d (#391)
Change Details
This reverts commit 1bd4b3b.
This commit worked around an issue that was seen on ARM64 platforms where random builds would fail. However, it also increased the size of all FVs containing PEIMs.
This also masked the ability to repro and debug the underlying issue. Hence, this commit is being reverted so that repros will be seen and can be debugged.
Preface
Please ensure you have read the contribution docs prior
to submitting the pull request. In particular,
pull request guidelines.Description
<Please include a description of the change and why this change was made.>
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
<Please describe the test(s) that were run to verify the changes.>
Integration Instructions
<Describe how these changes should be integrated. Use N/A if nothing is required.>
</blockquote> <hr> </details>
- Impacts functionality?
-
Fixing bug with newer versions of markdownlint @bkarstens (#389)
Change Details
## Description Fixed a bug with the MarkdownLintCheck plugin where with newer versions of the tool the plugin would pass when there were markdown issues. Newer versions of `markdownlint` (in this case `0.34.0`) no longer understand backslashes in the `` parameter; including backslashes in that parameter results in the tool printing the help text and returning 0. This change removes the backslashes from that parameter to fix the plugin.
- 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
On Windows 11 with Node v16.15.0:
- with markdownlint v0.34.0: ran stuart_ci_build on my pkgs and observed the MarkdownLintCheck plugin failed when markdown issues, succeeded when no markdown issues.
- with markdownlint v0.31.1 (version known to not have this issue): ran stuart_ci_build on my pkgs and observed the MarkdownLintCheck plugin failed when markdown issues, succeeded when no markdown issues.
Integration Instructions
N/A
</blockquote> <hr> </details>
- Impacts functionality?
Full Changelog: v2022080002.0.0...v2022080002.0.1
v2022080002.0.0
What's Changed
⚠️ Breaking Changes
-
Remove the ARM GCC compiler extdeps to use container GCC @cfernald (#388)
Change Details
## Description
Removes the ARM & AARCH64 GCC compiler extdep files. Thes external dependencies frequently break, and all Project MU builds should now be using the container provided GCC binaries.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested
Local build test in container.
Integration Instructions
All consumers that require the ext dep must now carry their own copies of the extdep files removed by the commit.
BaseTools/Bin/gcc_aarch64_linux_ext_dep.yaml
BaseTools/Bin/gcc_arm_linux_ext_dep.yaml</blockquote> <hr> </details>
Full Changelog: v2022080001.4.3...v2022080002.0.0
v2022080001.4.3
What's Changed
-
Converge on 4k Section Alignment for AARCH64 Builds @os-d (#352)
Change Details
# Preface
Please ensure you have read the contribution docs prior
to submitting the pull request. In particular,
pull request guidelines.Description
Currently tools_def.template sets two different common-page-sizes for GCC/Clang AARCH64 builds. This is not a supported configuration. This leads to ambiguity and relying on the toolchain to interpret the arguments in a certain way, which they are not guaranteed to do. This leads to the case where the same code can fail to be aligned to the required 4k boundary because the incorrect common-page-size was chosen.
This PR removes the incorrect common-page-size for AARCH64 GCC/Clang builds and only uses the 4kb alignment to remove the ambiguity and fix errors seen where the wrong common-page-size gets chosen by the toolchain. This PR also removes some of the duplicate instances of setting the common-page-size that exist to try to reduce issues in the future if it is changed. However, it was not attempted to reduce all of the duplicated instances in order to not miss edge cases and instead only the clearly duplicated cases where a new macro expanded another macro that contained common-page-size and then set common-page-size directly afterwards.
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
Tested by running in a local CI build that was failing due to the local GCC toolchain choosing the non-4k alignment argument passed to it and GenFw failing due to incorrect section alignment. With this fix, the CI build passes.
Integration Instructions
To integrate this change, pull the latest mu_basecore and delete the top level Conf directory. This will get regenerated from the updated mu_basecore tools_def.template.
- Impacts functionality?
Full Changelog: v2022080001.4.2...v2022080001.4.3
v2022080001.4.2
What's Changed
-
MdeModulePkg/Core: Reduce stack cookie value verbosity @makubacki (#384)
Change Details
## Description
The message that prints the security cookie value initialized during
PE image load prints about 150 times on some Intel platforms
(depending on DXE/MM module count and cookie config settings).This information is typically not needed unless specialized debug
related to security cookies is required which is rare. This change
constrains the message toDEBUG_VERBOSE
(instead ofDEBUG_INFO
)
in addition toDEBUG_LOAD
.- 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
Before change, log showed stack cookie value and after change it does not
(withDEBUG_VERBOSE
andDEBUG_LOAD
not active).Integration Instructions
Check if any tools or processes were dependent on the stack cookie value message
and adjust debug print level accordingly if necessary.
- Impacts functionality?
🐛 Bug Fixes
-
Fix dmpstore regressed during CodeQL changes @kuqin12 (#382)
Change Details
# Preface
Please ensure you have read the contribution docs prior
to submitting the pull request. In particular,
pull request guidelines.Description
During one of the CodeQL changes, the
dmpstore
command was no longer functional if the input wasdmpstore -all
.This was caused because the NULL pointer check incorrectly return the function, which is what occurs when using
-all
option. TheProcessVariables
will properly handle NULL input forName
.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 ARM FVP and QEMU virtual platforms.
Integration Instructions
N/A
</blockquote> <hr> </details>
- Impacts functionality?
Full Changelog: v2022080001.4.1...v2022080001.4.2
v2022080001.4.1
What's Changed
-
Edk2ToolsBuild.py: set arch to host arch if not specified on linux @Javagedes (#381)
Change Details
# Preface
Please ensure you have read the contribution docs prior
to submitting the pull request. In particular,
pull request guidelines.Description
The -a command line options should be optional, defaulting to IA32 on windows or the host arch on linux, however this scenario fails on linux systems as the arch is not set to the host's architecture. This PR adds this logic.
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
<Please describe the test(s) that were run to verify the changes.>
Integration Instructions
<Describe how these changes should be integrated. Use N/A if nothing is required.>
</blockquote> <hr> </details>
- Impacts functionality?
Full Changelog: v2022080001.4.0...v2022080001.4.1
v2022080001.4.0
What's Changed
-
Updated Crypto Tests @kenlautner (#372)
Change Details
## Description
Updated the crypto tests to reference the crypto functionality PCDs before attempting to test them. This will only test the enabled functionality for the different crypto flavors of the shared crypto binaries. Tests for functionality that are not enabled are skipped and labelled that way in the report.
Additionally, a new PCD dsc file was created for test purposes where all the Crypto PCDs are enabled. This should only be used for testing.
- 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 test on QemuQ35 and Adl physical platforms. Checked the different flavors to make sure tests were passed/failed/skipped as expected without any problems.
Integration Instructions
When building the shell app or host based unit test include the relevant PCDs that correspond to the flavor of Shared Crypto used for DXE.
- Impacts functionality?
🚀 Features & ✨ Enhancements
-
Updating all binary releases @kuqin12 (#379)
Change Details
# Preface
Please ensure you have read the contribution docs prior
to submitting the pull request. In particular,
pull request guidelines.Description
This change updates the binary tools released with BASECORE to the latest version. This includes:
- BaseTools: Added binary releases for Windows ARM/ARM64 and Linux ARM64
- IASL: Added binary releases for Window ARM64 and Linux ARM64
- Uncrustify: Added binary release for Linux ARM64
- NASM: Added binary releases for Linux ARM64
This is part of the effort of features: #305 and #369.
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 ARM based hardware system building QEMU Q35 and SBSA platforms.
Integration Instructions
N/A
</blockquote> <hr> </details>
Full Changelog: v2022080001.3.0...v2022080001.4.0
v2022080001.3.0
What's Changed
-
pip: bump edk2-basetools from 0.1.44 to 0.1.45 @dependabot (#377)
Change Details
Bumps [edk2-basetools](https://github.com/tianocore/edk2-basetools) from 0.1.44 to 0.1.45.
Commits
- See full diff in compare view
You can trigger a rebase of this PR by commenting
@dependabot rebase
.
Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebase
will rebase this PR@dependabot recreate
will recreate this PR, overwriting any edits that have been made to it@dependabot merge
will merge this PR after your CI passes on it@dependabot squash and merge
will squash and merge this PR after your CI passes on it@dependabot cancel merge
will cancel a previously requested merge and block automerging@dependabot reopen
will reopen this PR if it is closed@dependabot close
will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot ignore this major version
will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor version
will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependency
will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
-
pip: bump edk2-basetools from 0.1.43 to 0.1.44 @dependabot (#373)
Change Details
Bumps [edk2-basetools](https://github.com/tianocore/edk2-basetools) from 0.1.43 to 0.1.44.
Commits
- See full diff in compare view
You can trigger a rebase of this PR by commenting
@dependabot rebase
.
Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebase
will rebase this PR@dependabot recreate
will recreate this PR, overwriting any edits that have been made to it@dependabot merge
will merge this PR after your CI passes on it@dependabot squash and merge
will squash and merge this PR after your CI passes on it@dependabot cancel merge
will cancel a previously requested merge and block automerging@dependabot reopen
will reopen this PR if it is closed@dependabot close
will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot ignore this major version
will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor version
will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependency
will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
🚀 Features & ✨ Enhancements
-
[CHERRY-PICK] BaseTools/Plugin: Clarify code coverage failure message @makubacki (#375)
Change Details
## Description
HostBasedUnitTestRunner.py is a build plugin responsible for locating
and executing host-based unit tests.Recently, commit 6bb00aa introduced support for the plugin to
generate code coverage reports via lcov and OpenCppCoverage.The plugin has discovered unit tests by searching for executables
with "Test" in the name for a while. However, the test coverage
change makes assumptions about test presence when crafting the
OpenCppCoverage command that ultimately fails with an ambiguous error
message if no host-based unit tests are discovered (see "ERROR").SECTION - Run Host based Unit Tests SUBSECTION - Testing for architecture: X64 ERROR - UnitTest Coverage: Failed to generate cobertura format xml in single package. PROGRESS - --->Test Success: Host Unit Test Compiler Plugin NOOPT
This change preempts that message with a check in the plugin to
determine if any host-based tests were discovered. If not, a message
is printed with more guidance about how the developer should proceed
to either (1) fix their tests so code coverage is generated as
expected or (2) prevent the error message.New message:
SECTION - Run Host based Unit Tests SUBSECTION - Testing for architecture: X64 WARNING - UnitTest Coverage: No unit tests discovered. Test coverage will not be generated. Prevent this message by: 1. Adding host-based unit tests to this package 2. Ensuring tests have the word "Test" in their name 3. Disabling HostUnitTestCompilerPlugin in the package CI YAML file PROGRESS - --->Test Success: Host Unit Test Compiler Plugin NOOPT
Cc: Rebecca Cran [email protected]
Cc: Liming Gao [email protected]
Cc: Bob Feng [email protected]
Cc: Yuwei Chen [email protected]
Cc: Michael D Kinney [email protected]
Cc: Sean Brogan [email protected]
Signed-off-by: Michael Kubacki [email protected]
Reviewed-by: Liming Gao [email protected]
Reviewed-by: Rebecca Cran [email protected]
(cherry picked from commit 3163f34)- 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
Local and server CI.
Integration Instructions
N/A - No major change in functionality
- Impacts functionality?
-
Revert #168. Move changes into Terminal driver's Terminal ConIn. @apop5 (#378)
Change Details
# Preface
Please ensure you have read the contribution docs prior
to submitting the pull request. In particular,
pull request guidelines.Description
Revert #168 implementation. Move implementation into Terminal driver.
Moving this because serial ports don't need to be able to receive data unless the port is being used for simple text in.
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 cl...
- Breaking change - Will anyone consuming this change experience a break
- Impacts functionality?