## Description
Problem Report:
On AARCH64, there is no ordering guarantee between configuration
space (ECAM) writes and memory space reads (MMIO). ARM AMBA CHI
only guarantees ordering for reads and writes within a single address
region,
however, on some systems MMIO and ECAM may be split into separate
address regions.
A problem may arise when an ECAM write is issued a completion before a
subsequent
MMIO read is issued and receives a completion.
For example, a typical PCI software flow is the following:
1. ECAM write to device command register to enable memory space
2. MMIO read from device memory space for which access was enabled
in step 1.
There is no guarantee that step 2. will not begin before the completion
of step 1.
on systems where ECAM/MMIO are specified as separate address regions,
even
if both spaces have the memory attributes device-nGnRnE.
- Add a read after the final PCI Configuration space write
in RootBridgeIoPciAccess. Configuration space reads should not have
side-efects.
- When configuration space is strongly ordered, this ensures
that program execution cannot continue until the completion
is received for the previous Cfg-Write, which may have side-effects.
- Risk of reading a "write-only" register and causing a CA which leaves
the device
unresponsive. The expectation based on the PCI Base Spec v6.1 section
7.4 is that
all PCI Spec-defined registers will be readable, however, there may
exist
design-specific registers that fall into this category.
- [X] 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
- AARCH64 platform on real silicon
## Integration Instructions
N/A
---------
Co-authored-by: joelopez <joelopez@microsoft.com>
## Description
#612 added an additional `MuDevOpsWrapper.yml` parameter configuration
to opt in or out of code coverage, with the default being `false`,
disabling code coverage. This was due to the fact that uploading code
coverage data required a minimum `edk2-pytool-extensions` and
`edk2-pytool-library` version and associated `ParseSettingsManager` to
be implemented.
This commit upgrades Edk2-pytools to the required version, implements
`ParseSettingsManager`, and re-enables code coverage. This change only
restores previous functionality, with the caveat that code coverage data
is now organized by INF rather than by test executable.
This change results in no impact to consumers of MU_BASECORE, however
maintainers and contributors may view code coverage results by selecting
the pipeline in github and navigating to the pipeline run located at
`dev.azure.com`
- [ ] 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
N/A
## Integration Instructions
No impact to consumers of MU_BASECORE, however maintainers and
contributors may view code coverage results by selecting the pipeline in
github and navigating to the pipeline run located at `dev.azure.com`
## Description
Checks if the rust-src component is installed for the workspace
toolchain.
This is a basic requirement to build firmware code and not having
rust-src can result in an obscure error during firmware build.
- [ ] Impacts functionality?
- **Functionality** - Does the change ultimately impact how firmware
functions?
- Examples: Add a new library, publish a new PPI, update an algorithm,
...
- [ ] Impacts security?
- **Security** - Does the change have a direct security impact on an
application,
flow, or firmware?
- Examples: Crypto algorithm change, buffer overflow fix, parameter
validation improvement, ...
- [ ] 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
- Verify with the `rust-src` component installed/uninstalled
- Check on Linux and Windows
## Integration Instructions
N/A - Instructions included in log output
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
## Description
This change is required to allow test's that depend on the google test
mock function gRT_GetTime to function.
- [ ] 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?
- [ ] Breaking change?
- [ ] Includes tests?
- [ ] Includes documentation?
## How This Was Tested
This was tested on a test that is currently not public.
## Integration Instructions
N/A
Updates the requirements on
[edk2-pytool-library](https://github.com/tianocore/edk2-pytool-library)
to permit the latest version.
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
## Description
Incorrect comment identifier was used in module INF.
Found by running edk2-pytool-library INF parser over the mdemodulepkg
dsc 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, ...
- [ ] 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
Verified that CI continues to pass after fixing
## Integration Instructions
<_Describe how these changes should be integrated. Use N/A if nothing is
required._>
## Description
With Python 3.12 invalid escape sequences now generate warning messages.
This change fixes the problem exposed by the warning message.
```
INFO - mu_basecore\BaseTools\Scripts\BinToPcd.py:40: SyntaxWarning: invalid escape sequence '\_'
INFO - if re.split ('[a-zA-Z\_][a-zA-Z0-9\_]*\.[a-zA-Z\_][a-zA-Z0-9\_]*', Argument) != ['', '']:
INFO - mu_basecore\BaseTools\Scripts\BinToPcd.py:46: SyntaxWarning: invalid escape sequence '\_'
INFO - if re.split ('[a-zA-Z\_][a-zA-Z0-9\_]*', Argument) != ['', '']:
```
Additional updates:
* run isort
* removed trailing whitespace
- [ ] 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
I verified that the Python 3.12 character invalid escape sequence print
is no longer output, and that the regex expression is still functioning
as expected.
## Integration Instructions
N/A
## Description
Allows a build wrapper to set an environment variable (chosen as the
input method for its simplicity) to exclude a list of tools.
For example, a GitHub workflow that only runs CodeQL for C code,
might need cargo installed for Rust compilation as part of the
package build, but might not need cargo tarpaulin for code coverage.
The GitHub workflow can set the environment variable on the build
step to opt out of verifying those tools.
This is not intended to be used often as most local developers and
build environments are expected to have the base set of tools needed
to build and test the code when the plugins scope is present.
- [ ] 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, ...
- [x] 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
- Verified locally against a Rust enabled workspace
- Verified in a Mu Plus CodeQL workflow that does not have `cargo fmt`
and `cargo tarpaulin` installed by adding the following to the build
step (`RUST_ENV_CHECK_TOOL_EXCLUSIONS`):
```yaml
- name: CI Build
env:
RUST_ENV_CHECK_TOOL_EXCLUSIONS: "cargo fmt, cargo tarpaulin"
STUART_CODEQL_PATH: ${{ steps.cache_key_gen.outputs.codeql_cli_ext_dep_dir }}
run: stuart_ci_build -c .pytool/CISettings.py -t DEBUG -p ${{ matrix.package }} -a ${{ matrix.archs }} TOOL_CHAIN_TAG=${{ matrix.tool_chain_tag }} --codeql
```
## Integration Instructions
Add `RUST_ENV_CHECK_TOOL_EXCLUSIONS` as a shell variable if any tools
need to be excluded from the Rust environment check. The variable
contains
a comma separated list of tool names.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
## Description
Firmware developer's machines are often not setup for Rust. Ad more
Rust code is proliferating across the repos, this plugin is used to
provide early and direct feedback about the developer's environment
so it can successfully build Rust code using the tools commonly
used in the firmware build process.
The plugin is run when the `rust-ci` scope is specified which is used
by platforms to opt into Rust plugin support in Project Mu.
The entire plugin takes ~1.4 sec to run on average so build time is
not meaningfully impacted.
- [x] 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
Verified:
- The plugin does not run if the `rust-ci` scope is not set
- The plugin does run if the `rust-ci` scope is set
- The plugin reports no errors if all expected tools are installed.
- The plugin reports the corresponding tool installation help text if a
given tools is not installed.
- The plugin can properly parse a `rust-toolchain.toml` file
- The plugin reports errors in the console and build log as expected.
## Integration Instructions
Enable the `rust-ci` scope if Rust code is being built. The plugin will
run when that scope is set.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
## Description
Adds a check that PcdGetPtr returned a non-NULL value before calling
into CompareGuid()
- [x] Impacts functionality?
- **Functionality** - Does the change ultimately impact how firmware
functions?
- Examples: Add a new library, publish a new PPI, update an algorithm,
...
- [x] 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
Tested on Q35
## Integration Instructions
N/A
## Description
CodeQL fixes for MpLib, PeiMpLib and DxeMpLib. This includes their
related files.
- [ ] 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
Tested on Intel physical devices. I was able to build and boot without
any problems.
## Integration Instructions
N/A
## Description
PolicyServicePkg's PolicyLib rely on PolicyLibCommon, which includes
MemoryAllocationLib, header.
The Policy Libs do not enumerate MemoryAllocationLib in the
LibraryClasses section of their INF files.
If one of the enumerated library classes do not include
MemoryAllocationLib, a build error will occur.
Fixes#596
- [ ] 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
A platform threw a build error because of unresolved externals coming
from the MemoryAllocationLib usage.
Adding MemoryAllocationLib to the INFs resolved the build error.
## Integration Instructions
N/A
---------
Signed-off-by: Aaron <105021049+apop5@users.noreply.github.com>
Co-authored-by: Michael Kubacki <michael.kubacki@microsoft.com>
## Description
MdeModulePkg/MemoryTypeInfoSecVarCheckLib: Elaborate on expected mem
types
This variable check library instance currently checks the size of the
`MemoryTypeInformation` UEFI variable to determine if it contains the
total size expected based on the expected number of entries and the
`EFI_MEMORY_TYPE_INFORMATION` structure size where the structure is
used to represent an individual entry.
This changes adds a comment near entry count to describe what entries
are expected and updates the associated assert message to indicate the
developer should check the actual memory types against the expected
memory types if a size mismatch occurs.
- [ ] 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, ...
- [x] 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
- MdeModulePkg build and CI
- QemuQ35Pkg and QemuSbsaPkg build and boot with the change
## Integration Instructions
N/A
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Updates the requirements on
[edk2-pytool-library](https://github.com/tianocore/edk2-pytool-library)
to permit the latest version.
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: Michael Kubacki <michael.kubacki@microsoft.com>
## Description
Added a panic library to MdePkg. This provides an API to use for when an
unrecoverable error is hit during boot. It will print a message to the
debug console and have the system deadloop indefinitely.
It can be used by including the BasePanicLib implementation in your
module or library and calling `PANIC`. You can input your own custom
message to indicate what's triggering the `PANIC`.
- [x] 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
Tested on Intel physical devices. Confirmed that when a `PANIC` is hit
we get the expected message and we halt boot.
## Integration Instructions
Include the panic library in your platform dsc.
## Description
Adds a CI Plugin that verifies there is no nested package conflicts in
the target package.
This will eventually replace the check that occurs everytime Edk2Path is
instantiated in edk2-pytool-extensions.
- [ ] 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
Verified that manually adding nested packages are:
1. Detected and reported for the target package only
2. Reported but not build breaking when AuditOnly is true.
## Integration Instructions
N/A
---------
Signed-off-by: Joey Vagedes <joey.vagedes@gmail.com>
Co-authored-by: Michael Kubacki <michael.kubacki@microsoft.com>
## Description
By updating the version, users will be prompted to delete their Conf
directory so the new files with Rust support can be copied over.
- [ ] 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
- Local and CI build
## Integration Instructions
N/A - Expect that users with existing Conf directories will be notified
during
build to delete the directory so the new file content can be copied
over.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
## Description
* Remove support for datetime.utcnow() function as it is slated for
deprecation.
https://docs.python.org/3/library/datetime.html#datetime.datetime.utcnow
* Removed unused import of subprocess.
* Pull in change to FlattenPdbs.py to unblock build validation.
- [ ] 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, ...
- [x] Breaking change?
- **Breaking change** - Will anyone consuming this change experience a
break
in build or boot behavior?
Yes, anyone using Python 3.9 and older will no longer be able to use the
FlattenPdbs plug-in. Tangentially, this will cause builds to break that
include this plug-in if using Python 3.9 or older.
The fix is to upgrade python to 3.10 or newer.
- [ ] 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
* Verified override tag parsing and creation produced the correct UTC
time.
## Integration Instructions
N/A
Updates the requirements on
[edk2-pytool-library](https://github.com/tianocore/edk2-pytool-library)
to permit the latest version.
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
# Preface
Please ensure you have read the [contribution
docs](https://github.com/microsoft/mu/blob/master/CONTRIBUTING.md) prior
to submitting the pull request. In particular,
[pull request
guidelines](https://github.com/microsoft/mu/blob/master/CONTRIBUTING.md#pull-request-best-practices).
## Description
Python platform inquiry will return `Windows` and `ARM64` for OS name
and architecture, respectively.
This change will update the value to match that, and thus properly skip
rust coverage step from this plugin.
For each item, place an "x" in between `[` and `]` if true. Example:
`[x]`.
_(you can also check items in the GitHub UI)_
- [x] 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
This was tested on Windows ARM64 system.
## Integration Instructions
N/A
## Description
RustHostUnitTestPlugin is a plugin that is run when the scope "rust-ci"
is set, however the scope is set for an entire repository (for
`stuart_ci_build`) rather than on a per-package basis. This means that
the plugin is run for all packages in the repository, not just the
package containing a rust crate.
In the scenario where there are no rust crates in the package, the
coverage provider, tarpaulin, will not collect any coverage data and
return a failure, causing the plugin to fail. This commit skips the
plugin if it is detected that no crust crates exist in the 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, ...
- [ ] 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
CI
## Integration Instructions
N/A
## Description
Updates the RustHostUnitTestPlugin to allow the developer to enable or
disable the code coverage portion of the plugin.
Additionally fixes a bug in which doctests marked as ignored were still
causing the CI plugin to fail.
Additionally turns off code coverage if it detects its running on a
Windows ARM device as tarpaulin does not support that type of device.
- [ ] 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
CI
## Integration Instructions
CI
## Description
Create Google mock for ReadOnlyVariable2
Created a new PR for cleaner single-commit (also this one works)
Old PR: https://github.com/microsoft/mu_basecore/pull/530
- [ ] 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
Tested with ConfigKnobShimLib GoogleTest
## Integration Instructions
N/A
## Description
Makes multiple improvements to the RustHostUnitTestPlugin to support a
more reliable experience:
1. The plugin now fails when a test fails to compile or cargo tarpaulin
fails to run.
2. The plugin now logs the reason for failing as a warning in addition
to logging the output to the xml file.
3. The plugin now properly filters results to only include results of
rust crates inside the package being tested.
Closes#575
- [ ] 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
1. Verified only rust crates in the package being tested, are tested
2. Verified coverage results from rust crates being tested only show
coverage values of rust crates in that specific EDKII package (If a
crate has a dependency on another crate in a different EDKII package,
the coverage results for the other crate would show up.
3. Verified we properly log (and fail the plugin) when a test fails to
compile
4. Verified we properly log (and fail the plugin) when the command as a
whole fails for some reason
5. Verified we log (in addition to the xml log) the particular test that
is failing the plugin
## Integration Instructions
N/A
Updates the requirements on
[edk2-pytool-library](https://github.com/tianocore/edk2-pytool-library)
to permit the latest version.
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
## Description
When setting PcdPciDisableBusEnumeration to TRUE, an assert is hit in
StartPciDevices due to the RootBridge not existing. This is expected
when skipping enumeration so change the assert to only fail if
enumeration was not disabled.
- [ ] Impacts functionality?
- [ ] Impacts security?
- [ ] Breaking change?
- [ ] Includes tests?
- [ ] Includes documentation?
## How This Was Tested
Tested on QEMU Q35 platform
## Integration Instructions
N/A
## Description
When VariablePolicyFuncTestApp ends, the variable policy engine has been
disabled. To accomodate automated testing, reboot the system at the end
of the test suite to reset the variable policy state. The app already
reboots several times during execution to reset the variable policy
enablement/lock state.
- [x] 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
Tested on Q35
## Integration Instructions
N/A
## Description
Currently, HeapGuard, when in the GuardAlignedToTail mode, assumes that
the pool head has been allocated in the first page of memory that was
allocated. This is not the case for ARM64 platforms when allocating
runtime pools, as RUNTIME_PAGE_ALLOCATION_GRANULARITY is 64k, unlike
X64, which has RUNTIME_PAGE_ALLOCATION_GRANULARITY as 4k.
When a runtime pool is allocated on ARM64, the minimum number of pages
allocated is 16, to match the runtime granularity. When a small pool is
allocated and GuardAlignedToTail is true, HeapGuard instructs the pool
head to be placed as (MemoryAllocated + EFI_PAGES_TO_SIZE(Number of
Pages)
- SizeRequiredForPool).
This gives this scenario:
|Head Guard|Large Free Number of Pages|PoolHead|TailGuard|
When this pool goes to be freed, HeapGuard instructs the pool code to
free from (PoolHead & ~EFI_PAGE_MASK). However, this assumes that the
PoolHead is in the first page allocated, which as shown above is not
true in this case. For the 4k granularity case (i.e. where the correct
number of pages are allocated for this pool), this logic does work.
In this failing case, HeapGuard then instructs the pool code to free 16
(or more depending) pages from the page the pool head was allocated on,
which as seen above means we overrun the pool and attempt to free memory
far past the pool. We end up running into the tail guard and getting an
access flag fault.
This causes ArmVirtQemu to fail to boot with an access flag fault when
GuardAlignedToTail is set to true (and pool guard enabled for runtime
memory). It should also cause all ARM64 platforms to fail in this
configuration, for exactly the same reason, as this is core code making
the assumption.
This patch removes HeapGuard's assumption that the pool head is
allocated on the first page and instead undoes the same logic that
HeapGuard did when allocating the pool head in the first place.
With this patch in place, ArmVirtQemu boots with GuardAlignedToTail set
to true (and when it is false, also).
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4521
Github PR: https://github.com/tianocore/edk2/pull/4731
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
For each item, place an "x" in between `[` and `]` if true. Example:
`[x]`.
_(you can also check items in the GitHub UI)_
- [x] 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
Tested on ArmVirtQemu on edk2.
## Integration Instructions
N/A.
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Co-authored-by: Oliver Smith-Denny <osde@linux.microsoft.com>
## Description
To enable testing variable policy functionality in the shell, it needs
to be unlocked when the test starts. This PR adds a check to the system
device state and avoids locking if it is in unit test mode.
- [x] Impacts functionality?
- **Functionality** - Does the change ultimately impact how firmware
functions?
- Examples: Add a new library, publish a new PPI, update an algorithm,
...
- [x] 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
Tested by running the variable policy test app in Q35.
## Integration Instructions
N/A
## Description
Updates to latest to fix numerous bugs. Complete set of changes:
https://github.com/github/codeql-cli-binaries/compare/v2.12.4...v2.14.5
- [ ] Impacts functionality?
- **Functionality** - Does the change ultimately impact how firmware
functions?
- Examples: Add a new library, publish a new PPI, update an algorithm,
...
- [ ] Impacts security?
- **Security** - Does the change have a direct security impact on an
application,
flow, or firmware?
- Examples: Crypto algorithm change, buffer overflow fix, parameter
validation improvement, ...
- [ ] 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
In progresss.
## Integration Instructions
N/A - CodeQL change will be picked up through the plugin automatically.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
# Preface
Please ensure you have read the [contribution
docs](https://github.com/microsoft/mu/blob/master/CONTRIBUTING.md) prior
to submitting the pull request. In particular,
[pull request
guidelines](https://github.com/microsoft/mu/blob/master/CONTRIBUTING.md#pull-request-best-practices).
## Description
Added Ipmi Threshold sensor APIs and their NULL implementation in a new
file IpmiCommandLibNetFnSensor.c under MdeModulePkg
For each item, place an "x" in between `[` and `]` if true. Example:
`[x]`.
_(you can also check items in the GitHub UI)_
- [x] 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
Verified CI build is successful
## Integration Instructions
---------
Co-authored-by: Aaron <105021049+apop5@users.noreply.github.com>
## Description
PCIe's Max Payload Size controls the maximum packet size that can be
handled by a given device. The device's maximum supported MPS is
provided by the PCIe Device Capabilities Register, and the current MPS
is programmed in the Control Register. For a given Root Port, the MPS
should be the same value for all devices and bridges under that Root
Port. When the new PCD `PcdPcieInitializeMps` is set to TRUE, the
supported MPS will be collected as part of PCI device creation and after
all devices are enumerated under the Root Port, all devices and bridges
will have their MPS set to the optimum value.
This allows platforms to ensure that the optimum MPS is set across the
PCI tree before PCI devices are started. This can significantly improve
performance for PCI devices such as NVMe.
- [x] Impacts functionality?
- [ ] Impacts security?
- [ ] Breaking change?
- [ ] Includes tests?
- [ ] Includes documentation?
## How This Was Tested
Tested on virtual and physical platforms, OS boot tested.
## Integration Instructions
N/A
Co-authored-by: abrahamg <abrahamg@microsoft.com>
---------
Co-authored-by: abrahamg <abrahamg@microsoft.com>
## Description
RuntimeLibExitBootServicesEventCallback is defined and exported in two
locations, RuntimeLib and PolicyLib. This causes a linker error if both
libraries are linked to a module.
This patch both changes the name of the callback in PolicyLib (as this
was not an accurate name) and marks it STATIC, as this function should
not be called at all except for the function pointer that is registered
for the event firing.
Closes#565.
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, ...
- [ ] 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
Unit tests ran.
## Integration Instructions
N/A.
Updates the requirements on
[edk2-pytool-extensions](https://github.com/tianocore/edk2-pytool-extensions)
to permit the latest version.
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Updates the queries opted into by Project Mu available in the
standard CodeQL query package `codeql/cpp-queries`.
I tested many queries and found the included set here to be the
most useful with the least number of false positives. Some queries
had a number of issues that led to them being placed on the exclusion
list so they are not considered in the future without the notes there
being taken into account.
General details about queries available in the pack are available
here:
https://codeql.github.com/codeql-query-help/cpp/
The changelog for the query pack is available here:
https://github.com/github/codeql/blob/codeql-cli/latest/cpp/ql/src/CHANGELOG.md
The following new queries are enabled organized alphabetically
within sections grouped by type:
Errors:
- cpp/missing-return
- cpp/no-space-for-terminator
- cpp/pointer-overflow-check
- cpp/redundant-null-check-simple
- cpp/very-likely-overrunning-write
Warnings:
- cpp/comparison-precedence
- cpp/implicit-bitfield-downcast
- cpp/offset-use-before-range-check
- cpp/overflow-calculated
- cpp/overflow-destination
- cpp/return-stack-allocated-memory
- cpp/static-buffer-overflow
- cpp/unsigned-comparison-zero
Recommendations:
- cpp/missing-header-guard
- cpp/unused-local-variable
- cpp/unused-static-function
- cpp/unused-static-variable
The following queries are newly explicitly excluded as noted in the
file:
- cpp/allocation-too-small
- cpp/commented-out-code
- cpp/duplicate-include-guard
- cpp/invalid-pointer-deref
- cpp/useless-expression
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Many arrays are defined with a length of MAX_MENU_NUMBER in
FormGuid.h. Two of those are BootOptionOrder and DriverOptionOrder.
In UpdatePage.c, a pointer is set to either of those arrays. The
array buffer is accessed using an index whose range is checked after
the pointer to the array is dereferenced. This change moves the check
before the dereference.
In another place in the file, the ConsoleCheck pointer is also set to
an array buffer with MAX_MENU_NUMBER elements. Only an ASSERT()
currently checks the range of the array index. This change
conditionalizes the pointer dereference itself on the range of Index.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Moves the range check for the index into the array before attempting
to access the array element.
Cc: Zhichao Gao <zhichao.gao@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Removes the comparison since unsigned values are always greater than
or equal to 0.
See the following CodeQL query for more info:
/cpp/cpp-unsigned-comparison-zero/
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Cc: Rebecca Cran <rebecca@bsdio.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
joe
Joey Vagedes
Project Mu UEFI Bot [bot]
Michael Kubacki
Doug Flick
dependabot[bot]
Aaron
Antaeus Kleinert-Strand
Taylor Beebe
kenlautner
kuqin12
Vivian Nowka-Keane
Chris Fernald
Oliver Smith-Denny
v-bhavanisu