CryptoPkg: Update OneCrypto binary ext_dep to v1.0.2

[Doug Flick (Flickdm)]

Description

This pull request updates the OneCrypto_ext_dep.json file to use the latest version of the OneCrypto binary. The update ensures that the dependency is current and that the integrity check matches the new release.

Dependency update:

• Updated the source URL, version, and sha256 checksum in CryptoPkg/Binaries/OneCrypto_ext_dep.json to reference OneCrypto version 1.0.2 instead of 1.0.1.

Since we're holding on to the dual copy approach - this PR is not a breaking change. If we drop this - then this may be a breaking change.

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

How This Was Tested

Single copy and dual copy via QemuArmVirtPkg

Integration Instructions

This introduces two styles of integration.

Single copy is the preferred mechanism and works when the platform supports DXE and S*MM.

Single Copy FDF

# DXE FV: loader only. Do not include OneCryptoBinDxe.
INF $(ONE_CRYPTO_PATH)/$(TARGET)/AARCH64/OneCryptoLoaders/OneCryptoLoaderDxeFromMm.inf

# Standalone MM FV
INF $(ONE_CRYPTO_PATH)/$(TARGET)/AARCH64/OneCryptoLoaders/OneCryptoLoaderStandaloneMm.inf
INF $(ONE_CRYPTO_PATH)/$(TARGET)/AARCH64/OneCryptoLoaders/OneCryptoImageProviderStandaloneMm.inf

# The sole binary copy, either directly in the Standalone MM FV:
INF $(ONE_CRYPTO_PATH)/$(TARGET)/AARCH64/OneCryptoBin/OneCryptoBinStandaloneMm.inf

# Or in a dedicated compressed FV embedded in Standalone MM, as QemuArmVirt does.

If your platform cannot communicate over a MM-Communicate channel or only supports DXE. Then the dual copy mechanism can be used. Where on the platform without S*MM you can just include only the DXE changes.

Dual Copy FDF

# DXE FV
INF $(ONE_CRYPTO_PATH)/$(TARGET)/AARCH64/OneCryptoLoaders/OneCryptoLoaderDxe.inf
INF $(ONE_CRYPTO_PATH)/$(TARGET)/AARCH64/OneCryptoBin/OneCryptoBinDxe.inf

# Standalone MM FV
INF $(ONE_CRYPTO_PATH)/$(TARGET)/AARCH64/OneCryptoLoaders/OneCryptoLoaderStandaloneMm.inf
INF $(ONE_CRYPTO_PATH)/$(TARGET)/AARCH64/OneCryptoBin/OneCryptoBinStandaloneMm.inf

[mu-automation]

✅ QEMU Validation Passed

Source Dependencies

Repository	Commit
mu_basecore	aa1a66c
mu_tiano_platforms	b15d1f8

Results

Platform	Target	Build	Boot	Overall Boot Time	Build Logs	Boot Logs
Q35	DEBUG	✅ success	✅ success	0m 17s	Build Logs	Boot Logs
ArmVirt	DEBUG	✅ success	✅ success	0m 14s	Build Logs	Boot Logs

Workflow run: https://github.com/microsoft/mu_basecore/actions/runs/31064657165

This comment was automatically generated by the Mu QEMU PR Validation workflow.

[Doug Flick (Flickdm)]

Waiting on success from here: microsoft/mu_tiano_platforms#1460

[Doug Flick (Flickdm)]

In v1.0.3 I will revisit dropping dual copy (this will be a breaking change) - since I am losing my ability to test the binaries with the move to single copy. What will be challenging is that some platforms can't easily move off. Some platforms depend on a dxe only copy currently satisfied by dual copy.

[Michael Kubacki (makubacki)]

In v1.0.3 I will revisit dropping dual copy (this will be a breaking change) - since I am losing my ability to test the binaries with the move to single copy. What will be challenging is that some platforms can't easily move off. Some platforms depend on a dxe only copy currently satisfied by dual copy.

Can you update the integration instructions to explain when each approach should be used?