mu_tiano_platforms - v4.4.1

Published by github-actions[bot] about 1 year ago

What's Changed

There are several errors produced when building QemuQ35Pkg and QemuSbsaPkg indicating that some relative paths cannot be converted to absolute paths. This is because these paths do not exist in the code tree anymore.

This patch removes the unused env vars.

For each item, place an "x" in between [ and ] if true. Example: [x].
(you can also check items in the GitHub UI)

Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
Impacts security?
- Security - Does the change have a direct security impact on an application,
  flow, or firmware?
- Examples: Crypto algorithm change, buffer overflow fix, parameter
  validation improvement, ...
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

Still builds without these.

Integration Instructions

N/A.

🐛 Bug Fixes

All header files should have include guards.

See the following for more info:
https://codeql.github.com/codeql-query-help/cpp/cpp-missing-header-guard/

Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
Impacts security?
- Security - Does the change have a direct security impact on an application,
  flow, or firmware?
- Examples: Crypto algorithm change, buffer overflow fix, parameter
  validation improvement, ...
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 build
Ran CodeQL with cpp-missing-header-guard enabled

Integration Instructions

N/A

The virtual drive image is passed with the following parameter:

-hdd <VirtualDrivePath>

This results in the following warning:

WARNING: Image format was not specified for 'VirtualDrive.img' and
         probing guessed raw.

         Automatically detecting the format is dangerous for raw
         images, write operations on block 0 will be restricted.
         Specify the 'raw' format explicitly to remove the
         restrictions.

This passes the image using -drive to resolve the warning.

Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
Impacts security?
- Security - Does the change have a direct security impact on an application,
  flow, or firmware?
- Examples: Crypto algorithm change, buffer overflow fix, parameter
  validation improvement, ...
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

QemuQ35Pkg and QemuSbsaPkg build and run

Integration Instructions

N/A

🔐 Security Impacting

The physical presence check is a poor way to determine if a user is actually physically present at the machine. Because some security checks can be bypassed with physical presence, set physical presence to FALSE.

Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
Impacts security?
- Security - Does the change have a direct security impact on an application,
  flow, or firmware?
- Examples: Crypto algorithm change, buffer overflow fix, parameter
  validation improvement, ...
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 and SBSA

Integration Instructions

N/A

🛠️ Submodule Updates

Introduces 12 new commits in Features/CONFIG.

Signed-off-by: Project Mu Bot [email protected]

Introduces 4 new commits in MU_BASECORE.

Signed-off-by: Project Mu Bot [email protected]

Full Changelog: https://github.com/microsoft/mu_tiano_platforms/compare/v4.4.0...v4.4.1

mu_tiano_platforms - v4.4.0

Published by github-actions[bot] about 1 year ago

What's Changed

🚀 Features & ✨ Enhancements

Includes changes to add Rust build support to the repo, include a Rust
DXE driver (HelloWorldRustDxe) in the QemuQ35Pkg and QemuSbsaPkg
build and boot, and associated pipeline changes.

Change summary:

Add repo Rust infrastructure support

Adds files to support:

A cargo-make makefile
Default Rust toolchain version
Rust formatting configuration
Rust host-based unit test CI execution

Bump Common/MU from 2023020001.3.1 to 2023020001.4.0

Add HelloWorldRustDxe to QemuQ35Pkg and QemuSbsaPkg

Adds the driver to both packages to demonstrate a Rust based UEFI
DXE driver executing during boot on a X64 and AARCH64 system.

A workspace Cargo.toml file is added for cargo make. Since this repo
is the "leaf of a dependency chain" in that it builds binaries that
are integrated into the platform build, the Cargo.lock file is
checked in per the guidance in:
https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries

.azurepipelines: Add Rust support

Updates the repo pipelines to support Rust builds.

Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
Impacts security?
- Security - Does the change have a direct security impact on an application,
  flow, or firmware?
- Examples: Crypto algorithm change, buffer overflow fix, parameter
  validation improvement, ...
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 and Platform builds locally and in CI
Verified QemuQ35Pkg and QemuSbsaPkg builds
Verified HelloWorldRustDxe dispatches during boot and prints
the expected debug messages

Integration Instructions

N/A

Note: The MU_BASECORE submodule will be updated after https://github.com/microsoft/mu_basecore/pull/545 completes.

Full Changelog: https://github.com/microsoft/mu_tiano_platforms/compare/v4.3.1...v4.4.0

mu_tiano_platforms - v4.3.1

Published by github-actions[bot] about 1 year ago

What's Changed

Updates the repo for a change that merged UefiCpuLib with CpuLib.

UefiCpuLib will be removed entirely soon so all references are updated to CpuLib.

Includes the following submodule updates:

MU_BASECORE to v2023020005.0.1
Common/MU to v2023020001.4.1
Common/MU_TIANO to v2023020001.4.1
Features/MM_SUPV to v8.1.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

CI package build (via PR checks)

Integration Instructions

N/A

Associated Changes in Submodules

Full Changelog: https://github.com/microsoft/mu_tiano_platforms/compare/v4.3.0...v4.3.1

mu_tiano_platforms - v4.2.0

Published by github-actions[bot] about 1 year ago

What's Changed

🚀 Features & ✨ Enhancements

Description

This feature enables experimentation with controlling the TPM
measurements made by firmware. It allows a developer to craft
a TPM event log and have the replayed during boot. It is disabled
by default.

General feature information is available in its readme:

https://github.com/microsoft/mu_plus/blob/HEAD/TpmTestingPkg/TpmReplayPei/Readme.md

It is currently only planned to be used QemuQ35Pkg. It could be
enabled in QemuSbsaPkg in the future if there is interest.

Details about the feature in the context of QEMU, are described in
Platforms/Docs/Q35/Features/feature_tpm_replay.md in this change.

Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
Impacts security?
- Security - Does the change have a direct security impact on an application,
  flow, or firmware?
- Examples: Crypto algorithm change, buffer overflow fix, parameter
  validation improvement, ...
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

Input YAML to binary
Input JSON to binary
Input binary to YAML
Replay events on QEMU Q35 to PCRs
Verify event log in OS against the input file

Integration Instructions

See feature_tpm_replay.md.

Enable the feature in QemuQ35Pkg in the DSC file:

  DEFINE TPM_REPLAY_ENABLED = TRUE

Or, as a stuart_build argument:

> stuart_build -c Platforms/QemuQ35Pkg/PlatformBuild.py --flashrom TOOL_CHAIN_TAG=GCC5 BLD_*_TPM_ENABLE=TRUE \
               BLD_*_TPM_ENABLE=TRUE TPM_DEV=/tmp/mytpm1/swtpm-sock

Then, follow instructions to create the TPM Replay
event log and load it.

📖 Documentation Updates

Description

This feature enables experimentation with controlling the TPM
measurements made by firmware. It allows a developer to craft
a TPM event log and have the replayed during boot. It is disabled
by default.

General feature information is available in its readme:

https://github.com/microsoft/mu_plus/blob/HEAD/TpmTestingPkg/TpmReplayPei/Readme.md

It is currently only planned to be used QemuQ35Pkg. It could be
enabled in QemuSbsaPkg in the future if there is interest.

Details about the feature in the context of QEMU, are described in
Platforms/Docs/Q35/Features/feature_tpm_replay.md in this change.

Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
Impacts security?
- Security - Does the change have a direct security impact on an application,
  flow, or firmware?
- Examples: Crypto algorithm change, buffer overflow fix, parameter
  validation improvement, ...
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

Input YAML to binary
Input JSON to binary
Input binary to YAML
Replay events on QEMU Q35 to PCRs
Verify event log in OS against the input file

Integration Instructions

See feature_tpm_replay.md.

Enable the feature in QemuQ35Pkg in the DSC file:

  DEFINE TPM_REPLAY_ENABLED = TRUE

Or, as a stuart_build argument:

> stuart_build -c Platforms/QemuQ35Pkg/PlatformBuild.py --flashrom TOOL_CHAIN_TAG=GCC5 BLD_*_TPM_ENABLE=TRUE \
               BLD_*_TPM_ENABLE=TRUE TPM_DEV=/tmp/mytpm1/swtpm-sock

Then, follow instructions to create the TPM Replay
event log and load it.

🛠️ Submodule Updates

Introduces 1 new commits in MU_BASECORE.

Signed-off-by: Project Mu Bot [email protected]

Full Changelog: https://github.com/microsoft/mu_tiano_platforms/compare/v4.1.3...v4.2.0

mu_tiano_platforms - v4.1.1

Published by github-actions[bot] about 1 year ago

What's Changed

🐛 Bug Fixes

Two changes related to cleaning up library usage.

Clean up ResetSystemLib usage

Remove library class warning messages and consistently link reset
logic across phases.

Set all HwResetSystemLib instances to QEMU platform-specific
reset logic.
Set Standalone MM driver and core HwResetSystemLib instances
to BaseResetSystemLib.inf in QemuQ35Pkg.
QemuQ35Pkg:
- Add HwResetSystemLib library class to BaseResetSystemLib
  and DxeResetSystemLib library instances.
- Drop phase bindings in BaseResetSystemLib as content is not
  specific to those phases.

QemuSbsaPkg: Change SbsaQemuNorFlashLib library class

Updates the library class to the name used for the header file
in the DEC file and used in consuming code.

Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
Impacts security?
- Security - Does the change have a direct security impact on an application,
  flow, or firmware?
- Examples: Crypto algorithm change, buffer overflow fix, parameter
  validation improvement, ...
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

QemuQ35Pkg and QemuSbsaPkg build.

Integration Instructions

N/A - Changes local to the repo

🛠️ Submodule Updates

Introduces 4 new commits in MU_BASECORE.

Signed-off-by: Project Mu Bot [email protected]

Introduces 4 new commits in Features/CONFIG.

Signed-off-by: Project Mu Bot [email protected]

Introduces 5 new commits in Silicon/Arm/MU_TIANO.

Signed-off-by: Project Mu Bot [email protected]

Introduces 1 new commits in Features/MM_SUPV.

Signed-off-by: Project Mu Bot [email protected]

Introduces 2 new commits in Common/MU_OEM_SAMPLE.

Signed-off-by: Project Mu Bot [email protected]

Introduces 2 new commits in Common/MU.

Signed-off-by: Project Mu Bot [email protected]

Full Changelog: https://github.com/microsoft/mu_tiano_platforms/compare/v4.1.0...v4.1.1

mu_tiano_platforms - v4.0.2

Published by github-actions[bot] over 1 year ago

What's Changed

Please ensure you have read the contribution docs prior
to submitting the pull request. In particular,
pull request guidelines.

Description

This adds support for both VHD and QCOW2 images by using the extension to determine which storage rule should be used for qemu See Issue 607

For each item, place an "x" in between [ and ] if true. Example: [x].
(you can also check items in the GitHub UI)

Impacts functionality?
- Adds back functionality for qcow2 images
Impacts security?
- N/A
Breaking change?
- N/A
Includes tests?
- N/A
Includes documentation?
- N/A

How This Was Tested

This was used to run both a vhd image and a cow2 image, to confirm backward compatibility the resultant string was also compared

Integration Instructions

N/A

  </blockquote>
  <hr>
</details>

🛠️ Submodule Updates

Introduces 2 new commits in MU_BASECORE.

Signed-off-by: Project Mu Bot [email protected]

Introduces 5 new commits in Common/MU.

Signed-off-by: Project Mu Bot [email protected]

Introduces 7 new commits in Common/MU_OEM_SAMPLE.

Signed-off-by: Project Mu Bot [email protected]

Introduces 13 new commits in Features/MM_SUPV.

Signed-off-by: Project Mu Bot [email protected]

Full Changelog: https://github.com/microsoft/mu_tiano_platforms/compare/v4.0.1...v4.0.2

mu_tiano_platforms - v4.0.1

Published by github-actions[bot] over 1 year ago

What's Changed

🐛 Bug Fixes

Commit 5a01f4f updated the YAML file to use the Ubuntu container
but did not replace DNF with APT when installing OpenSSL.

This change allows the release pipeline to work when using the
Ubuntu container.

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

Release pipeline.

Integration Instructions

N/A

Full Changelog: https://github.com/microsoft/mu_tiano_platforms/compare/v4.0.0...v4.0.1

mu_tiano_platforms - v4.0.0

Published by github-actions[bot] over 1 year ago

What's Changed

Removes "TARGET_ARCH" and "ACTIVE_PLATFORM" from being set inside the RetrieveCommandLineOptions() function. These are already set in the SetPlatformEnv() function, which is the common place for them to be set.

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

  </blockquote>
  <hr>
</details>

Adds a PrEval entry into the ci.yaml file, used for PrEval to evaluate the newly added policy 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

No tests necessary

Integration Instructions

N/A

  </blockquote>
  <hr>
</details>

Remove unnecessary exemptions and extend lingering exemptions two weeks.

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 pipelines

Integration Instructions

N/A

Update platform CI and .devcontainer to use the project MU dev containers. For more information see https://github.com/microsoft/mu_devops/tree/main/Containers.

Impacts functionality?
Impacts security?
Breaking change?
Includes tests?
Includes documentation?

How This Was Tested

Local tests and CI pipeline

Integration Instructions

N/A

  </blockquote>
  <hr>
</details>

Please ensure you have read the contribution docs prior
to submitting the pull request. In particular,
pull request guidelines.

Description

This change added the SBSA builds on self-hosted ARM systems. This work was left out because we need a change from BaseTools to resolve a build break when using native ARM gcc compiler, which we have now in 202302 mu_basecore.

This change resolves https://github.com/microsoft/mu_basecore/issues/369.

For each item, place an "x" in between [ and ] if true. Example: [x].
(you can also check items in the GitHub UI)

Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
Impacts security?
- Security - Does the change have a direct security impact on an application,
  flow, or firmware?
- Examples: Crypto algorithm change, buffer overflow fix, parameter
  validation improvement, ...
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

Pipeline builds and run passes.

Integration Instructions

N/A

  </blockquote>
  <hr>
</details>

Update MU_BASECORE submodule. Main changes are the base tools binary updates.

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

CI

Integration Instructions

N/A

  </blockquote>
  <hr>
</details>

⚠️ Breaking Changes

Please ensure you have read the contribution docs prior
to submitting the pull request. In particular,
pull request guidelines.

Description

Update OEM sample repo to v2023020000.0.2 and mu_feature_config repo to v0.3.4 for mu_tiano_platforms.

The corresponding configuration module usage is also simplified to pair with the submodule changes.

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

Tested locally on Q35 and SBSA.

Integration Instructions

Added a new configuration build variable for profile names on Q35 platform.

🐛 Bug Fixes

Please ensure you have read the contribution docs prior
to submitting the pull request. In particular,
pull request guidelines.

Description

This change removed the individual policy initializers from platform level since they are centralized to ConfigKnobs.

This change also removed the Depex in ConfigKnobs driver to fix the dependency change.

Fixes https://github.com/microsoft/mu_tiano_platforms/issues/610.

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

This change was tested on QemuSbsa and booted to Windows. The QemuQ35 is also tested and booted to shell.

Integration Instructions

N/A

  </blockquote>
  <hr>
</details>

🔐 Security Impacting

Changed the openssl inf version used to be the full version to match expected functionality. Additionally disabled NETWORK_ISCSI_ENABLE as we weren't using it.

Extra crypto functionality include:

Every SHA hash function. The default openssl version support SHA256 only.
X509 full functionality (this is connected with item 3)
ECC for TLS and other crypto features (item #2)

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

Passed BaseCryptLib Unit Tests.

Integration Instructions

N/A

  </blockquote>
  <hr>
</details>

Please ensure you have read the contribution docs prior
to submitting the pull request. In particular,
pull request guidelines.

Description

Current SBSA is using timer based RngLib, which is not appropriate as an example. This change updated the library to be instruction based.

Note that this instruction may not be available on all instructions sets.

The change also updates to the latest TFA release for our own housekeeping.

Fixes https://github.com/microsoft/mu_tiano_platforms/issues/616.

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

Booted SBSA platform firmware to Windows desktop.

Integration Instructions

N/A

  </blockquote>
  <hr>
</details>

🛠️ Submodule Updates

Introduces 3 new commits in MU_BASECORE.

Signed-off-by: Project Mu Bot [email protected]

Introduces 5 new commits in Features/CONFIG.

Signed-off-by: Project Mu Bot [email protected]

Introduces 2 new commits in MU_BASECORE.

Signed-off-by: Project Mu Bot [email protected]

Introduces 1 new commits in Silicon/Arm/MU_TIANO.

Signed-off-by: Project Mu Bot [email protected]

Introduces 5 new commits in Common/MU_TIANO.

Signed-off-by: Project Mu Bot [email protected]

Introduces 6 new commits in MU_BASECORE.

Signed-off-by: Project Mu Bot [email protected]

Introduces 3 new commits in Common/MU_OEM_SAMPLE.

Signed-off-by: Project Mu Bot [email protected]

Introduces 1 new commits in Common/MU.

Signed-off-by: Project Mu Bot [email protected]

Introduces 18 new commits in MU_BASECORE.

Signed-off-by: Project Mu Bot [email protected]

Introduces 1 new commits in Silicon/Arm/MU_TIANO.

Signed-off-by: Project Mu Bot [email protected]

Please ensure you have read the contribution docs prior
to submitting the pull request. In particular,
pull request guidelines.

Description

Update OEM sample repo to v2023020000.0.2 and mu_feature_config repo to v0.3.4 for mu_tiano_platforms.

The corresponding configuration module usage is also simplified to pair with the submodule changes.

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

Tested locally on Q35 and SBSA.

Integration Instructions

Added a new configuration build variable for profile names on Q35 platform.

Full Changelog: https://github.com/microsoft/mu_tiano_platforms/compare/v3.0.1...v4.0.0

mu_tiano_platforms - v3.0.1

Published by github-actions[bot] over 1 year ago

What's Changed

🔐 Security Impacting

Updates mu_tiano_platforms to use the new release/202302 branches of MU. Additionally, renamed VmgExitLib to CcExitLib along with it's associated functions and changed reference openssl inf. Lastly, added the VirtNorFlashStandaloneMm driver for QemuSbsa.

Moved Feature/MM_SUPV from v7.3.2 to v8.1.0
Moved Feature/DFCI from v3.0.0 to top of tree (no new release since v3.0.0)
Moved MU_BASECORE from v2022080002.0.2 to v2023020002.0.0

Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
Impacts security?
- Security - Does the change have a direct security impact on an application,
  flow, or firmware?
- Examples: Crypto algorithm change, buffer overflow fix, parameter
  validation improvement, ...
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

Built and booted QemuQ35 without any problems.

Integration Instructions

Just update to this branch or later.

📖 Documentation Updates

Updates mu_tiano_platforms to use the new release/202302 branches of MU. Additionally, renamed VmgExitLib to CcExitLib along with it's associated functions and changed reference openssl inf. Lastly, added the VirtNorFlashStandaloneMm driver for QemuSbsa.

Moved Feature/MM_SUPV from v7.3.2 to v8.1.0
Moved Feature/DFCI from v3.0.0 to top of tree (no new release since v3.0.0)
Moved MU_BASECORE from v2022080002.0.2 to v2023020002.0.0

Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
Impacts security?
- Security - Does the change have a direct security impact on an application,
  flow, or firmware?
- Examples: Crypto algorithm change, buffer overflow fix, parameter
  validation improvement, ...
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

Built and booted QemuQ35 without any problems.

Integration Instructions

Just update to this branch or later.

Full Changelog: https://github.com/microsoft/mu_tiano_platforms/compare/v3.0.0...v3.0.1

mu_tiano_platforms - v3.0.0

Published by github-actions[bot] over 1 year ago

What's Changed

⚠️ Breaking Changes

Set the Type 1 and Type 3 serial numbers to different values. This allows one to see the that UI App has chosen the correct serial number to display. It also is the source for the Type 1 serial number that DfciDeviceIdLib uses to inform InTune of the device Serial Number. The latest test cases will verify the correct serial number.

Used in testing Issue microsoft/mu_oem_sample#102

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 - Potentially a code break if the wrong serial number has been used in the past.
Includes tests?
- Tests - The latest Dfci Test cases will verify the correct serial number.
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 QemuQ35Plg

Integration Instructions

N/A

  </blockquote>
  <hr>
</details>

Full Changelog: https://github.com/microsoft/mu_tiano_platforms/compare/v2.4.4...v3.0.0

mu_tiano_platforms - v2.4.4

Published by github-actions[bot] over 1 year ago

What's Changed

Updates the pipeline to pass a matrix object to the Platform-Build-Job.yml
template.
Uses the main branch of mu_devops instead of a version since the version
is not automatically updated in this file and tends to drift out-of-date.

How This Was Tested

Performed a test release on a mu_devops fork.

Integration Instructions

N/A - No user visible changes

Full Changelog: https://github.com/microsoft/mu_tiano_platforms/compare/v2.4.3...v2.4.4

mu_tiano_platforms - v2.4.3

Published by github-actions[bot] over 1 year ago

What's Changed

Please ensure you have read the contribution docs prior
to submitting the pull request. In particular,
pull request guidelines.

Description

This change added a few new matrix entries to support building mu_tiano_platforms on native ARM64 systems. The PR will cover both https://github.com/microsoft/mu_basecore/issues/369 and https://github.com/microsoft/mu_basecore/issues/305.

The running steps on Windows ARM64 is separated from building due to the lack of support on QEMU Windows-ARM64.

QEMU SBSA building on Linux ARM is temporarily disabled due to a change needed from BaseTools: . This is pending to be added when release/202302 is available.

For each item, place an "x" in between [ and ] if true. Example: [x].
(you can also check items in the GitHub UI)

Impacts functionality?
- Functionality - Does the change ultimately impact how firmware functions?
- Examples: Add a new library, publish a new PPI, update an algorithm, ...
Impacts security?
- Security - Does the change have a direct security impact on an application,
  flow, or firmware?
- Examples: Crypto algorithm change, buffer overflow fix, parameter
  validation improvement, ...
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 selfhost-agents and existing agents.

Integration Instructions

Pipeline changes, N/A for integration.

  </blockquote>
  <hr>
</details>

🐛 Bug Fixes

📖 Documentation Updates

Some relative links were broken when the documentation was moved. This PR fixes those broken relative links and removes some sections which don't apply.

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

N/A

  </blockquote>
  <hr>
</details>

Full Changelog: https://github.com/microsoft/mu_tiano_platforms/compare/v2.4.2...v2.4.3

mu_tiano_platforms - v2.4.2

Published by github-actions[bot] over 1 year ago

What's Changed

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

CI

Integration Instructions

N/A

  </blockquote>
  <hr>
</details>

Windows Builds 25855+ require the POPCNT CPU feature. This PR adds this option to the Q35 CPU options when launching QEMU to ensure compatibility.

Impacts functionality?
Impacts security?
Breaking change?
Includes tests?
Includes documentation?

How This Was Tested

Tested on Windows boot locally.

Integration Instructions

N/A

  </blockquote>
  <hr>
</details>

📖 Documentation Updates

Fixes #470.

PRE-REQ. This PR requires the following PR's before this one will work correctly:
https://github.com/microsoft/mu_tiano_platforms/pull/473
https://github.com/microsoft/mu_tiano_platforms/pull/471
https://github.com/microsoft/mu_feature_dfci/pull/84

This PR will have to bump DfciPkg to include PR 84 above before it is completed.

This change adds the prereqs for DFCI - that is, platform specific libraries required to interface between DFCI and a particular platform. The required DFCI libraries are in PR 471. A convenience PR for booting to FrontPage or with certain USB device mounted is also require (PR 473).

Impacts functionality?
Impacts security?
Breaking change?
Includes tests?
Includes documentation?

How This Was Tested

With all of the prerequisites included, a Q35 Virtual System was used to run the Dfci End to End UnitTest with satisfactory results. That is, all of the test cases ran will full success except Dfci_IntuneSettings - which exhibits some know errors. This is not fixed due to another pending change.

Integration Instructions

N/A

  </blockquote>
  <hr>
</details>

🛠️ Submodule Updates

You can trigger a rebase of this PR by commenting @dependabot rebase.

You can trigger Dependabot actions by commenting on this PR:

@dependabot rebase will rebase this PR
@dependabot recreate will recreate this PR, overwriting any edits that have been made to it
@dependabot merge will merge this PR after your CI passes on it
@dependabot squash and merge will squash and merge this PR after your CI passes on it
@dependabot cancel merge will cancel a previously requested merge and block automerging
@dependabot reopen will reopen this PR if it is closed
@dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
@dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Introduces 10 new commits in MU_BASECORE.

Signed-off-by: Project Mu Bot [email protected]

You can trigger a rebase of this PR by commenting @dependabot rebase.

You can trigger Dependabot actions by commenting on this PR:

@dependabot rebase will rebase this PR
@dependabot recreate will recreate this PR, overwriting any edits that have been made to it
@dependabot merge will merge this PR after your CI passes on it
@dependabot squash and merge will squash and merge this PR after your CI passes on it
@dependabot cancel merge will cancel a previously requested merge and block automerging
@dependabot reopen will reopen this PR if it is closed
@dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
@dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

You can trigger a rebase of this PR by commenting @dependabot rebase.

You can trigger Dependabot actions by commenting on this PR:

@dependabot rebase will rebase this PR
@dependabot recreate will recreate this PR, overwriting any edits that have been made to it
@dependabot merge will merge this PR after your CI passes on it
@dependabot squash and merge will squash and merge this PR after your CI passes on it
@dependabot cancel merge will cancel a previously requested merge and block automerging
@dependabot reopen will reopen this PR if it is closed
@dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
@dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

You can trigger a rebase of this PR by commenting @dependabot rebase.

You can trigger Dependabot actions by commenting on this PR:

@dependabot rebase will rebase this PR
@dependabot recreate will recreate this PR, overwriting any edits that have been made to it
@dependabot merge will merge this PR after your CI passes on it
@dependabot squash and merge will squash and merge this PR after your CI passes on it
@dependabot cancel merge will cancel a previously requested merge and block automerging
@dependabot reopen will reopen this PR if it is closed
@dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
@dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

You can trigger a rebase of this PR by commenting @dependabot rebase.

You can trigger Dependabot actions by commenting on this PR:

@dependabot rebase will rebase this PR
@dependabot recreate will recreate this PR, overwriting any edits that have been made to it
@dependabot merge will merge this PR after your CI passes on it
@dependabot squash and merge will squash and merge this PR after your CI passes on it
@dependabot cancel merge will cancel a previously requested merge and block automerging
@dependabot reopen will reopen this PR if it is closed
@dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
@dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

You can trigger a rebase of this PR by commenting @dependabot rebase.

You can trigger Dependabot actions by commenting on this PR:

@dependabot rebase will rebase this PR
@dependabot recreate will recreate this PR, overwriting any edits that have been made to it
@dependabot merge will merge this PR after your CI passes on it
@dependabot squash and merge will squash and merge this PR after your CI passes on it
@dependabot cancel merge will cancel a previously requested merge and block automerging
@dependabot reopen will reopen this PR if it is closed
@dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
@dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

You can trigger a rebase of this PR by commenting @dependabot rebase.

You can trigger Dependabot actions by commenting on this PR:

@dependabot rebase will rebase this PR
@dependabot recreate will recreate this PR, overwriting any edits that have been made to it
@dependabot merge will merge this PR after your CI passes on it
@dependabot squash and merge will squash and merge this PR after your CI passes on it
@dependabot cancel merge will cancel a previously requested merge and block automerging
@dependabot reopen will reopen this PR if it is closed
@dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
@dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

You can trigger a rebase of this PR by commenting @dependabot rebase.

You can trigger Dependabot actions by commenting on this PR:

@dependabot rebase will rebase this PR
@dependabot recreate will recreate this PR, overwriting any edits that have been made to it
@dependabot merge will merge this PR after your CI passes on it
@dependabot squash and merge will squash and merge this PR after your CI passes on it
@dependabot cancel merge will cancel a previously requested merge and block automerging
@dependabot reopen will reopen this PR if it is closed
@dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
@dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

You can trigger a rebase of this PR by commenting @dependabot rebase.

You can trigger Dependabot actions by commenting on this PR:

@dependabot rebase will rebase this PR
@dependabot recreate will recreate this PR, overwriting any edits that have been made to it
@dependabot merge will merge this PR after your CI passes on it
@dependabot squash and merge will squash and merge this PR after your CI passes on it
@dependabot cancel merge will cancel a previously requested merge and block automerging
@dependabot reopen will reopen this PR if it is closed
@dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
@dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

You can trigger a rebase of this PR by commenting @dependabot rebase.

You can trigger Dependabot actions by commenting on this PR:

@dependabot rebase will rebase this PR
@dependabot recreate will recreate this PR, overwriting any edits that have been made to it
@dependabot merge will merge this PR after your CI passes on it
@dependabot squash and merge will squash and merge this PR after your CI passes on it
@dependabot cancel merge will cancel a previously requested merge and block automerging
@dependabot reopen will reopen this PR if it is closed
@dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
@dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

You can trigger a rebase of this PR by commenting @dependabot rebase.

You can trigger Dependabot actions by commenting on this PR:

@dependabot rebase will rebase this PR
@dependabot recreate will recreate this PR, overwriting any edits that have been made to it
@dependabot merge will merge this PR after your CI passes on it
@dependabot squash and merge will squash and merge this PR after your CI passes on it
@dependabot cancel merge will cancel a previously requested merge and block automerging
@dependabot reopen will reopen this PR if it is closed
@dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
@dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Full Changelog: https://github.com/microsoft/mu_tiano_platforms/compare/v2.4.1...v2.4.2

mu_tiano_platforms - v2.4.1

Published by github-actions[bot] over 1 year ago

What's Changed

Picks up commit https://github.com/microsoft/mu_devops/commit/13b0ab797c96cd1ac47ec15436fadacd41808c3f
which is needed to successfully run Platform-Build-Job.yml as of
commit e0b43e2.

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

Release pipeline.

Integration Instructions

N/A - Impacts local repo releases

Full Changelog: https://github.com/microsoft/mu_tiano_platforms/compare/v2.4.0...v2.4.1

mu_tiano_platforms - v2.4.0

Published by github-actions[bot] over 1 year ago

What's Changed

You can trigger a rebase of this PR by commenting @dependabot rebase.

You can trigger Dependabot actions by commenting on this PR:

@dependabot rebase will rebase this PR
@dependabot recreate will recreate this PR, overwriting any edits that have been made to it
@dependabot merge will merge this PR after your CI passes on it
@dependabot squash and merge will squash and merge this PR after your CI passes on it
@dependabot cancel merge will cancel a previously requested merge and block automerging
@dependabot reopen will reopen this PR if it is closed
@dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
@dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

You can trigger a rebase of this PR by commenting @dependabot rebase.

You can trigger Dependabot actions by commenting on this PR:

@dependabot rebase will rebase this PR
@dependabot recreate will recreate this PR, overwriting any edits that have been made to it
@dependabot merge will merge this PR after your CI passes on it
@dependabot squash and merge will squash and merge this PR after your CI passes on it
@dependabot cancel merge will cancel a previously requested merge and block automerging
@dependabot reopen will reopen this PR if it is closed
@dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
@dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

The update to use a helper plugin for virtual drive managment changed the way we filter tests. Instead of report_results() checking for exempt tests during the report, the Q35 and SBSA platforms would filter out exempt tests from the test list passed to report_results(). As a result, the exempt unit tests would not have their XMLs copied to unit_test_results or have a summary of their results dumped via logging even if the tests passed.

This PR creates a second list containing only the exempt tests and passes that to report_results(). By ignoring the output of report_results() when passing in the exempt test list, we effectively ignore the failures.

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

Running on Q35 and SBSA

Integration Instructions

N/A

  </blockquote>
  <hr>
</details>

🚀 Features & ✨ Enhancements

  </blockquote>
  <hr>
</details>

Add a step when adding unit tests to the startup.nsh file to add a second run of DxePagingAuditTestApp with the '-d' parameter to dump the paging audit files. When reporting results, extract the paging audit files and create the audit.

With this update, every CI run will contain the paging audit in the artifacts. Also, whenever DxePagingAuditTestApp.efi is included in a Q35 or SBSA TEST_REGEX, the paging audit will be created and deposited into the unit_test_results 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, ...
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

Build and run on SBSA and Q35

Integration Instructions

N/A

🛠️ Submodule Updates

  </blockquote>
  <hr>
</details>

You can trigger a rebase of this PR by commenting @dependabot rebase.

You can trigger Dependabot actions by commenting on this PR:

@dependabot rebase will rebase this PR
@dependabot recreate will recreate this PR, overwriting any edits that have been made to it
@dependabot merge will merge this PR after your CI passes on it
@dependabot squash and merge will squash and merge this PR after your CI passes on it
@dependabot cancel merge will cancel a previously requested merge and block automerging
@dependabot reopen will reopen this PR if it is closed
@dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
@dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Introduces 6 new commits in MU_BASECORE.

Also updates Features/MM_SUPV to include an override hash update required
with this Mu Basecore update.

Signed-off-by: Project Mu Bot [email protected]

You can trigger a rebase of this PR by commenting @dependabot rebase.

You can trigger Dependabot actions by commenting on this PR:

@dependabot rebase will rebase this PR
@dependabot recreate will recreate this PR, overwriting any edits that have been made to it
@dependabot merge will merge this PR after your CI passes on it
@dependabot squash and merge will squash and merge this PR after your CI passes on it
@dependabot cancel merge will cancel a previously requested merge and block automerging
@dependabot reopen will reopen this PR if it is closed
@dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
@dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

You can trigger a rebase of this PR by commenting @dependabot rebase.

You can trigger Dependabot actions by commenting on this PR:

@dependabot rebase will rebase this PR
@dependabot recreate will recreate this PR, overwriting any edits that have been made to it
@dependabot merge will merge this PR after your CI passes on it
@dependabot squash and merge will squash and merge this PR after your CI passes on it
@dependabot cancel merge will cancel a previously requested merge and block automerging
@dependabot reopen will reopen this PR if it is closed
@dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
@dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

You can trigger a rebase of this PR by commenting @dependabot rebase.

You can trigger Dependabot actions by commenting on this PR:

@dependabot rebase will rebase this PR
@dependabot recreate will recreate this PR, overwriting any edits that have been made to it
@dependabot merge will merge this PR after your CI passes on it
@dependabot squash and merge will squash and merge this PR after your CI passes on it
@dependabot cancel merge will cancel a previously requested merge and block automerging
@dependabot reopen will reopen this PR if it is closed
@dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
@dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Full Changelog: https://github.com/microsoft/mu_tiano_platforms/compare/v2.3.0...v2.4.0