What's Changed

#94 Updated the generate_cryptodriver.py script to include the correct path to the DEPEX binary, but it failed to include the newly generated INF files.

Now updating with the correctly generated INF files.

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

Ran local build, replaced in mu_tiano_platforms and verified build failures were resolved (and q35 project booted).

Integration Instructions

N/A

🐛 Bug Fixes

In packages generated before 2023.11.3, the generated INF files would reference a common DEPEX file for all the arches instead of being contained in the same folder as the generated EFI file.

After the update for including map files, etc, the location of the DEPEX was in in the same folder as the EFI, MAP and PDB file.
Updating the script generate the correct file location for the DEPEX.

• 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

Manually updated a project to use 2023.11.5 and encountered a build error because of the depex file path was mismatched.

Integration Instructions

N/A

Full Changelog: https://github.com/microsoft/mu_crypto_release/compare/v2024.0.0...v2024.0.1

What's Changed

🐛 Bug Fixes

In packages generated before 2023.11.3, the generated INF files would reference a common DEPEX file for all the arches instead of being contained in the same folder as the generated EFI file.

After the update for including map files, etc, the location of the DEPEX was in in the same folder as the EFI, MAP and PDB file.
Updating the script generate the correct file location for the DEPEX.

• 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

Manually updated a project to use 2023.11.5 and encountered a build error because of the depex file path was mismatched.

Integration Instructions

N/A

Full Changelog: https://github.com/microsoft/mu_crypto_release/compare/v2024.0.0...v2024.0.1

What's Changed

• Repo File Sync: synced file(s) with microsoft/mu_devops by @uefibot in https://github.com/microsoft/mu_crypto_release/pull/64
• [CHERRY-PICK] Reduce Crypto RNG Assumptions by @os-d in https://github.com/microsoft/mu_crypto_release/pull/89

New Contributors

• @os-d made their first contribution in https://github.com/microsoft/mu_crypto_release/pull/89

Full Changelog: https://github.com/microsoft/mu_crypto_release/compare/v2023.2.13...v2023.2.14

What's Changed

⚠️ Breaking Changes

NOTE: This PR should only be completed when we are sure that we would like to
introduce a dependency on the RNG PPI and RNG Protocol for the PEI and DXE
binaries.

NOTE: This will need to be cherry-picked into the release/202302 branch
(with the MU_BASECORE submodule updated).

CryptoBinPkg.dsc: Use static stack cookie init for DXE

Simplifies the RNG support expected of platforms integrating
the DXE binary.

CryptoBinPkg: Use PeiRngLib and DxeRngLib for crypto binaries

Since platforms integrating the binaries may have very different
levels of support for random number generation, allow the platform
to provide a RNG service for PEI and DXE.

A similar change may be made for SMM and Standalone MM environments
in the future.

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

How This Was Tested

• Build and platform integration
• Verify RNG PPI/Protocol is present on the PEI and DXE binaries
• Verify the PeiRngLib and DxeRngLib libraries can locate and use
  the RNG PPI and Protocol

Integration Instructions

• Read the readme update made in this change in the
  "Dependencies Built into Shared Crypto" section.
  
  

🚀 Features & ✨ Enhancements

NOTE: This PR should only be completed when we are sure that we would like to
introduce a dependency on the RNG PPI and RNG Protocol for the PEI and DXE
binaries.

NOTE: This will need to be cherry-picked into the release/202302 branch
(with the MU_BASECORE submodule updated).

CryptoBinPkg.dsc: Use static stack cookie init for DXE

Simplifies the RNG support expected of platforms integrating
the DXE binary.

CryptoBinPkg: Use PeiRngLib and DxeRngLib for crypto binaries

Since platforms integrating the binaries may have very different
levels of support for random number generation, allow the platform
to provide a RNG service for PEI and DXE.

A similar change may be made for SMM and Standalone MM environments
in the future.

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

How This Was Tested

• Build and platform integration
• Verify RNG PPI/Protocol is present on the PEI and DXE binaries
• Verify the PeiRngLib and DxeRngLib libraries can locate and use
  the RNG PPI and Protocol

Integration Instructions

• Read the readme update made in this change in the
  "Dependencies Built into Shared Crypto" section.
  
  

📖 Documentation Updates

NOTE: This PR should only be completed when we are sure that we would like to
introduce a dependency on the RNG PPI and RNG Protocol for the PEI and DXE
binaries.

NOTE: This will need to be cherry-picked into the release/202302 branch
(with the MU_BASECORE submodule updated).

CryptoBinPkg.dsc: Use static stack cookie init for DXE

Simplifies the RNG support expected of platforms integrating
the DXE binary.

CryptoBinPkg: Use PeiRngLib and DxeRngLib for crypto binaries

Since platforms integrating the binaries may have very different
levels of support for random number generation, allow the platform
to provide a RNG service for PEI and DXE.

A similar change may be made for SMM and Standalone MM environments
in the future.

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

How This Was Tested

• Build and platform integration
• Verify RNG PPI/Protocol is present on the PEI and DXE binaries
• Verify the PeiRngLib and DxeRngLib libraries can locate and use
  the RNG PPI and Protocol

Integration Instructions

• Read the readme update made in this change in the
  "Dependencies Built into Shared Crypto" section.
  
  

Full Changelog: https://github.com/microsoft/mu_crypto_release/compare/v2023.11.5...v2024.0.0

What's Changed

Updates the logic that is responsible to bundling the nuget contents in the appropriate manner. This update replaces the standalone script with a post build plugin that will be executed when the command line argument --bundle is added to either the MultiFlavorBuild or SingleFlavorBuild build scripts.

Additionally, update the dsc to generate pdbs on release builds in addition to debug builds. Also ensures pdb, map, and build available and a part of the bundle that is generated for a NuGet release. These changes make it easier for the local story, such that developers can run the py MultiFlavorBuild.py ... --bundle, and the structure of the NuGet package is generated. Instead of copying over the newly compiled binaries to the NuGet package in the platform, the developer can simply set the SHARED_CRYPTO_PATH=<workspace/Bundle> and build.

• Impacts functionality?
  • Functionality - Does the change ultimately impact how firmware functions?
  • Examples: Add a new library, publish a new PPI, update an algorithm, ...
• Impacts security?
  • Security - Does the change have a direct security impact on an application,
    flow, or firmware?
  • Examples: Crypto algorithm change, buffer overflow fix, parameter
    validation improvement, ...
• Breaking change?
  • Breaking change - Will anyone consuming this change experience a break
    in build or boot behavior?
  • Examples: Add a new library class, move a module to a different repo, call
    a function in a new library class in a pre-existing module, ...
• Includes tests?
  • Tests - Does the change include any explicit test code?
  • Examples: Unit tests, integration tests, robot tests, ...
• Includes documentation?
  • Documentation - Does the change contain explicit documentation additions
    outside direct code modifications (and comments)?
  • Examples: Update readme file, add feature readme file, link to documentation
    on an a separate Web page, ...

How This Was Tested

Ensured compiling, bundling, and releasing continues to work: https://dev.azure.com/projectmu/mu/_build/results?buildId=69830&view=results

Integration Instructions

N/A

📖 Documentation Updates

• Primarily updates CryptoBinPkg/Driver/readme.md to improve the
  instructions for integrating shared crypto binary releases into a
  platform firmware.

• Updates the main Readme.rst file to point to the driver instructions
  toward the top of the file.

• Removes a small set of redundant code in CryptoBinPkg.dsc.

• Impacts functionality?

• Impacts security?

• Breaking change?

• Includes tests?

• Includes documentation?

How This Was Tested

• N/A - Only updates readme.

Integration Instructions

• N/A
  
  

Full Changelog: https://github.com/microsoft/mu_crypto_release/compare/v2023.11.3...v2023.11.5

What's Changed

• Repo File Sync: synced file(s) with microsoft/mu_devops by @uefibot in https://github.com/microsoft/mu_crypto_release/pull/79
• CryptoPkg/BaseCryptLib: add DigestLen to RsaOaepEncrypt(), RsaOaepDecrypt() by @cmruffin in https://github.com/microsoft/mu_crypto_release/pull/80
• CryptoPkg/Binaries: update to 2023.11.3 by @cmruffin in https://github.com/microsoft/mu_crypto_release/pull/82

New Contributors

• @cmruffin made their first contribution in https://github.com/microsoft/mu_crypto_release/pull/80

Full Changelog: https://github.com/microsoft/mu_crypto_release/compare/v2023.11.2...v2023.11.3

What's Changed

NOTE: When picking up the crypto binary built with this change, you must
include commit 6cc02e2 from the release/202311 branch in Mu
Basecore.

🔐 Security Impacting

Expand the availability of the RSAES-OAEP crypto capability in
BaseCryptLib. Applications using RSA crypto functions directly from
OpensslLib can transition to BaseCryptLib to take advantage of the
shared crypto feature in CryptoDxe.

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

How This Was Tested

Host-based unit tests, end-to-end testing with shared crypto binary.

Integration Instructions

When picking up the crypto binary built with this change, you must
include commit 6cc02e2 from the release/202311 branch in Mu
Basecore.

Full Changelog: https://github.com/microsoft/mu_crypto_release/compare/v2023.11.1...v2023.11.2

What's Changed

This is the first crypto binary release based on the Mu Basecore 202311 branch.

The underlying crypto changes are the same as the 2023.2.13 release, the only
difference is it is built upon Mu Basecore release/202311.

What's Changed

This was a release candidate (RC) for the 202302 branch of Mu Crypto release.

It was a RC built of a special release branch (mu_cryptobin_2023_2_14).

Due to integration challenges syncing the changes with Mu Basecore, this is planned
to be the final release based on Mu Basecore 202302, future releases will be based on
Mu Basecore 202311.

🔐 Security Impacting

Expand the availability of the RSAES-OAEP crypto capability in
BaseCryptLib. Applications using RSA crypto functions directly from
OpensslLib can transition to BaseCryptLib to take advantage of the
shared crypto feature in CryptoDxe.

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

How This Was Tested

Host-based unit tests, end-to-end testing with shared crypto binary.

Integration Instructions

When picking up the crypto binary built with this change, you must
include commit 6cc02e2 from the release/202311 branch in Mu
Basecore.

What's Changed

🚀 Features

Closes #69

Adds the AARCH64 build for CryptoRuntimeDxe. The crypto generation
script already publishes build files for AARCH64 Runtime DXE
binaries.

• 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 each flavor of the AARCH64 driver on GCC.
• Verify the file is in the assembled NuGet package.
• Ensure the driver is in the generated crypto scripts.
• PR is in draft while testing on a platform is performed.

Integration Instructions

RUNTIMEDXE_CRYPTO_ARCH and RUNTIMEDXE_CRYPTO_SERVICES should be set
in platform DSC files for the AARCH64 architecture and the selected
flavor to have the binary included in thee platform build.

Full Changelog: https://github.com/microsoft/mu_crypto_release/compare/v2023.2.12...v2023.2.13

What's Changed

• Adding Sha256HashAll to all versions of generated binaries by @apop5 in https://github.com/microsoft/mu_crypto_release/pull/72

New Contributors

• @apop5 made their first contribution in https://github.com/microsoft/mu_crypto_release/pull/72

Full Changelog: https://github.com/microsoft/mu_crypto_release/compare/v2023.2.11...v2023.2.12

What's Changed

✨ Enhancements

A platform is expected to define the crypto services and applicable
archs at the beginning of the platform DSC and then include the
CryptoDriver.inc.dsc file. This file currently requires that all
services and archs are accounted for even if they are not used.

This change first checks if the platform set any values. If not, then
the service and corresponding arch is set to NONE. This allows
platforms to simply opt into the services and corresponding archs
that are necessary.

• 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 changes in mu_tiano_platforms with services and archs missing to confirm
  the NONE value is applied.
• Tested changes in mu_tiano_platforms with services set to actual values to verify
  the values are retained.

Integration Instructions

Define the crypto services needed for a platform. If a crypto service is used,
set the applicable arch. Otherwise, the arch does not need to be specified.

What's Changed

NOTE: This release should have updated the minor version since it is a breaking change.
This was not done in retrospect since the release has already been consumed in several repos.

⚠️ Breaking Changes

Recently Openssl and its BaseCryptLib implementation were moved out of MU_BASECORE in favor of requiring a crypto binary. However, the generated files that work with the binary were left in CryptoPkg. This PR moves binary generation code to CryptoBinPkg and updates it to work from it's new location.

Changes that were made:

1. Moved the crypto driver to CryptoBinPkg and updated it to generate its files in its new location.
   NOTE: Some files in MU_BASECORE are still updated when running the python script, specifically CryptoPkg/Library/BaseCryptLibOnProtocolPpi/CryptLib.c and CryptoPkg/Include/Protocol/Crypto.h. The changes are almost always a timestamp bump but you'll need to confirm that when generating new crypto binaries.
2. Added all the CryptoPkg/Driver files to the published nuget binary (excluding the temp files and the crypto generation script itself).
3. The readme was updated to better describe integration steps as well as how the crypto binary currently behaves.

• 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 and on the server pipeline to make sure the crypto files were correctly added to the nuget binary. Tested the generated extdep to make sure the core functionality has remained the same.

Integration Instructions

If you were previously using the crypto binary you'll need to update the paths to the extdep files.

🚀 Features & ✨ Enhancements & 🐛 Bug Fixes & 📃Documentation

Closes #55

Primary purpose is to add Runtime DXE shared crypto. Other fixes and
updates are included. Below is a summary of the changes.

OpensslPkg/RuntimeCryptLib: Fix build issues

UefiRuntimeLib needs to be included in [LibaryClasses] to properly
link the functions. gEfiEventVirtualAddressChangeGuid is missing
in the [Guids] section.

generate_cryptodriver.py: Fix migration regression

The migration commit (455ca6b) contained an older section of code in
the DSC generation section. This restores the section to match the
contents in https://github.com/microsoft/mu_basecore/pull/713.

Use SHARED_CRYPTO_PATH for the shared crypto path

In CryptoBinPkg, some files (like Crypto.inc.dsc) are used during
the build. This should come from the latest revisions in the
mu_crypto_release repo (which doesn't use the actual binaries).

In consuming repos, the ext dep could be defined anywhere. To
satisfy both of these needs and make the location more portable in
general, a build environment variable is introduced to track the
path.

In mu_crypto_release, the path will be set to "CryptoBinPkg". This
will cause its build to reference the files in the code tree. In
shared crypto consuming repos, it is set in the ext dep (during build)
to the path the binaries are placed in.

Add shared crypto Runtime DXE driver

Adds the CryptoRuntimeDxe driver, currently built for IA32 and X64,
it produces the EDK II Crypto protocol backed by runtime code buffers
so the functionality can be invoked at OS runtime.

Consuming RT DXE drivers should link an instance of BaseCryptLib
that is RT DXE compatible, like the RuntimeDxeCryptLib in
CryptoPkg.

RUNTIMEDXE_CRYPTO_SERVICES and RUNTIMEDXE_CRYPTO_ARCH should be set
in platform DSC files to a value other than "NONE" to use the driver.

Update readmes for recent changes

Refreshes content in the main repo and shared crypto readme files
to reflect recent changes and current process.

• Impacts functionality?
  • Functionality - Does the change ultimately impact how firmware functions?
  • Examples: Add a new library, publish a new PPI, update an algorithm, ...
• Impacts security?
  • Security - Does the change have a direct security impact on an application,
    flow, or firmware?
  • Examples: Crypto algorithm change, buffer overflow fix, parameter
    validation improvement, ...
• Breaking change?
  • Breaking change - Will anyone consuming this change experience a break
    in build or boot behavior?
  • Examples: Add a new library class, move a module to a different repo, call
    a function in a new library class in a pre-existing module, ...
• Includes tests?
  • Tests - Does the change include any explicit test code?
  • Examples: Unit tests, integration tests, robot tests, ...
• Includes documentation?
  • Documentation - Does the change contain explicit documentation additions
    outside direct code modifications (and comments)?
  • Examples: Update readme file, add feature readme file, link to documentation
    on an a separate Web page, ...

How This Was Tested

• Local flavor build and assembly
• Test binaries produced on QemuQ35Pkg and QemuSbsaPkg

Integration Instructions

Use the new Runtime DXE shared crypto binaries if needed for a
platform.

What's Changed

🔐 Security Impacting

Update the MU_BASECORE pin to include the change to the STANDARD crypto binary flavor that includes SHA384 and SHA512.

• 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 a local build. The newly generated crypto binary included SHA384 and SHA512.

Integration Instructions

Update to the next crypto binary release.

What's Changed

🚀 Features & ✨ Enhancements

Add PEI and Standalone MM AARCH64 binaries

Produces an AARCH64 CryptoPei and CryptoStandaloneMm binary.

Note:

• Uses the MmServicesTableLib and StandaloneMmDriverEntryPoint library
  instances in StandaloneMmPkg for AARCH64.
• Uses BaseRngLibTimerLib instance for AARCH64 MM_STANDALONE due to current
  platform compatibility.
• Uses RngDxe instance for DXE drivers so platforms can publish a
  gEdkiiCryptoProtocolGuid protocol instance backed by an RngLib
  (or alternative) implementation of choice.
• AARCH64 binaries can be built for all flavors using GCC or Visual Studio,
  however, only GCC binaries are currently published and supported.

AARCH64 GCC Build and Pipeline Support

• Add pipeline support for AARCH64 GCC builds
• Build AARCH64 GCC binaries in the Mu Devops Ubuntu container
• Update MultiFlavorBuild.py to force AARCH64 builds to use GCC.

• Impacts functionality?
  • Functionality - Does the change ultimately impact how firmware functions?
  • Examples: Add a new library, publish a new PPI, update an algorithm, ...
• Impacts security?
  • Security - Does the change have a direct security impact on an application,
    flow, or firmware?
  • Examples: Crypto algorithm change, buffer overflow fix, parameter
    validation improvement, ...
• Breaking change?
  • Breaking change - Will anyone consuming this change experience a break
    in build or boot behavior?
  • Examples: Add a new library class, move a module to a different repo, call
    a function in a new library class in a pre-existing module, ...
• Includes tests?
  • Tests - Does the change include any explicit test code?
  • Examples: Unit tests, integration tests, robot tests, ...
• Includes documentation?
  • Documentation - Does the change contain explicit documentation additions
    outside direct code modifications (and comments)?
  • Examples: Update readme file, add feature readme file, link to documentation
    on an a separate Web page, ...

How This Was Tested

• Local build of all crypto flavors
• Test on QEMU Mu Tiano Platform packages

Integration Instructions

• Use the AARCH64 PEI and Standalone MM binaries on a platform if needed.
  
  

Closes #46

Note: CryptoStandaloneMm is intentionally only built for X64 due to
build limitations in MM Supervisor dependencies for IA32.

1. CryptoBinPkg/CryptoBingPkg.dsc: Remove MU_CHANGE and MSCHANGE tags

This file is not tracking an upstream file. Diff markers are not
needed.

2. MultiFlavorBuild.py: Default to VS2022 instead of VS2019

If a tool chain is not specified, use VS2022 instead of VS2019. It
is the pipeline build tool chain and installed more commonly now.

3. Update to the latest MU_BASECORE

Moves MU_BASECORE to the latest MU_BASECORE. This is a relatively
large move including about 207 Mu Basecore commits.

Some integration related changes are included.

4. CryptoBinPkg: Add CryptoStandaloneMm

Adds a Standalone MM driver to the shared crypto binary release.

5. CryptoBinPkg: Add MM Supervisor submodule

Adds the Project Mu MM Supervisor repo as a submodule and updates the
library instances for CryptoStandaloneMm to use the supervisor library
instances where relevant.

6. MultiFlavorBuild.py: Fix SyntaxWarning on new Python versions

Properly escapes the backslash character to prevent SyntaxWarning
due to an invalid escape sequence.

7. CryptoBinPkg: Merge LibraryClasses sections in DSC

Merges the two [LibraryClasses] sections together resolving duplicates
and sorting contents for easier inspection and diff.

NOTE: The Mu Basecore submodule will be updated after several PRs are
completed in that repo required for this PR. Right now, this PR
is using a temporary branch with all of those changes consolidated.

• Impacts functionality?
  • Functionality - Does the change ultimately impact how firmware functions?
  • Examples: Add a new library, publish a new PPI, update an algorithm, ...
• Impacts security?
  • Security - Does the change have a direct security impact on an application,
    flow, or firmware?
  • Examples: Crypto algorithm change, buffer overflow fix, parameter
    validation improvement, ...
• Breaking change?
  • Breaking change - Will anyone consuming this change experience a break
    in build or boot behavior?
  • Examples: Add a new library class, move a module to a different repo, call
    a function in a new library class in a pre-existing module, ...
• Includes tests?
  • Tests - Does the change include any explicit test code?
  • Examples: Unit tests, integration tests, robot tests, ...
• Includes documentation?
  • Documentation - Does the change contain explicit documentation additions
    outside direct code modifications (and comments)?
  • Examples: Update readme file, add feature readme file, link to documentation
    on an a separate Web page, ...

How This Was Tested

• Local build including package assembly of all crypto flavors
• mu_cryto_release pipeline run with changes (61774).
• Integration of generated binaries on QemuQ35Pkg (using Standalone MM crypto binary)
• Integration of generated binaries on a physical Intel platform (using Standalone MM crypto binary)

Integration Instructions

• Use the new Standalone MM binary if using the Project Mu MM Supervisor
  on a platform where shared crypto is needed for Standalone MM.

A new build rule may be needed in a platform FDF to integrate Standalone MM binaries. An
example to use the Standalone MM shared crypto driver is shown below:

[Rule.Common.MM_STANDALONE.BINARY]
  FILE MM_STANDALONE = $(NAMED_GUID) {
    SMM_DEPEX SMM_DEPEX Optional      |.depex
    PE32      PE32                    |.efi
    UI        STRING="$(MODULE_NAME)" Optional
    VERSION   STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
  }

  </blockquote>
  <hr>
</details>

🐛 Bug Fixes

The parameter is currently not passed from the outer YAML file to
the template so the nuget_publish value in template-build.yml is
always 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

• Pipeline run with change - 20240201.10 • ReleaseBuild.yml: Pass publish_nuget param to template

Integration Instructions

• N/A - Only impacts local repo pipeline release process.
  
  

🔐 Security Impacting

Add PEI and Standalone MM AARCH64 binaries

Produces an AARCH64 CryptoPei and CryptoStandaloneMm binary.

Note:

• Uses the MmServicesTableLib and StandaloneMmDriverEntryPoint library
  instances in StandaloneMmPkg for AARCH64.
• Uses BaseRngLibTimerLib instance for AARCH64 MM_STANDALONE due to current
  platform compatibility.
• Uses RngDxe instance for DXE drivers so platforms can publish a
  gEdkiiCryptoProtocolGuid protocol instance backed by an RngLib
  (or alternative) implementation of choice.
• AARCH64 binaries can be built for all flavors using GCC or Visual Studio,
  however, only GCC binaries are currently published and supported.

AARCH64 GCC Build and Pipeline Support

• Add pipeline support for AARCH64 GCC builds
• Build AARCH64 GCC binaries in the Mu Devops Ubuntu container
• Update MultiFlavorBuild.py to force AARCH64 builds to use GCC.

• Impacts functionality?
  • Functionality - Does the change ultimately impact how firmware functions?
  • Examples: Add a new library, publish a new PPI, update an algorithm, ...
• Impacts security?
  • Security - Does the change have a direct security impact on an application,
    flow, or firmware?
  • Examples: Crypto algorithm change, buffer overflow fix, parameter
    validation improvement, ...
• Breaking change?
  • Breaking change - Will anyone consuming this change experience a break
    in build or boot behavior?
  • Examples: Add a new library class, move a module to a different repo, call
    a function in a new library class in a pre-existing module, ...
• Includes tests?
  • Tests - Does the change include any explicit test code?
  • Examples: Unit tests, integration tests, robot tests, ...
• Includes documentation?
  • Documentation - Does the change contain explicit documentation additions
    outside direct code modifications (and comments)?
  • Examples: Update readme file, add feature readme file, link to documentation
    on an a separate Web page, ...

How This Was Tested

• Local build of all crypto flavors
• Test on QEMU Mu Tiano Platform packages

Integration Instructions

• Use the AARCH64 PEI and Standalone MM binaries on a platform if needed.
  
  

Openssl was removed from MU_BASECORE in favor of the generated SHARED_CRYPTO binaries. However, to create the binary we still need access to Openssl. This PR moves Openssl and the BaseCryptLib implementation into this repo for binary generation.

• Impacts functionality?
  • Functionality - Does the change ultimately impact how firmware functions?
  • Examples: Add a new library, publish a new PPI, update an algorithm, ...
• Impacts security?
  • Security - Does the change have a direct security impact on an application,
    flow, or firmware?
  • Examples: Crypto algorithm change, buffer overflow fix, parameter
    validation improvement, ...
• Breaking change?
  • Breaking change - Will anyone consuming this change experience a break
    in build or boot behavior?
  • Examples: Add a new library class, move a module to a different repo, call
    a function in a new library class in a pre-existing module, ...
• Includes tests?
  • Tests - Does the change include any explicit test code?
  • Examples: Unit tests, integration tests, robot tests, ...
• Includes documentation?
  • Documentation - Does the change contain explicit documentation additions
    outside direct code modifications (and comments)?
  • Examples: Update readme file, add feature readme file, link to documentation
    on an a separate Web page, ...

How This Was Tested

In progress

Integration Instructions

N/A

Full Changelog: https://github.com/microsoft/mu_crypto_release/compare/v2023020000.0.2...v2023020000.1.0

What's Changed

🚀 Features & ✨ Enhancements

Closes #46

Note: CryptoStandaloneMm is intentionally only built for X64 due to
build limitations in MM Supervisor dependencies for IA32.

1. CryptoBinPkg/CryptoBingPkg.dsc: Remove MU_CHANGE and MSCHANGE tags

This file is not tracking an upstream file. Diff markers are not
needed.

2. MultiFlavorBuild.py: Default to VS2022 instead of VS2019

If a tool chain is not specified, use VS2022 instead of VS2019. It
is the pipeline build tool chain and installed more commonly now.

3. Update to the latest MU_BASECORE

Moves MU_BASECORE to the latest MU_BASECORE. This is a relatively
large move including about 207 Mu Basecore commits.

Some integration related changes are included.

4. CryptoBinPkg: Add CryptoStandaloneMm

Adds a Standalone MM driver to the shared crypto binary release.

5. CryptoBinPkg: Add MM Supervisor submodule

Adds the Project Mu MM Supervisor repo as a submodule and updates the
library instances for CryptoStandaloneMm to use the supervisor library
instances where relevant.

6. MultiFlavorBuild.py: Fix SyntaxWarning on new Python versions

Properly escapes the backslash character to prevent SyntaxWarning
due to an invalid escape sequence.

7. CryptoBinPkg: Merge LibraryClasses sections in DSC

Merges the two [LibraryClasses] sections together resolving duplicates
and sorting contents for easier inspection and diff.

NOTE: The Mu Basecore submodule will be updated after several PRs are
completed in that repo required for this PR. Right now, this PR
is using a temporary branch with all of those changes consolidated.

• Impacts functionality?
  • Functionality - Does the change ultimately impact how firmware functions?
  • Examples: Add a new library, publish a new PPI, update an algorithm, ...
• Impacts security?
  • Security - Does the change have a direct security impact on an application,
    flow, or firmware?
  • Examples: Crypto algorithm change, buffer overflow fix, parameter
    validation improvement, ...
• Breaking change?
  • Breaking change - Will anyone consuming this change experience a break
    in build or boot behavior?
  • Examples: Add a new library class, move a module to a different repo, call
    a function in a new library class in a pre-existing module, ...
• Includes tests?
  • Tests - Does the change include any explicit test code?
  • Examples: Unit tests, integration tests, robot tests, ...
• Includes documentation?
  • Documentation - Does the change contain explicit documentation additions
    outside direct code modifications (and comments)?
  • Examples: Update readme file, add feature readme file, link to documentation
    on an a separate Web page, ...

How This Was Tested

• Local build including package assembly of all crypto flavors
• mu_cryto_release pipeline run with changes (61774).
• Integration of generated binaries on QemuQ35Pkg (using Standalone MM crypto binary)
• Integration of generated binaries on a physical Intel platform (using Standalone MM crypto binary)

Integration Instructions

• Use the new Standalone MM binary if using the Project Mu MM Supervisor
  on a platform where shared crypto is needed for Standalone MM.

A new build rule may be needed in a platform FDF to integrate Standalone MM binaries. An
example to use the Standalone MM shared crypto driver is shown below:

[Rule.Common.MM_STANDALONE.BINARY]
  FILE MM_STANDALONE = $(NAMED_GUID) {
    SMM_DEPEX SMM_DEPEX Optional      |.depex
    PE32      PE32                    |.efi
    UI        STRING="$(MODULE_NAME)" Optional
    VERSION   STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
  }

Note that the Standalone MM binaries are built against the Project Mu
MM Supervisor.

Full Changelog: https://github.com/microsoft/mu_crypto_release/compare/v2023020000.0.2...v2023020000.1.0

What's Changed

🔐 Security Impacting

Update the referenced OpensslLib to be OpensslLibFull to include additional crypto algorithms that we want available in the Shared Crypto binary.

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

Used BaseCryptLib Shell based test with test binaries and passed all tests with this change.

Integration Instructions

Update to the new release that will be made after this goes in (2023.02.3)

Full Changelog: https://github.com/microsoft/mu_crypto_release/compare/v2023020000.0.1...v2023020000.0.2

What's Changed

Crypto autogen was updated to not specify the module type for components to follow PEI spec. This PR pulls these changes for a release.

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

Build and booted with latest changes to crypto.

Integration Instructions

Update crypto binary version in basecore to 2023.02.2

  </blockquote>
  <hr>
</details>

Full Changelog: https://github.com/microsoft/mu_crypto_release/compare/v2023020000.0.0...v2023020000.0.1

What's Changed

This is the first MU Crypto 202302 release 🎉

The previous branch was 202208.

These versions correspond to edk2 stable release tags that the code is based upon.

Since edk2 makes a release every 3 months, two stable tags were actually picked up in this release:

• edk2-stable202211
• edk2-stable202302

Review those release notes to understand the changes coming in from edk2. In addition, Mu repos highlight important changes in their Readme files. Review the 202302 Readme before you move code to this branch to understand major changes.