Releases: microsoft/mu_basecore
v2023110001.1.0
What's Changed
-
RustEnvironmentCheck: Bugfix embedded quotes @Javagedes (#749)
Change Details
## Description
Replaces embedded double quotes with single quotes in the RustEnvironmentCheck plugin as embedded double quotes support when working with f-strings was only added in python 3.12, and this project should support python 3.10, 3.11, and 3.12.
File "C:\src\mu_plus\MU_BASECORE\BaseTools\Plugin\RustEnvironmentCheck\RustEnvironmentCheck.py", line 259 f" cargo binstall cargo-make {('--version ' + tool_versions.get("cargo-make", "")) if "cargo-make" in tool_versions else ""}" SyntaxError: f-string: unmatched '('
- 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 the plugin works on 3.10, 3.11, and 3.12
Integration Instructions
N/A
</blockquote> <hr> </details>
- Impacts functionality?
🚀 Features & ✨ Enhancements
-
Edk2ToolsBuild: override basetoolsbin\_ext\_dep @Javagedes (#745)
Change Details
## Description
Building a local copy of Edk2ToolsBuild does not automatically override the pre-compiled copy of the basetools provided by basetoolsbin_ext_dep.
This commit adds an id to the external dependency, that can then be overridden with override_id in the path_env file that is generated when you build the basetools locally with Edk2ToolsBuild.
- 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 EDK_TOOLS_BIN now points at the locally-built basetools once they have been built.
Integration Instructions
N/A
</blockquote> <hr> </details>
- Impacts functionality?
Full Changelog: v2023110001.0.3...v2023110001.1.0
v2023110001.0.3
What's Changed
-
remove edk2-basetools @Javagedes (#732)
Change Details
## Description
Removes edk2-basetools from pip-requirements.txt and any usage of it in the CISettings.py. The is done as there are changes in the build tools python source code that are available locally in BaseTools (as it is managed by Project Mu) that is not available in edk2-basetools.
- Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
- Security - Does the change have a direct security impact on an application,
flow, or firmware? - Examples: Crypto algorithm change, buffer overflow fix, parameter
validation improvement, ...
- Security - Does the change have a direct security impact on an application,
- Breaking change?
- Breaking change - Will anyone consuming this change experience a break
in build or boot behavior? - Examples: Add a new library class, move a module to a different repo, call
a function in a new library class in a pre-existing module, ...
- Breaking change - Will anyone consuming this change experience a break
- Includes tests?
- Tests - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
- Documentation - Does the change contain explicit documentation additions
outside direct code modifications (and comments)? - Examples: Update readme file, add feature readme file, link to documentation
on an a separate Web page, ...
- Documentation - Does the change contain explicit documentation additions
How This Was Tested
Verified the build system continues to use the local python source
Integration Instructions
N/A - only effects this repository's CI system.
- Impacts functionality?
-
RustEnvironmentCheck: Check Version if specified @Javagedes (#737)
Change Details
## Description
Allows repository owners to enforce version requirements for some rust related tools needed for build. This includes cargo-make and cargo-tarpaulin.
RustEnvironmentCheck currently only checks that the necessary tooling exists on the system. The only version check it performs is for the compiler version. This update adds support for repository owners to optionally require specific versions for cargo-make and cargo-tarpaulin by setting the required version in the rust-toolchain.toml file at the workspace root.
Updates the install command suggestion for cargo make and cargo tarpaulin.
Example Usage:
# rust-toolchain.toml [toolchain] channel = "1.73.0" [tool] cargo-tarpaulin = "0.27.3" cargo-make = "0.37.9"
- 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
Confirmed the following scenarios:
- Tool missing, version specified
- Tool missing, version not specified
- Tool installed, version mismatch
Integration Instructions
Example Usage:
[toolchain] channel = "1.73.0" [tool] cargo-tarpaulin = "0.27.3" cargo-make = "0.37.9"
If a repository maintainer wants to manage the version, update the rust-toolchain.toml file similar to the example aove.
- Impacts functionality?
🐛 Bug Fixes
-
BaseTools/RustEnvironmentCheck: Allow no tools in toolchain file @makubacki (#746)
Change Details
## Description
The get_required_tool_versions() function currently assumes that a
tool match will be present in the workspace toolchain file. This
change prevents aNoneType
AttributeError
if no results are found
by first checking that match is notNone
.- Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
- Security - Does the change have a direct security impact on an application,
flow, or firmware? - Examples: Crypto algorithm change, buffer overflow fix, parameter
validation improvement, ...
- Security - Does the change have a direct security impact on an application,
- Breaking change?
- Breaking change - Will anyone consuming this change experience a break
in build or boot behavior? - Examples: Add a new library class, move a module to a different repo, call
a function in a new library class in a pre-existing module, ...
- Breaking change - Will anyone consuming this change experience a break
- Includes tests?
- Tests - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
- Documentation - Does the change contain explicit documentation additions
outside direct code modifications (and comments)? - Examples: Update readme file, add feature readme file, link to documentation
on an a separate Web page, ...
- Documentation - Does the change contain explicit documentation additions
How This Was Tested
- Run against
rust-toolchain.toml
file with a matching tool pattern - Run against
rust-toolchain.toml
file without a matching tool pattern
Integration Instructions
N/A
- Impacts functionality?
Full Changelog: v2023110001.0.2...v2023110001.0.3
v2023020013.1.4
What's Changed
🔐 Security Impacting
-
[Release/202302] Cherry-Picks PixieFail vulnerability fixes for Bugs 1-7 @Flickdm (#739)
Change Details
# Preface
Description
This integrates fixes for bugs 1-7 for the PixieFail NetworkPkg vulnerabilities into mu_basecore.
- 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?
- Yes Patches the following CVEs:
- CVE-2023-45229
- CVE-2023-45230
- CVE-2023-45231
- CVE-2023-45232
- CVE-2023-45233
- CVE-2023-45234
- CVE-2023-45235
- Yes Patches the following CVEs:
- Breaking change?
- No
- Includes tests?
- Yes - provides unit tests to confirm the vulnerability has been fixed and backwards compatibility has been maintained
- Includes documentation?
- Yes - SecurityFixes.yaml explains which CVEs have been patched
How This Was Tested
Unit Tests / PxeBoot on real hardware
Integration Instructions
Take these changes if a merge conflict occurs
- Impacts functionality?
📖 Documentation Updates
-
[Release/202302] Cherry-Picks PixieFail vulnerability fixes for Bugs 1-7 @Flickdm (#739)
Change Details
# Preface
Description
This integrates fixes for bugs 1-7 for the PixieFail NetworkPkg vulnerabilities into mu_basecore.
- 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?
- Yes Patches the following CVEs:
- CVE-2023-45229
- CVE-2023-45230
- CVE-2023-45231
- CVE-2023-45232
- CVE-2023-45233
- CVE-2023-45234
- CVE-2023-45235
- Yes Patches the following CVEs:
- Breaking change?
- No
- Includes tests?
- Yes - provides unit tests to confirm the vulnerability has been fixed and backwards compatibility has been maintained
- Includes documentation?
- Yes - SecurityFixes.yaml explains which CVEs have been patched
How This Was Tested
Unit Tests / PxeBoot on real hardware
Integration Instructions
Take these changes if a merge conflict occurs
- Impacts functionality?
Full Changelog: v2023020013.1.3...v2023020013.1.4
v2023110001.0.2
What's Changed
🔐 Security Impacting
-
[Release/202311] Cherry-Picks PixieFail vulnerability fixes for Bugs 1-7 @Flickdm (#738)
Change Details
# Preface
Description
This integrates fixes for bugs 1-7 for the PixieFail NetworkPkg vulnerabilities into mu_basecore.
- 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?
- Yes Patches the following CVEs:
- CVE-2023-45229
- CVE-2023-45230
- CVE-2023-45231
- CVE-2023-45232
- CVE-2023-45233
- CVE-2023-45234
- CVE-2023-45235
- Yes Patches the following CVEs:
- Breaking change?
- No
- Includes tests?
- Yes - provides unit tests to confirm the vulnerability has been fixed and backwards compatibility has been maintained
- Includes documentation?
- Yes - SecurityFixes.yaml explains which CVEs have been patched
How This Was Tested
Unit Tests / PxeBoot on real hardware
Integration Instructions
Take these changes if a merge conflict occurs
- Impacts functionality?
📖 Documentation Updates
-
[Release/202311] Cherry-Picks PixieFail vulnerability fixes for Bugs 1-7 @Flickdm (#738)
Change Details
# Preface
Description
This integrates fixes for bugs 1-7 for the PixieFail NetworkPkg vulnerabilities into mu_basecore.
- 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?
- Yes Patches the following CVEs:
- CVE-2023-45229
- CVE-2023-45230
- CVE-2023-45231
- CVE-2023-45232
- CVE-2023-45233
- CVE-2023-45234
- CVE-2023-45235
- Yes Patches the following CVEs:
- Breaking change?
- No
- Includes tests?
- Yes - provides unit tests to confirm the vulnerability has been fixed and backwards compatibility has been maintained
- Includes documentation?
- Yes - SecurityFixes.yaml explains which CVEs have been patched
How This Was Tested
Unit Tests / PxeBoot on real hardware
Integration Instructions
Take these changes if a merge conflict occurs
- Impacts functionality?
Full Changelog: v2023110001.0.1...v2023110001.0.2
v2023110001.0.1
What's Changed
-
CryptoPkg/RuntimeDxeCryptLib: Make globals static @makubacki (#741)
Change Details
## Description
The GNU linker (ld) raises an error due to duplicate symbols for the
mVirtualAddressChangeEvent
global. This change updates both globals
in the file to be static to prevent future symbol collisions.- 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
VariableRuntimeDxe
using GCC on Ubuntu with theRuntimeDxeCryptLib
library instance linked.
Integration Instructions
N/A
- Impacts functionality?
-
BaseTools/GenFds: Resolve absolute workspace INF paths @makubacki (#740)
Change Details
## Description
Currently, if an INF path is an absolute path on Linux (begins with
"/"), the "/" character will be removed. If the path is an absolute
system path, this creates an invalid path.This creates an issue, for example, if an INF is in an ext dep where
the ext dep has theset_build_var
flag set and DSC files refer to
files by its build variable (e.g.$(SHARED_CRYPTO_PATH)/Module.inf
).$(SHARED_CRYPTO_PATH)
will be an absolute path to the ext dep
directory andFfsInfStatement.__InfParse__
will remove the leading
"/" character so the path is invalid.This change first checks if the absolute path will resolve into the
current workspace. If it does (as will happen in the shared crypto
ext dep example above), it modifies the path to be relative to the
workspace so later logic dependent on relative paths can operate on
it. If the absolute path is not within the current workspace, it
follows previous behavior for backward compatibility to that
scenario.- 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 with the change against Mu Basecore CI and Mu Tiano Platforms platform builds.
- Build on Ubuntu with an ext dep that sets an absolute path in a build variable that
is used to build an INF file. Verify failure before and success after the change.
Integration Instructions
N/A
- Impacts functionality?
Full Changelog: v2023110001.0.0...v2023110001.0.1
v2023110001.0.0
What's Changed
-
Remove static initialization of gMmst for MM Core Lib @cfernald (#730)
Change Details
## Description
Removes static initialization for gMmst in the MM Core implementation of MmServicesTableLib. Static initialization of this structure is problematic as callers will use the initialized value as a indication services are ready for use. This results in premature calls to memory allocations causing early faults in the core.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested
Tested boot with change.
Integration Instructions
N/A
⚠️ Breaking Changes
-
CryptoPkg/Driver: Remove directory @makubacki (#733)
Change Details
## Description
These contents will be available in the shared crypto binary.
Quite a bit of the DSC is cleaned up to reflect the fact that the package is
mostly just building libraries that wrap around PPIs and protocols now.- 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 files present in shared crypto external dependency in QemuQ35Pkg
and QemuSbsaPkg.
Integration Instructions
Update any code to refer to the files relative to the shared crypto binary
external dependency. Most references for shared crypto will be in files inside
the shared crypto binary distribution package (ext dep).NOTE: The value
BLD_*_SHARED_CRYPTO_PATH
is different than the previous
var_name
value in the JSON file previously checked into this repo. This value
can be used in build files and is more generic for the new use cases it serves.The ext dep also sits in
CryptoPkg/Binaries
a shorter, simpler path than
before.
- Impacts functionality?
🚀 Features & ✨ Enhancements
-
CryptoPkg/Driver: Remove directory @makubacki (#733)
Change Details
## Description
These contents will be available in the shared crypto binary.
Quite a bit of the DSC is cleaned up to reflect the fact that the package is
mostly just building libraries that wrap around PPIs and protocols now.- 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 files present in shared crypto external dependency in QemuQ35Pkg
and QemuSbsaPkg.
Integration Instructions
Update any code to refer to the files relative to the shared crypto binary
external dependency. Most references for shared crypto will be in files inside
the shared crypto binary distribution package (ext dep).NOTE: The value
BLD_*_SHARED_CRYPTO_PATH
is different than the previous
var_name
value in the JSON file previously checked into this repo. This value
can be used in build files and is more generic for the new use cases it serves.The ext dep also sits in
CryptoPkg/Binaries
a shorter, simpler path than
before.
- Impacts functionality?
-
.pytool/Plugin/DscCompleteCheck: Allow git ignore syntax @makubacki (#736)
Change Details
## Description
Allows ignore lines in the CI YAML file to use git ignore syntax.
This is especially useful for ignore files recursively in directories
like those that may exist in an external dependency folder.- 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
- DSC Complete against all packages in Mu Basecore
- DSC Complete against CryptoPkg ignoring shared crypto ext dep INFs
withCryptoPkg/Binaries/**
Integration Instructions
Use the new syntax if beneficial in a platform.
- Impacts functionality?
-
CryptoPkg: Add RT DXE shared crypto library instance @makubacki (#731)
Change Details
## Description
Adds a new BaseCryptLibOnProtocolPpi instance that can be used by
Runtime DXE drivers. For any other DXE modules types such as UEFI
applications or not-RT DXE drivers, the existing DxeCryptLib should
be used.- 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
- CryptoPkg build and CI.
- QemuQ35Pkg build and boot to Windows using the Runtime DXE variable driver
withSMM_ENABLED=FALSE
.
Integration Instructions
Use the
RuntimeDxeCryptLib
instance ofBaseCryptLib
if needed
for RT DXE crypto support on a platform.
- Impacts functionality?
📖 Documentation Updates
-
.pytool/Plugin/DscCompleteCheck: Allow git ignore syntax @makubacki (#736)
Change Details
v2023020013.1.3
What's Changed
-
[CHERRY-PICK] Restore IntrinsicLib to CryptoPkg @kenlautner (#735)
Change Details
## Description
Some silicon code is making use of the CryptoPkg's Intrinsic lib.
Intrinsiclib was removed in 04bb719.
Adding the functionality back to allow silicon code to use the library while a better long term solution is created.
- 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, ...
- 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, ... - 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, ...
How This Was Tested
Integration Instructions
N/A
Full Changelog: v2023020013.1.2...v2023020013.1.3
v2023110000.0.1
What's Changed
🔐 Security Impacting
-
Updated Crypto binaries to 2023.02.9 to include SHA384 and SHA512 functions @kenlautner (#726)
Change Details
## Description
Built new binaries to include SHA384 and SHA512 functions in the STANDARD flavor of the crypto binary. This is to support new authenticated variable logic that allows you to choose which SHA functions to use instead of always using SHA256.
- 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 QemuQ35 and on physical systems. SHA384 and SHA512 functions were usable.
Integration Instructions
Update your MU_BASECORE pin to include this change and it'll be pulled automatically.
- Impacts functionality?
Full Changelog: v2023110000.0.0...v2023110000.0.1
v2023110000.0.0
What's Changed
First 202311 Mu Basecore release 🎉.
-
Restore IntrinsicLib to CryptoPkg @apop5 (#712)
Change Details
## Description
Some silicon code is making use of the CryptoPkg's Intrinsic lib.
Intrinsiclib was removed in afd1f31.
Adding the functionality back to allow silicon code to use the library while a better long term solution is created.
- 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
Integration Instructions
N/A
- Impacts functionality?
-
[Rebase \& FF] [Cherry-pick] Get all the missing commits from 202302 into 202311 @kenlautner (#721)
Change Details
## Description
Cherry-pick the commits from 202302 that are missing from 202311 since the creation of the release branch.
- Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
- Security - Does the change have a direct security impact on an application,
flow, or firmware? - Examples: Crypto algorithm change, buffer overflow fix, parameter
validation improvement, ...
- Security - Does the change have a direct security impact on an application,
- Breaking change?
- Breaking change - Will anyone consuming this change experience a break
in build or boot behavior? - Examples: Add a new library class, move a module to a different repo, call
a function in a new library class in a pre-existing module, ...
- Breaking change - Will anyone consuming this change experience a break
- Includes tests?
- Tests - Does the change include any explicit test code?
- Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
- Documentation - Does the change contain explicit documentation additions
outside direct code modifications (and comments)? - Examples: Update readme file, add feature readme file, link to documentation
on an a separate Web page, ...
- Documentation - Does the change contain explicit documentation additions
How This Was Tested
CI
Integration Instructions
N/A
- Impacts functionality?
-
release-basetools.yml: Add contents write permission for publishing @makubacki (#718)
Change Details
## Description
The GITHUB_TOKEN is used in the
gh release upload
command to
upload a new basetools release. This adds content write permission
to allow the upload to work when the default permission is read-only
for the token.- 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 failure with read-only token on fork. Confirmed success with the change.
Integration Instructions
N/A - Only affects local repro GitHub workflow.
- Impacts functionality?
-
[CHERRY-PICK] Repo File Sync: Add permissions to GitHub workflows @makubacki (#719)
Change Details
## Description
Needed for GitHub workflows on this branch to continue functioning.
(cherry picked from commit 8e5180d)
- 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
- release/202302 branch
Integration Instructions
N/A
- Impacts functionality?
-
Add SHA384 and SHA512 to the STANDARD flavor of the crypto binary @kenlautner (#709)
Change Details
## Description
Authenticated variables were updated to allow the choice of SHA256, SHA384 or SHA512 for hashing. To accommodate this change, we need the algorithms available for use. This change updates the STANDARD flavor of shared crypto to include the SHA384 and SHA512 algorithms so that they can be used by consumers of the binary.
There is no size impact for the STANDARD flavor because all of the SHA implementations are built together in openssl. This simply enables their use.
- 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 locally generated binaries. SHA384 and SHA512 were available to use.
Integration Instructions
N/A
- Impacts functionality?
-
[CHERRY-PICK] Remove requirements on `CRYPTO_SERVICES` and `ARCH` variables #710 @kuqin12 (#713)
Change Details
## Description
The original implementation of autogenerated dsc files is requiring platform owners to define all
CRYPTO_SERVICES
andARCH
variables when the dsc is included. This would require certain platforms, such as some AARCH64 platforms, to pull in unrelated library instances for BL32 or BL33 only builds.This change updated the ...
v2023020013.1.2
What's Changed
-
[CHERRY-PICK] release-basetools.yml: Add contents write permission for publishing @makubacki (#717)
Change Details
## Description
The GITHUB_TOKEN is used in the
gh release upload
command to
upload a new basetools release. This adds content write permission
to allow the upload to work when the default permission is read-only
for the token.(cherry picked from commit 1cab22a)
- 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 failure with read-only token on fork. Confirmed success with the change.
Integration Instructions
N/A - Only affects local repro GitHub workflow.
- Impacts functionality?
Full Changelog: v2023020013.1.1...v2023020013.1.2