[Feature]: Add Runtime DXE shared crypto support #55
Assignees
Labels
state:needs-triage
Needs to triaged to determine next steps
type:feature-request
A new feature proposal
urgency:medium
Important with a moderate impact
Comments
makubacki
added
type:feature-request
5 tasks
makubacki
added a commit
to microsoft/mu_tiano_platforms
that referenced
this issue
Feb 1, 2024
## Description Moving forward the OpenSSL submodule will no longer be present in `CryptoPkg` and the only option to integrate crypto into the platform will be shared crypto (via the binary crypto ext dep). The option to enable/disable shared crypto is removed since disabling it is no longer an option. Notes: - Integrates newly available `AARCH64` PEI and Standalone MM shared crypto binaries. - The `BaseCryptLibUnitTest` EFI shell test is removed since it depends on functions not present in the PPI/Protocol instances of `BaseCryptLib` and the crypto releases should have the tests run before the release is made. - An issue to track this is here: microsoft/mu_crypto_release#56 - Runtime DXE crypto is not currently available. It is only needed at this time for the non-SMM instance of `QemuQ35Pkg` (`VariableRuntimeDxe`). Since this is not the primary target for `QemuQ35Pkg`, the Runtime DXE binary will be updated in the future to unblock Mu Basecore updates in Mu Tiano Platforms. - An issue to track that is here: microsoft/mu_crypto_release#55 --- Updates these submodules to the following release points: - `MU_BASECORE`: [v2023020013.1.0](https://github.com/microsoft/mu_basecore/releases/tag/v2023020013.1.0) - `Common/MU_TIANO`: [v2023020000.2.0](https://github.com/microsoft/mu_tiano_plus/releases/tag/v2023020000.2.0) - `Features/MM_SUPV`: [v8.1.8](https://github.com/microsoft/mu_feature_mm_supv/releases/tag/v8.1.8) --- - [x] Impacts functionality? - **Functionality** - Does the change ultimately impact how firmware functions? - Examples: Add a new library, publish a new PPI, update an algorithm, ... - [x] 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 - `QemuQ35Pkg` and `QemuSbsaPkg` CI build and boot. ## Integration Instructions - These changes only affect mu_tiano_platforms. Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
|
Thank you for this, I've personally been forced to take a copy of this repository to continue building the VariableRuntimeDxe driver without resorting to have variable auth handled in trustzone on specific platforms, this would make maintenance much easier. While I understand most platforms should be handling this in trustzone or MM, I think a lot of people would still want to have variable auth handled in the UEFI itself for specific reasons. Looking forward to the change, as upon investigations, we cannot currently use this repository as a submobule either due to conflicts with MU_BASECORE also containing CryptoPkg folders. (I've seen another issue in this repo working towards fixing this as well) |
|
@gus33000 thanks for the info, it's helpful to know how this can benefit others. |
5 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Feature Overview
We don't have a direct shared crypto replacement for
RuntimeCryptoLibat the moment.Feature tracks adding a path for Runtime DXE drivers (like
VariableRuntimeDxe) to also use shared crypto. This is important since the previousRuntimeCryptLiblibrary instance was remove fromCryptoPkgrecently alongside theopensslsubmodule.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
The text was updated successfully, but these errors were encountered: