v2023.2.14-rc

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

• CryptoPkg/BaseCryptLib: Add additional RSAES-OAEP crypto functions @cmruffin(#78)
  
  Change Details

  ## Description

  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.
  

  
  

  ---

  
  

v2023.2.13

What's Changed

🚀 Features

• CryptoBinPkg: Add AARCH64 CryptoRuntimeDxe @makubacki(#73)
  
  Change Details

  ## Description

  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: v2023.2.12...v2023.2.13

v2023.2.12

What's Changed

• Adding Sha256HashAll to all versions of generated binaries by @apop5 in #72

New Contributors

• @apop5 made their first contribution in #72

Full Changelog: v2023.2.11...v2023.2.12

v2023.2.11

What's Changed

✨ Enhancements

• CryptoBinPkg: Assume crypto service/arch NONE values @makubacki(#71)
  
  Change Details

   ## Description

  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.
  

  
  

  ---

  
  

v2023.2.10

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

• Migrate crypto driver files and include them in the binary @kenlautner (#66)
  
  Change Details

   ## Description

  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

• Add RT DXE Shared Crypto @makubacki (#67)
  
  Change Details

   ## Description

  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 microsoft/mu_basecore#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.
  

  
  

  ---

  
  

v2023.2.9

What's Changed

🔐 Security Impacting & 🐛 Bug Fixes

• Updated MU_BASECORE pin @kenlautner (#65)
  
  Change Details

   ## Description

  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.
  

  
  

  ---

  
  

v2023.2.8

What's Changed

🚀 Features & ✨ Enhancements

• Add PEI and Standalone MM AARCH64 binaries [Rebase \& FF] @makubacki (#57)
  
  Change Details

    ## Description

  ---

  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.
    

  
  

  ---

• Add Standalone MM Support (And Other Enhancements) [Rebase \& FF] @makubacki (#52)
  
  Change Details

    ## Description

  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

• ReleaseBuild.yml: Pass publish\_nuget param to template @makubacki (#63)
  
  Change Details

    ## Description

  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 [Rebase \& FF] @makubacki (#57)
  
  Change Details

    ## Description

  ---

  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 pipeli...

v2023.2.6

What's Changed

🚀 Features & ✨ Enhancements

• Add Standalone MM Support (And Other Enhancements) [Rebase \& FF] @makubacki (#52)
  
  Change Details

    ## Description

  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: v2023020000.0.2...v2023020000.1.0

v2023020000.0.2

What's Changed

⚠️ Warning!
This release is not recommended! This release was accidentally built without Elliptic Curve support for TLS connections.
This release has been unlisted and it is now highly recommended to move to a later release 2023.02.06 or later.

🔐 Security Impacting

• Update reference openssl library @kenlautner (#34)
  
  Change Details

    ## Description

  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: v2023020000.0.1...v2023020000.0.2

v2023020000.0.1

What's Changed

• Update MU\_BASECORE to include crypto file changes @kenlautner (#25)
  
  Change Details

    ## Description

  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: v2023020000.0.0...v2023020000.0.1