microsoft / mu_crypto_release Goto Github PK

Is there an existing issue for this?

• I have searched existing issues

Current Behavior

Builds results for AARCH64 using the VS2022 toolchain don't meet expectations. Many memory sections instead of the two expected.

Additionally when testing issues are ran into.

Expected Behavior

1. Two memory sections
2. Platforms are able to use the binaries for AARCH64

Steps To Reproduce

1. Build for AARCH64 locally or with the pipeline.
2. Examine the build to see the incorrect number of memory sections.

Build Environment

- OS(s): Windows
- Tool Chain(s): VS2022
- Targets Impacted: AARCH64 crypto reliant platforms

Version Information

Top of release/202302

Urgency

Low

Are you going to fix this?

I will fix it

Do you need maintainer feedback?

No maintainer feedback needed

Anything else?

No response

Feature Overview

We don't have a direct shared crypto replacement for RuntimeCryptoLib at the moment.

Feature tracks adding a path for Runtime DXE drivers (like VariableRuntimeDxe) to also use shared crypto. This is important since the previous RuntimeCryptLib library instance was remove from CryptoPkg recently alongside the openssl submodule.

Solution Overview

Support shared crypto with Runtime DXE.

Alternatives Considered

No response

Urgency

Medium

Are you going to implement the feature request?

I will implement the feature

Do you need maintainer feedback?

No maintainer feedback needed

Anything else?

No response

Our current crypto implementation is based on openssl and has been for years. Unfortunately, we've had some issues continuing to use Openssl for this purpose such as:

1. Binary size bloat
2. Code readability and understanding
3. Lack of ability to modify the codebase

For these reasons we're exploring different sources for our underlying crypto implementation. Any findings/updates will be posted here.

Feature Overview

Currently the code to generate the shared crypto driver lives in MU_BASECORE. It makes sense to consolidate it with the actual crypto implementations in this repo.

Solution Overview

1. Move the crypto driver content to this repo.
2. Update the published binary to include .map files and symbols files.
3. Add a readme to the binary as well (that includes integration steps)

Alternatives Considered

No response

Urgency

Low

Are you going to implement the feature request?

I will implement the feature

Do you need maintainer feedback?

No maintainer feedback needed

Anything else?

No response

Feature Overview

Currently all crypto functionality in project MU is found in the CryptoPkg in MU_BASECORE and is free to reference for anyone consuming it. To reach our goal of having everyone move to our Shared Crypto binary system we're moving the functional crypto implementations into this repo where we'll build the binaries.

Solution Overview

Migrate the MbedTLS submodule and BaseCryptLib implementation of it to this repo.

Alternatives Considered

No response

Urgency

Medium

Are you going to implement the feature request?

I will implement the feature

Do you need maintainer feedback?

No maintainer feedback needed

Anything else?

No response

Feature Overview

With Crypto being such a critical path in firmware it makes sense to add code coverage to the binary. This will provide the benefit of confidence in our binaries functionality.

Solution Overview

Add code coverage testing and results to the binary build pipeline.

Alternatives Considered

No response

Urgency

High

Are you going to implement the feature request?

I will implement the feature

Do you need maintainer feedback?

No maintainer feedback needed

Anything else?

No response

Feature Overview

changes to the crypto protocol must not break compatibility and should allow a caller of a different version to still work (with limited functions). The simplest method of achieving this to only allow changes added to the end.

Solution Overview

only add functions to end
put tooling in place to enforce this

Alternatives Considered

No response

Urgency

Medium

Are you going to implement the feature request?

Someone else needs to implement the feature

Do you need maintainer feedback?

No maintainer feedback needed

Anything else?

No response

Feature Overview

Flavors allowed a creator to trim the functionality to match their needs but flavors added significant complexity and inconsistency to the crypto provider. As we look to scale the crypto binary out more broadly the complexity and incompatibility of flavors is not worth the savings.

Solution Overview

remove flavors and provide more consistent api

Alternatives Considered

No response

Urgency

Low

Are you going to implement the feature request?

Someone else needs to implement the feature

Do you need maintainer feedback?

No maintainer feedback needed

Anything else?

No response

Request Description

The build documentation (and scripts like SingleFlavorBuild.py) currently focus on building CryptoBinPkg. The build process for OpensslPkg needs to be documented.

Are you going to make the change?

Someone else needs to make the change

Do you need maintainer feedback?

No maintainer feedback needed

Anything else?

No response

Check the functionality of our currently published crypto binaries. Confirm if everything behaves as expected or if there are adjustments necessary in terms of the crypto functions supported in our different flavors.

Possible issues: Lack of SHA384 and SHA512 support in the STANDARD flavor binary. CONFIRMED

VariableSmm.c calls VariableWriteServiceInitializeSmm which eventually leads to calling AuthVariableLibInitialize which calls
SHA384 and SHA512 context functions.

Feature Overview

The BaseCryptLibUnitTestApp was being run in mu_tiano_platforms using crypto source code from MU_BASECORE/CryptoPkg. With the source backed instance of BaseCryptLib removed, mu_tiano_platforms will solely integrate crypto from the shared crypto binary.

The instances of BaseCryptLib that support dynamic interfaces (i.e. the PPI/Protocol) do not support all of the functions tested by BaseCryptLibUnitTestApp. Also, it would be ideal to test crypto binaries as part of their release flow.

Solution Overview

Run BaseCryptLibUnitTestApp in mu_crypto_release on PRs and releases.

Alternatives Considered

No response

Urgency

Low

Are you going to implement the feature request?

Someone else needs to implement the feature

Do you need maintainer feedback?

No maintainer feedback needed

Anything else?

No response

Feature Overview

Currently the Shared crypto binaries produced are only availble for PEI, DXE and SMM. With growing interest in Standalone MM having a binary for it makes sense.

Solution Overview

1. Generate a standalone MM binary for all the different Shared crypto flavors.
2. Separate DXE and SMM crypto into their own fdf files.
3. Include a Standalone MM fdf file.
4. Update the publishing script to also publish the new Standalone MM binaries.

Alternatives Considered

No response

Urgency

Medium

Are you going to implement the feature request?

Someone else needs to implement the feature

Do you need maintainer feedback?

No maintainer feedback needed

Anything else?

No response

With the sweeping repo changes it's important to make sure we're still able to generate new crypto binaries with all the changes. If there are issues with the process fixes will be necessary.

Feature Overview

Because we moved the different crypto implementations into mu_crypto_release we need to integrate edk2 changes into this repo.

Solution Overview

Have a document that describes the integration process. Additionally it might make sense to clean up the commit history to make integration easier.

Alternatives Considered

No response

Urgency

Low

Are you going to implement the feature request?

I will implement the feature

Do you need maintainer feedback?

No maintainer feedback needed

Anything else?

No response

Enabling additional crypto algorithms can change the PCR measurements and/or effect measured boot. Check if enabling SHA384 and SHA512 algorithms cause such changes.

Feature Overview

Hi,
On some specific platforms it is impossible to use a custom trustzone environment or Arm's TFA or Smm. As a result, platforms wishing to use VariableRuntimeDxe need to take a dependency on AuthVariableLib and thus a runtime implementation of BaseCryptLib. While the implementation of a runtime BaseCryptLib provider as well as a CryptoRuntimeDxe was made available recently, CryptoRuntimeDxe is not built for aarch64 and it is impossible for such platforms to continue using VariableRuntimeDxe with AuthVariableServices due to changes that removed BaseCryptLib from the basecore repository.

Solution Overview

Please provide a pre-built binary of CryptoRuntimeDxe for AArch64, solving above scenario as well as inf files pointing towards non existent efi binaries in the current nuget package.

Alternatives Considered

No response

Urgency

Medium

Are you going to implement the feature request?

Someone else needs to implement the feature

Do you need maintainer feedback?

No maintainer feedback needed

Anything else?

No response

We're currently using openssl 1.1.1 for our binary generation and it's no longer supported as of September 2023.
We'll need to move to openssl 3.0 and update our crypto implementations to match it.

Request Description

Create a shared crypto guide to describe how to ingest the SHARED CRYPTO binaries. This needs to include what random libraries are included as well as flags and debug library expectations.

Are you going to make the change?

I will make the change

Do you need maintainer feedback?

No maintainer feedback needed

Anything else?

No response

Feature Overview

Add PR gates to build the code.

Solution Overview

PR gates should bulid all code expected to succeed in the release pipeline, optionally run tests, and report status to the PR.

Alternatives Considered

No response

Urgency

Low

Are you going to implement the feature request?

Someone else needs to implement the feature

Do you need maintainer feedback?

No maintainer feedback needed

Anything else?

No response

Request Description

The release from this repo includes various crypto flavors. The functionality included in each flavor is key integration information needed for consumers to include the proper binaries in a platform firmware.

Ideally, this would be in a markdown table in the main readme (similar to the crypto family service table here).

Are you going to make the change?

Someone else needs to make the change

Do you need maintainer feedback?

No maintainer feedback needed

Anything else?

No response