Initial Release notes of 202405 contain a full list of mu changes on top of edk2-stable202405

PR associated with the commit can be found at the bottom of the information pane reached by clicking on the commit hash

What's Changed## 🚀 Features & ✨ Enhancements

What's Changed

🚀 Features & ✨ Enhancements

The RngPei PEIM can be used if RNG should be provided over a dynamic
binary interface to other PEIMs on a platform.

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

How This Was Tested

• SecurityPkg CI
• Verify RNG linked with RngLib is executed as expected
• Verify random numbers are generated successfully with a valid RngLib

Integration Instructions

Use the RngPei module if a platform needs to produce gEfiRngPpiGuid.

The platform should usually link a different RngLib instance to RngPei
than other PEIMs that may use the RNG PPI produced since RngPei is responsible
for producing the PPI.

For example, a RngLib instance that uses the rdrand instruction may be linked
against RngPei and a RngLib instance that uses the RNG PPI may be linked
against other PEIMs.

Full Changelog: https://github.com/microsoft/mu_tiano_plus/compare/v2023110001.0.1...v2023110001.1.0

What's Changed

🚀 Features & ✨ Enhancements

The RngPei PEIM can be used if RNG should be provided over a dynamic
binary interface to other PEIMs on a platform.

(cherry picked from mu_basecore/release/202311)

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

How This Was Tested

• SecurityPkg CI
• Verify RNG linked with RngLib is executed as expected
• Verify random numbers are generated successfully with a valid RngLib

Integration Instructions

Use the RngPei module if a platform needs to produce gEfiRngPpiGuid.

The platform should usually link a different RngLib instance to RngPei
than other PEIMs that may use the RNG PPI produced since RngPei is responsible
for producing the PPI.

For example, a RngLib instance that uses the rdrand instruction may be linked
against RngPei and a RngLib instance that uses the RNG PPI may be linked
against other PEIMs.

Full Changelog: https://github.com/microsoft/mu_tiano_plus/compare/v2023020001.0.1...v2023020001.1.0

What's Changed

Resolves #275

CHANGE 1:

SecurityPkg: Restore DeviceSecurity (and libspdm submodule)

Reverts the following commit:

"SecurityPkg: Temporarily remove DeviceSecurity (and libspdm) from build"
(11506d59b72515a8d561baddfa2bb6660924ad6e)

The libspdm submodule is updated in the following commit to use a
cmocka from a more reliable host (GitLab). This revert is necessary
for that cherry-pick from edk2 to apply.

CHANGE 2:

[CHERRY-PICK] SecurityPkg: Update libspdm submodule to use GitLab cmocka repo

As noted in https://github.com/DMTF/libspdm/issues/2707, the cmocka
submodule on cryptomilk is unreliable and impacting downstream
consumer builds of SecurityPkg. This is considered a regression in
that pre-existing workflows that clone and recursively initialize
the repo are now broken.

The cmocka host was switched to a more reliable gitlab host in
https://github.com/DMTF/libspdm/pull/2710. This change updates the
submodule in edk2 to use that commit so edk2 users are not blocked
by cryptomilk.org service issues.

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

How This Was Tested

• SecurityPkg CI build

Integration Instructions

• First, note that this PR reverts PR https://github.com/microsoft/mu_tiano_plus/pull/272.
  • Review any changes you may have made in response to that PR.
• This PR adds the DeviceSecurity code back to the SecurityPkg build. That should not impact downstream users as the code was not removed, only not built in SecurityPkg.
• The libspdm submodule is added back. That submodule will now be present for downstream repos (and SecurityPkg code) to use.
  
  

Full Changelog: https://github.com/microsoft/mu_tiano_plus/compare/v2023110001.0.0...v2023110001.0.1

What's Changed

⚠️ Breaking Changes

The SecurityPkg/DeviceSecurity/SpdmLib/libspdm submodule contains a
unit_test/cmockalib/cmocka submodule to https://git.cryptomilk.org/projects/cmocka.git.

cryptomilk.org is very unreliable and breaking all builds right now.
Since the DeviceSecurity content is not actively used in any main
branches, this change removes the libspdm submodule from the package
which, in turn, leads to removal of the content dependent on the
submodule.

These changes are made such that this commit can be reverted in the future.

That will easily restore everything after the libspdm submodule is updated
to find a more reliable host than cryptomilk.org.

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

How This Was Tested

• SecurityPkg CI build

Integration Instructions

• This is a temporary change. It is expected to be reverted soon.
  • If you depend on the libspdm submodule in SecurityPkg, it is
    recommended to stay on the commit prior to its removal and wait
    for it to be restored in a future commit.
  • If you do not depend on the libspdm submodule, there is not impact.
• If you pick up this change be aware that any files in your build
  dependent on the libspdm submodule will fail.
  
  

Full Changelog: https://github.com/microsoft/mu_tiano_plus/compare/v2023110000.1.0...v2023110001.0.0

What's Changed

Description

The current dTPM library instance only supports MM_STANDALONE, which makes the MM core module unable to use this instance.

This change expands the support for this library to cover MM_CORE_STANDALONE as well.

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 QEMU Q35 and verified bootable to UEFI shell.

Integration Instructions

N/A

🚀 Features & ✨ Enhancements

Description

This cherry-pick series includes the SecurityPkg patches to support SPDM device authentication and measurement.

• Adds the libspdm submodule - A SPDM implementation in the DMTF repo.

• Adds TCG PFP 1.06 support - Adds support for the Tpm2ExtendNvIndex() API.

• Adds core Device Security libraries in SecurityPkg

• 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

• EDK II testing
• Tests in DeviceSecurityTestPkg

Integration Instructions

• See some integration examples in DeviceSecurityTestPkg
• This change depends on the Mu Basecore changes in https://github.com/microsoft/mu_basecore/pull/846. You must ensure those changes are also in your repo.
  
  

🔐 Security Impacting

Description

This cherry-pick series includes the SecurityPkg patches to support SPDM device authentication and measurement.

• Adds the libspdm submodule - A SPDM implementation in the DMTF repo.

• Adds TCG PFP 1.06 support - Adds support for the Tpm2ExtendNvIndex() API.

• Adds core Device Security libraries in SecurityPkg

• 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

• EDK II testing
• Tests in DeviceSecurityTestPkg

Integration Instructions

• See some integration examples in DeviceSecurityTestPkg
• This change depends on the Mu Basecore changes in https://github.com/microsoft/mu_basecore/pull/846. You must ensure those changes are also in your repo.
  
  

Full Changelog: https://github.com/microsoft/mu_tiano_plus/compare/v2023110000.0.5...v2023110000.1.0

What's Changed

Currently, if the TCG log fills up, the firmware will boot only logging some errors and the OS may or may not fail depending on scenario and configuration. This PR adds an assert so that these truncations can be found in testing rather then having to wait for failures in production.

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

How This Was Tested

N/A

Integration Instructions

N/A

Full Changelog: https://github.com/microsoft/mu_tiano_plus/compare/v2023110000.0.4...v2023110000.0.5

What's Changed

An instance of StackCheckLib must be in each DSC to accommodate -fstack-protector and /GS flags.

• 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 in pipelines

Integration Instructions

N/A

Full Changelog: https://github.com/microsoft/mu_tiano_plus/compare/v2023020001.0.0...v2023020001.0.1

What's Changed

An instance of StackCheckLib must be in each DSC to accommodate -fstack-protector and /GS flags.

• 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 in pipelines

Integration Instructions

N/A

Description

This reverts the revert where we reverted the update that supports SHA384 and SHA512.

When ProcessVarWithPk(..) is called the expected code path is that you are in CUSTOM MODE and a UserPhysicallyPresent. Neither of which Project MU does or supports. So we end up falling down into VerifyTimeBasedPayloadAndUpdate(..). From there we fall into VerifyTimeBasedPayload and then finally we were depending on a special case where the size wasn't checked to hit the following line

 // If the VariablePolicy engine is disabled, allow deletion of any authenticated variables.
 if ((PayloadSize == 0) && ((Attributes & EFI_VARIABLE_APPEND_WRITE) == 0) && !IsVariablePolicyEnabled ()) {
   VerifyStatus = TRUE;
   goto Exit;
 }

This would work in 202302 and before allow us to delete the PK. However in this commit the logic to detect digest algorithm was changed and now prevents any payload with an invalid signature size (such as a PK Delete payload) from working.

History:

1. Original Commit From EDK2
2. Cherry-pick into MU_TIANO_PLUS
3. Partial Revert to remove unnecessary logic

Bug seen where PK cannot be deleted
See Issue #246

1. Revert "SecurityPkg/SecureBoot: Support RSA4096 and RSA3072" and follow up change
2. Revert "SecurityPkg/SecureBoot: Support RSA4096 and RSA3072"

This patch series contains the original two commits and the bug fix

1. Cherry-pick into MU_TIANO_PLUS
2. Partial Revert to remove unnecessary logic
3. SecurityPkg/SecureBoot: Support special case where PK is being deleted.

Effectively this adds a special case where if the signature is 0

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 - Allows for a PK to be deleted
• Impacts security?
  • Security - No
• Breaking change?
  • Breaking change - No
• Includes tests?
  • Tests - No
• Includes documentation?
  • Documentation - No

How This Was Tested

1. Boot QemuQ35
2. Enable Secure Boot with the Microsoft Only Certificates
3. Boot to the Front Page
4. Go to the Security Tab - Reboot to Front Page
5. Disable Secure Boot by selecting None
6. If broken firmware will assert
7. otherwise proceed

Additionally, confirmed that authenticated variables with valid signature data using the hash algorithms SHA256, SHA384 and SHA512 still work.

Integration Instructions

N/A

Description

Pipeline just started picking up a spelling mistake in a log message in a unit test

• Impacts functionality?
  • Functionality - No
• Impacts security?
  • Security - No
• Breaking change?
  • Breaking change - No
• Includes tests?
  • Tests - No
• Includes documentation?
  • Documentation - No

How This Was Tested

N/A

Integration Instructions

N/A

Reverts commit https://github.com/microsoft/mu_tiano_plus/commit/36b848b39cdfe644a22c50f5421f873f3015e81f.
Reverts commit https://github.com/microsoft/mu_tiano_plus/commit/bbf182229587958b17336c114e0a1525c4f90f3d.

This change has created an issue where the PK cannot be deleted after creation because of a hashing signature mismatch. This change is to revert the offending change until this issue can be further debugged.

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

How This Was Tested

Tested oh physical platform

Integration Instructions

N/A

Full Changelog: https://github.com/microsoft/mu_tiano_plus/compare/v2023110000.0.3...v2023110000.0.4

What's Changed

Move the range check before array access to enforce the bounds
as expected.

Cc: Ray Ni [email protected]
Signed-off-by: Michael Kubacki [email protected]
Reviewed-by: Michael D Kinney [email protected]
(cherry picked from commit 3ce5f2d445e51efe2aebaa227a055e5c8522d00b)

• 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

• Run CodeQL before and after the change.

Integration Instructions

N/A

Full Changelog: https://github.com/microsoft/mu_tiano_plus/compare/v2023110000.0.2...v2023110000.0.3

What's Changed

Removes edk2-basetools from pip-requirements.txt and any usage of it in the CISettings.py. The is done as there are changes in the build tools python source code that are available locally in BaseTools (as it is managed by Project Mu) that is not available in edk2-basetools.

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

Integration Instructions

N/A - only effects this repository's CI system.

Full Changelog: https://github.com/microsoft/mu_tiano_plus/compare/v2023110000.0.1...v2023110000.0.2

What's Changed

Edk2 updated AuthVariable and secureboot to allow them to use SHA384 and SHA512. The AuthVariable addition is good because it allows signing this with the PK but the secureboot addition is unnecessary.

The secureboot change has things hashed by all three algorithms and then checking them in the DBX for SHA256, SHA384 and SHA512 lists to make sure it's not on any of them. The issue with this is two fold.

1. This will have a performance impact. One that many platforms will not want.
2. This is completely unnecessary because the only group putting things in the DBX is Microsoft and we only use SHA256.

For these reasons it makes sense to revert the change in the secureboot logic and keep the AuthVariable changes.
Commit in edk2 for reference: https://github.com/tianocore/edk2/commit/bbf182229587958b17336c114e0a1525c4f90f3d

• [] 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 systems. No issues seen.

Integration Instructions

N/A

Full Changelog: https://github.com/microsoft/mu_tiano_plus/compare/v2023110000.0.0...v2023110000.0.1

What's Changed

⚠️ Breaking Changes

The TempPreUefiEventLogLib is an instance of the Tcg2PreUefiEventLogLib, but it contains an assert for when the library instance is used.

Tcg2PreUefiEventLogNull is now available. TempPreUefiEventLogLib is no longer necessary to allow builds to complete.

Remove the TempPreUefiEventLogLib instance of TempPreUefiEventLogLib.

• 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
• Local build of platform with included change.

Integration Instructions

Dsc files that made use of TempPreUefiEventLogLib need to update to point to the Tcg2PreUefiEventLogLibNull library instance.

Full Changelog: https://github.com/microsoft/mu_tiano_plus/compare/v2023020000.2.1...v2023020001.0.0

What's Changed

First 202311 Mu Tiano Plus release 🎉.

Cherry-pick the commits from 202302 that are missing from 202311 since the creation of the release branch.

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

The 202311 rebase moved the codeql plugin from .pytool to Basetools. This requires a change in CISettings.py to reference the correct codeql helper functions. Instead of using the internal versions we instead move to the edk2 pytool extensions version.

• 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 CI.

Integration Instructions

N/A

🔐 Security Impacting

Description

Security Patches for CVE-2022-36763 for release/202311

• Impacts functionality?
• Impacts security?
  • Security - Patches CVE-2022-36763
• Breaking change?
• Includes tests?
  • Tests - Unit tests
• Includes documentation?

How This Was Tested

These have been shipping in MSFT firmware for months now and have been unit tested.

Integration Instructions

N/A

Full Changelog: https://github.com/microsoft/mu_tiano_plus/compare/...v0.1.0

What's Changed

Added NULL implementation for Tcg2PreUefiEventLogLib

• 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

Consumed this null library under C41A8 project and verified Build successful

Integration Instructions

N/A

Full Changelog: https://github.com/microsoft/mu_tiano_plus/compare/v2023020000.2.0...v2023020000.2.1

What's Changed

Updates edk2-pytool-extensions and edk2-pytool-library to work with the latest commit of MU_BASECORE

• Impacts functionality?
  • Functionality - Does the change ultimately impact how firmware functions?
  • Examples: Add a new library, publish a new PPI, update an algorithm, ...
• Impacts security?
  • 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

There are some references to BaseCryptLib and Openssl in package dsc files. In MU_BASECORE Openssl and it's BaseCryptLib implementations were removed so we need to update to using the NULL lib.

• 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 CI

Integration Instructions

N/A

🚀 Features & ✨ Enhancements

[CHERRY-PICK] SecurityPkg/SecurityPkg.dec: Move PcdCpuRngSupportedAlgorithm to MdePkg

In order to use PcdCpuRngSupportedAlgorithm in the MdePkg in a
following patch and to avoid making the MdePkg dependent on another
package, move PcdCpuRngSupportedAlgorithm to the MdePkg.

As the Pcd is only used for AARCH64, place it in an AARCH64
specific sections.

Signed-off-by: Pierre Gondois [email protected]
Reviewed-by: Liming Gao [email protected]
Reviewed-by: Sami Mujawar [email protected]
Acked-by: Ard Biesheuvel [email protected]
Acked-by: Jiewen Yao [email protected]
Tested-by: Kun Qin [email protected]
(cherry picked from commit 65b5dd828ef2ea5056031b239a4e7a6642f771a3)

[CHERRY-PICK] SecurityPkg/RngDxe: Simplify Rng algorithm selection for Arm

The first element of mAvailableAlgoArray is defined as the default
Rng algorithm to use. Don't go through the array at each RngGetRNG()
call and just return the first element of the array.

Signed-off-by: Pierre Gondois [email protected]
Reviewed-by: Sami Mujawar [email protected]
Acked-by: Ard Biesheuvel [email protected]
Acked-by: Jiewen Yao [email protected]
Tested-by: Kun Qin [email protected]
(cherry picked from commit ff7ddc02b273f9159ef46fdb67d99062f8e598d9)

[CHERRY-PICK] SecurityPkg/RngDxe: Use GetRngGuid() when probing RngLib

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4151

The EFI_RNG_PROTOCOL can rely on the RngLib. The RngLib has multiple
implementations, some of them are unsafe (e.g. BaseRngLibTimerLib).
To allow the RngDxe to detect when such implementation is used,
a GetRngGuid() function was added in a previous patch.

The EFI_RNG_PROTOCOL can advertise multiple algorithms through
Guids. The PcdCpuRngSupportedAlgorithm is currently used to
advertise the RngLib in the Arm implementation.

The issues of doing that are:

• the RngLib implementation might not use CPU instructions,
  cf. the BaseRngLibTimerLib
• most platforms don't set PcdCpuRngSupportedAlgorithm

A GetRngGuid() was added to the RngLib in a previous patch,
allowing to identify the algorithm implemented by the RngLib.
Make use of this function and place the unsage algorithm
at the last position in the mAvailableAlgoArray.

Signed-off-by: Pierre Gondois [email protected]
Reviewed-by: Sami Mujawar [email protected]
Acked-by: Ard Biesheuvel [email protected]
Acked-by: Jiewen Yao [email protected]
Tested-by: Kun Qin [email protected]
(cherry picked from commit 19438cff973bfb35a1ef12fab45fabb28b63fe64)

[CHERRY-PICK] SecurityPkg/SecurityPkg.dec: Move PcdCpuRngSupportedAlgorithm to MdePkg

In order to use PcdCpuRngSupportedAlgorithm in the MdePkg in a
following patch and to avoid making the MdePkg dependent on another
package, move PcdCpuRngSupportedAlgorithm to the MdePkg.

As the Pcd is only used for AARCH64, place it in an AARCH64
specific sections.

Signed-off-by: Pierre Gondois [email protected]
Reviewed-by: Liming Gao [email protected]
Reviewed-by: Sami Mujawar [email protected]
Acked-by: Ard Biesheuvel [email protected]
Acked-by: Jiewen Yao [email protected]
Tested-by: Kun Qin [email protected]
(cherry picked from commit 65b5dd828ef2ea5056031b239a4e7a6642f771a3)

• 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

• Mu Basecore CI.
• Build QemuQ35Pkg and QemuSbsaPkg IA32, X64, and AARCH64 with the changes.
• Leverage edk2 upstream testing.

Integration Instructions

• Use the gEdkiiRngAlgorithmUnSafe if needed to integrate other code changes.
  
  

🔐 Security Impacting

[CHERRY-PICK] SecurityPkg/SecurityPkg.dec: Move PcdCpuRngSupportedAlgorithm to MdePkg

In order to use PcdCpuRngSupportedAlgorithm in the MdePkg in a
following patch and to avoid making the MdePkg dependent on another
package, move PcdCpuRngSupportedAlgorithm to the MdePkg.

As the Pcd is only used for AARCH64, place it in an AARCH64
specific sections.

Signed-off-by: Pierre Gondois [email protected]
Reviewed-by: Liming Gao [email protected]
Reviewed-by: Sami Mujawar [email protected]
Acked-by: Ard Biesheuvel [email protected]
Acked-by: Jiewen Yao [email protected]
Tested-by: Kun Qin [email protected]
(cherry picked from commit 65b5dd828ef2ea5056031b239a4e7a6642f771a3)

[CHERRY-PICK] SecurityPkg/RngDxe: Simplify Rng algorithm selection for Arm

The first element of mAvailableAlgoArray is defined as the default
Rng algorithm to use. Don't go through the array at each RngGetRNG()
call and just return the first element of the array.

Signed-off-by: Pierre Gondois [email protected]
Reviewed-by: Sami Mujawar [email protected]
Acked-by: Ard Biesheuvel [email protected]
Acked-by: Jiewen Yao [email protected]
Tested-by: Kun Qin [email protected]
(cherry picked from commit ff7ddc02b273f9159ef46fdb67d99062f8e598d9)

[CHERRY-PICK] SecurityPkg/RngDxe: Use GetRngGuid() when probing RngLib

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4151

The EFI_RNG_PROTOCOL can rely on the RngLib. The RngLib has multiple
implementations, some of them are unsafe (e.g. BaseRngLibTimerLib).
To allow the RngDxe to detect when such implementation is used,
a GetRngGuid() function was added in a previous patch.

The EFI_RNG_PROTOCOL can advertise multiple algorithms through
Guids. The PcdCpuRngSupportedAlgorithm is currently used to
advertise the RngLib in the Arm implementation.

The issues of doing that are:

• the RngLib implementation might not use CPU instructions,
  cf. the BaseRngLibTimerLib
• most platforms don't set PcdCpuRngSupportedAlgorithm

A GetRngGuid() was added to the RngLib in a previous patch,
allowing to identify the algorithm implemented by the RngLib.
Make use of this function and place the unsage algorithm
at the last position in the mAvailableAlgoArray.

Signed-off-by: Pierre Gondois [email protected]
Reviewed-by: Sami Mujawar [email protected]
Acked-by: Ard Biesheuvel [email protected]
Acked-by: Jiewen Yao [email protected]
Tested-by: Kun Qin [email protected]
(cherry picked from commit 19438cff973bfb35a1ef12fab45fabb28b63fe64)

[CHERRY-PICK] SecurityPkg/SecurityPkg.dec: Move PcdCpuRngSupportedAlgorithm to MdePkg

In order to use PcdCpuRngSupportedAlgorithm in the MdePkg in a
following patch and to avoid making the MdePkg dependent on another
package, move PcdCpuRngSupportedAlgorithm to the MdePkg.

As the Pcd is only used for AARCH64, place it in an AARCH64
specific sections.

Signed-off-by: Pierre Gondois [email protected]
Reviewed-by: Liming Gao [email protected]
Reviewed-by: Sami Mujawar [email protected]
Acked-by: Ard Biesheuvel [email protected]
Acked-by: Jiewen Yao [email protected]
Tested-by: Kun Qin [email protected]
(cherry picked from commit 65b5dd828ef2ea5056031b239a4e7a6642f771a3)

• 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

• Mu Basecore CI.
• Build QemuQ35Pkg and QemuSbsaPkg IA32, X64, and AARCH64 with the changes.
• Leverage edk2 upstream testing.

Integration Instructions

• Use the gEdkiiRngAlgorithmUnSafe if needed to integrate other code changes.
  
  

Description

Security Patches for CVE-2022-36763 for release/202302

• Impacts functionality?
• Impacts security?
  • Security - Patches CVE-2022-36763
• Breaking change?
• Includes tests?
  • Tests - Unit tests
• Includes documentation?

How This Was Tested

These have been shipping in MSFT firmware for months now and have been unit tested.

Integration Instructions

N/A

Full Changelog: https://github.com/microsoft/mu_tiano_plus/compare/v2023020000.1.3...v2023020000.2.0

What's Changed

Adds commits that only applied Uncrustify formatting or converted
line endings to a .git-blame-ignore-revs file so they are ignored
by git blame. This is supported by GitHub:
https://github.blog/changelog/2022-03-24-ignore-commits-in-the-blame-view-beta/

This helps clean up git blame by filtering out these changes.

Note: This file needs to be updated on rebase branches. Processes
like filter-branch can automatically update relevant SHAs.

• 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

• git blame

Integration Instructions

N/A

Updating Mu projects to apply uncrusty formatting for Cpp and header files, config updated upstream in edk2 https://github.com/tianocore/edk2/pull/4957 .

Config will be updated in mu_basecore https://github.com/microsoft/mu_basecore/pull/609.

• 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?
  • Breaks Uncrustify check on header file. Dependent on Uncrustify update in mu_basecore (https://github.com/microsoft/mu_basecore/pull/609)
• 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 CI build using a local mu_basecore branch with the Uncrustify config changes.

Integration Instructions

Project needs update mu_basecore with config changes.

Full Changelog: https://github.com/microsoft/mu_tiano_plus/compare/v2023020000.1.2...v2023020000.1.3

What's Changed

🔐 Security Impacting

Update one DSC file to use the new stack cookie library, and MdePkg/MdeLibs.dsc.inc contains the definitions for the new stack cookie libraries for the remaining DSC 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 Q35 GCC and MSVC builds

Integration Instructions

N/A

Full Changelog: https://github.com/microsoft/mu_tiano_plus/compare/v2023020000.1.1...v2023020000.1.2

What's Changed

This change uses abstracted interface from MemLib to validate incoming nested pointer before usage to ensure user supplied legitimate NVS buffer for corresponding TCG operations.

• 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 is validated on proprietary hardware platform.

Integration Instructions

N/A

Full Changelog: https://github.com/microsoft/mu_tiano_plus/compare/v2023020000.1.0...v2023020000.1.1

What's Changed

🚀 Features & ✨ Enhancements

This filter file is picked up both directly in mu_tiano_plus but also
downstream repos. Therefore, the file patterns should allow matches
regardless of where a mu_tiano_plus submodule or external dependency
may reside in the overall repo structure.

• 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 local mu_tiano_plus CodeQL build
• Verified downstream (mu_tiano_platforms) CodeQL build that leverages
  the CodeQlFilters.yml file from mu_tiano_plus.

Integration Instructions

No change in filtering behavior within mu_tiano_plus. Downstream repos that use
mu_tiano_plus will see more results auto filtered matching the expectations of
upstream repos.

🐛 Bug Fixes

This filter file is picked up both directly in mu_tiano_plus but also
downstream repos. Therefore, the file patterns should allow matches
regardless of where a mu_tiano_plus submodule or external dependency
may reside in the overall repo structure.

• 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 local mu_tiano_plus CodeQL build
• Verified downstream (mu_tiano_platforms) CodeQL build that leverages
  the CodeQlFilters.yml file from mu_tiano_plus.

Integration Instructions

No change in filtering behavior within mu_tiano_plus. Downstream repos that use
mu_tiano_plus will see more results auto filtered matching the expectations of
upstream repos.

Full Changelog: https://github.com/microsoft/mu_tiano_plus/compare/v2023020000.0.4...v2023020000.1.0