v1.0.1

What's Changed

• Correct checks for StMm and Stmm_Supv conflicts. by @apop5 in #117

Full Changelog: v1.0.0...v1.0.1

v1.0.0

Adoption of Semantic Versioning

• Note: Shared Crypto follows semantic versioning. The version number is incremented based on the type of changes made to the shared crypto binaries. The version number is not tied to the version of the underlying crypto provider.
• Note: Prior to adopting semantic versioning in the 1.0.0 release, the version number followed a form of YYYY.MM.PATCH. The 1.0.0 release was the first to use semantic versioning and proceeds any of those versions.

Breaking Change - Standalone MM Integration

Two options are now provided for Standalone MM. It is important to select the option based on the Standalone MM core used on your platform:

• StandaloneMmPkg - Use STANDALONEMM_CRYPTO_SERVICES
• MmSupervisorPkg - Use STANDALONEMM_MMSUPV_CRYPTO_SERVICES

Since the MM Supervisor currently does not support AARCH64, only a X64 MM Supervisor Standalone MM binary is available. A platform should not have both STANDALONEMM_CRYPTO_SERVICES and STANDALONEMM_MMSUPV_CRYPTO_SERVICES set to non-NONE values.

What's Changed

• Use OpenSSL intrinsic lib for all archs by @makubacki in #96
• [Release/202311] CryptoBinPkg: Update EDKII_CRYPTO_VERSION from 17 to 18 by @Flickdm in #102
• generate_cryptodriver: Add useful versioning to shared crypto binaries by @makubacki in #105
• Remove temporary files from the published binary files by @kenlautner in #106
• Add PR test gates for Mu_Crypto_Release by @kenlautner in #104
• Update MU_BASECORE to include cherrypick subhook submodule by @Flickdm in #112
• Fix OpensslPkg CI by @makubacki in #114
• Add Non-MM Supervisor Standalone MM X64 Binary by @makubacki in #113
• Update instructions for semantic versioning by @makubacki in #115

Full Changelog: v2023.12.2...v1.0.0

v2023.12.2

What's Changed

• CryptoBinPkg: Add INFs generated with correct depex. @apop5 (#95)
  
  Change Details

    ## Description

  #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

• CryptoBinPkg: Updated DEPEX statement in generated INF files to match new location @apop5 (#94)
  
  Change Details

    ## Description

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

v2023.12.1

What's Changed

🐛 Bug Fixes

• CryptoBinPkg: Updated DEPEX statement in generated INF files to match new location @apop5 (#94)
  
  Change Details

    ## Description

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

v2023.12.0

What's Changed

⚠️ Breaking Changes

• Reduce Crypto RNG Assumptions [Rebase \& FF] @makubacki (#88)
  
  Change Details

    ## Description

  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

• Reduce Crypto RNG Assumptions [Rebase \& FF] @makubacki (#88)
  
  Change Details

    ## Description

  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

• Reduce Crypto RNG Assumptions [Rebase \& FF] @makubacki (#88)
  
  Change Details

    ## Description

  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: v2023.11.5...v2024.0.0

v2023.2.14

What's Changed

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

New Contributors

• @os-d made their first contribution in #89

Full Changelog: v2023.2.13...v2023.2.14

v2023.11.5

What's Changed

• Update nuget package bundling @Javagedes (#86)
  
  Change Details

    ## Description

  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

• Update driver integration instructions @makubacki (#85)
  
  Change Details

    ## Description

  • 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: v2023.11.3...v2023.11.5

v2023.11.3

What's Changed

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

New Contributors

• @cmruffin made their first contribution in #80

Full Changelog: v2023.11.2...v2023.11.3

v2023.11.2

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

• CryptoPkg/BaseCryptLib: Add additional RSAES-OAEP crypto functions @cmruffin & @makubacki
  
  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.
  

  
  

Full Changelog: v2023.11.1...v2023.11.2

v2023.11.1

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.

• Mu Basecore 202311 Integration @makubacki
  
  Change Details

  • Moves the MU_BASECORE submodule to release/202311
  • Makes adjustments in the CryptoBinPkg DSC to integrate libraries
  that differ in 202311 from the prior state of 202302.