CrptoPkg: introduce TPM library for software-based TPM implmentation

[LeviYeoReum]

Description

This patchset add TpmLib to be used for Software-based TPM driver.

TpmLib is wrapper library of [The TPM 2.0 Reference Implementation Library][1] and
[The TPM 2.0 Reference Implementation Library][1]'s platform part are implemented
with the PlatformTpmLib by each platform.

This will be used to implment [FtpmDxe driver][2] used by StandaloneMm so that
TPM funcionality can be supported with StandaloneMm

Patch #1 adds openssl build options to build TCG TPM 2.0 Reference Library
Patch #2 adds PlatformTpmLib which called by TCG TPM 2.0 Reference Library for handling platform specific functionalities
Patch #3-#8 add TpmLib used for software-based TPM.
Patch #9 adds GUID to handle event logs from TF-A
Patch #10 increses stack size for StandaloneMm when it use TpmLib.

For more, Please see the PR for [FtpmDxe driver][2]

References

[1] https://github.com/TrustedComputingGroup/TPM
[2] tianocore/edk2-platforms#919

[LeviYeoReum]

@samimujawar, @leiflindholm

I have two questions:

1. I've checked tpm_radix.h' format is "CRLF" with unix2dos but patch.check complains it's not a CRLF.
   Do you have any idea for this?

2. When I check the failure of CI, it doesn't seem to pull the TCG TPM library repository.
   Would you let me guide how I can make CI pull the newly added submodule -- TCG TPM library?

Thanks!

[liyi77]

hi, it is not appropriate to add tpm related feature to CryptoPkg,
please consider porting this to SecurityPkg.

[LeviYeoReum]

hi, it is not appropriate to add tpm related feature to CryptoPkg, please consider porting this to SecurityPkg.

Hi.

Since to build the TPM reference library, It's required to build:
- openssl header included via Private.
- Private library in the CryptoPkg (Cruntime).

So, at first, I've added this into the CryptoPkg instead of SecurityPkg because I couldn't find out the way to access
"Private" directories in CryptoPkg from the SecurityPkg in current edk2 build system.

Do you have any idea for this?

Thanks!

[liyi77]

Generally we do not allow packages outside of CryptoPkg to directly use OpenSSL.
You can encapsulate the necessary APIs within BaseCryptLib to decoupling.

[LeviYeoReum]

Generally we do not allow packages outside of CryptoPkg to directly use OpenSSL.

This is one of problem. openssl header file is directly included in TpmLib and
not only APIs but macros defined in the openssl header are used in TpmLib (i.e) openssl version.
I think it would be hard to solve unless directly modify the source of TCG-TPM library but it's not a good idea?

You can encapsulate the necessary APIs within BaseCryptLib to decoupling.
This is not only the APIs. but, like above in openssl, for TCG-TPM library requires to use "standard" header.
(In CryptoPkg/Libary/Include. e.x) stdio.h, stdlib.h and etc.
That's why unless we move "CryptoPkg/Library/Include" to public space to be included in other Package.

Because of these two reason, at first I've settled TpmLib in the CryptoPkg...

Or Am I missing something in your suggestions?

Thanks.

[liyi77]

Making two EDK2 submodules dependent on each other is a dangerous practice. For example, TPM might depend on OpenSSL 3.5, but EDK2 OpenSSL might need to be upgraded to 3.6, then leading to some errors.

Is it possible to implement the TPM Crypto API based on BaseCryptLib to make it independent of a specific SSL library?
If TpmCryptoXXX.c uses OpenSSL code, then implement the same API in EDK2 to avoid using this TPM file.

[LeviYeoReum]

Making two EDK2 submodules dependent on each other is a dangerous practice. For example, TPM might depend on OpenSSL 3.5, but EDK2 OpenSSL might need to be upgraded to 3.6, then leading to some errors.

Agree but... (see the below):

Is it possible to implement the TPM Crypto API based on BaseCryptLib to make it independent of a specific SSL library? If TpmCryptoXXX.c uses OpenSSL code, then implement the same API in EDK2 to avoid using this TPM file.

However, this still triggers duplicate symbol unless TCG TPM reference library calls the functions in openssl directly
even it doesn't handle the "direct header" including in the TCG TPM reference library.
IOW, without modification of TCG TPM reference library, It couldn't whatever we separates TpmCryptoXX.c and call the Wrapgper function from TCG TPM reference library source code (submodule uses the "openssl").

I don't want to modify the TCG TPM reference library source.. but try to keep as it is.

One idea I think, uses a trick with Symbolic link.. (with openssl directory link and Library/Include part).
then I think it moves to SecurityPkg.

[makubacki]

@LeviYeoReum, my understanding is that you are adding a new feature - software-based TPM with an implementation detail that it directly links OpenSSL. This doesn't justify setting aside EDK II package scope and boundaries.

Stepping back, I think you need to consider two options (1) reduce the upstream of this change to a level where it can be shared between platforms that need it and the dependencies like directly linking OpenSSL are controlled and maintained at that level or (2) abstract the dependencies so this can be shared more broadly, preferably with an RFC that explains how that will be accomplished.

[LeviYeoReum]

@LeviYeoReum, my understanding is that you are adding a new feature - software-based TPM with an implementation detail that it directly links OpenSSL. This doesn't justify setting aside EDK II package scope and boundaries.

Stepping back, I think you need to consider two options (1) reduce the upstream of this change to a level where it can be shared between platforms that need it and the dependencies like directly linking OpenSSL are controlled and maintained at that level or (2) abstract the dependencies so this can be shared more broadly, preferably with an RFC that explains how that will be accomplished.

Hmm, anyay it seems to modify the TPM TCG submodule to use "edk2" openssl wrapper for abstraction of dependency.
Currently:
TpmLib -> use TCG TPM submodule -> direct call openssl.

That why, to build TCG TPM submodule without any modification, I've located it in CryptoPkg
so that, openssl functions will be directly called TCG TPM submodule which doesn't know "edk2 wrapper".
As You and Yi Li point out, To abstract the dependency of openssl in edk2 source scope:
TpmLib -> TCG TPM submodule -> Some wrapper of Openssl -> openssl function.

But this requires "TCG TPM submodule" need to change the "openssl call" to "wrapper Openssl call".

TBH, Nothing immediately comes to mind wihtout modify the "TCG TPM submodule" for abstration of dependency.
And If it seems break the EDK ll packages boundaries and CryptoPkg does not a proper place,
I think it moves to edk2-platform/Platform/ARM to mange Openssl version independantly in there to collaborate with TCG TPM submodule. IOW reduces the shared scope into ARM only.

@samimujawar

Any thougt?

[liyi77]

Similar issues arose when introducing SPDM, FYI:
https://github.com/tianocore/edk2/blob/master/SecurityPkg/DeviceSecurity/OsStub/CryptlibWrapper/CryptlibWrapper.c
https://github.com/DMTF/libspdm/blob/main/os_stub/cryptlib_openssl/pk/x509.c

[ardbiesheuvel]

If I understand the feedback from @liyi77 and @makubacki correctly, it amounts to

• this library must not be placed in CryptoPkg
• this library must not create a cross-package dependency.

However, if the implementation of the library in question is as tightly coupled to OpenSSL as @LeviYeoReum claims it is (which I have no reason to doubt), I think CryptoPkg is the only reasonable place for it. Whether or not that means that the library class /definition/ (and a suitable NULL implementation) should live somewhere else (e.g., MdeModulePkg) is a thing we could discuss. But completely re-architecting how this existing piece of code interfaces with OpenSSL just to comply with our packaging rules is not the right way to go about this IMHO.

@LeviYeoReum For the sake of further discussion, could you provide a high level overview of the components, their roles in the overall functionality that you are adding, and how tightly each is coupled to OpenSSL.

Taking a step back, it would be good to also have some input on the desirability of this feature in combination with the use case it aims to enable, i.e., implementing a software TPM in standalone MM. To me, that sounds really useful, but perhaps there is prior art here? Or are there other concerns with the chosen approach?

[liyi77]

@LeviYeoReum For the sake of further discussion, could you provide a high level overview of the components, their roles in the overall functionality that you are adding, and how tightly each is coupled to OpenSSL.

Taking a step back, it would be good to also have some input on the desirability of this feature in combination with the use case it aims to enable, i.e., implementing a software TPM in standalone MM. To me, that sounds really useful, but perhaps there is prior art here? Or are there other concerns with the chosen approach?

Agree with this, we can discuss the necessity of this feature first, and then see if any compromises are needed.
Recommend to send email to community [email protected] to introduce your proposal and the current issues.

[LeviYeoReum]

Sorry for late answer. but at first, Let me make a brief in the github
and send it to mailing list.

@LeviYeoReum For the sake of further discussion, could you provide a high level overview of the components, their roles in the overall functionality that you are adding, and how tightly each is coupled to OpenSSL.

TpmLib provides Software-based TPM via TCG TPM v2.0 Reference Library (https://github.com/TrustedComputingGroup/TPM) and this TCG TPM v2.0 Library is consist of

                                        +----------------+
                                        |   TCG TPM LIB  |
                                        +----------------+
                                                 |
                                                 |
                              -------------------------------------
                              |                                   |
          +----------------------------+                      +-------------------------+
          |    Crypto / BigInt Library |                      |     Platform Layer      |
          |    (openssl or worfs)      |                      |  (TPMCmd/Platform/src)  |
          +----------------------------+                      +-------------------------+
                                  

Unfortunately, like:

Similar issues arose when introducing SPDM, FYI:
https://github.com/tianocore/edk2/blob/master/SecurityPkg/DeviceSecurity/OsStub/CryptlibWrapper/CryptlibWrapper.c
https://github.com/DMTF/libspdm/blob/main/os_stub/cryptlib_openssl/pk/x509.c

TCG TPM v2.0 Library provides but it with the "header files" and clung to "build option"
See (https://github.com/TrustedComputingGroup/TPM/tree/main/TPMCmd/tpm/cryptolibs).

I think by overriding the Header file, it seems to implments with the Wrapper of openssl.
However, I think it would be better to use openssl directly if possible.
Therefore, at first this patchset, locate TpmLib in the CryptoPkg for TCG TPM v2.0 Library uses openssl directly.

The Platform Layer is implmented by PlatformTpmLib.
and TpmLib provides bridge layer to let TCG TPM lilbrary call platform functions (_plat_XXX()) to be delivered correspondant function implmented by PlatformTpmLib implmented according to the platform.

      +----------------------+ 
      |       Driver         |
      |    (FtpmDxe - StMM)  |
      +----------------------+ 
                 |
        +---------------+                     +---------------+   crypto/BigInt           +-------------+
        |    TpmLib    |  ------------------> |  TCG TPM Lib  | ----------------------->  |  Openssl    |
        +---------------+                     +---------------+            |              +-------------+ 
                                                                           |
                                                                           |
                                                                           |
                                                                           |
          +--------------------------------+                    +-----------------------------+
          |      PlatformTpmLib            |  <--------------- - |       Platform Layer        |
          |    (via TpmPlatformFunctions.c |                    | (via TpmPlatformFunctions.c)|
          +--------------------------------+                    +-----------------------------+

Taking a step back, it would be good to also have some input on the desirability of this feature in combination with the use case it aims to enable, i.e., implementing a software TPM in standalone MM. To me, that sounds really useful, but perhaps there is prior art here? Or are there other concerns with the chosen approach?

About prior art, Not yet. But I'll share the other use cases later.
Currently I can tell you that like the FVP where use StandaloneMm with absent of physical TPM,
That's useful for Measurement Boot.
Though simulator of TPM runs at normal world,
But, we want to keep the TPM related data in Secure world to prevent leak.
and This TPM could be co-worred with other subsystem (IMA and etc).

[makubacki]

I think it moves to edk2-platform/Platform/ARM to manage Openssl version independently in there to collaborate with TCG TPM submodule. IOW reduces the shared scope into ARM only.

It does not need to fall under an Arm-specific directory. The /Features directory is a place to share vendor neutral features.

Note that most of the Intel features were placed under a "Features/Intel" directory at the time because they were only tested on Intel platforms and had not been pitched for broader acceptance. It is not a requirement for a feature to be placed in a vendor-specific directory.

---

Regardless of everything else, submodules in edk2 cause problems for consumers. It introduces dependencies that trip dependency injection and supply chain processes run at many companies because submodules are using dangerous/outdated dependencies themselves. It bloats the workspace for features that may never be used by a platform.

This was and still is a problem with openssl, libspdm (which itself, uses openssl and mbedtls submodules), and others. Those are just recent examples.

There is also an effort to separate OpenSSL from CryptoPkg to its own package (e.g. OpenSslPkg) that has been discussed. And the coupling introduced here would be more problematic at a time like that, because this doesn't depend on EDK II crypto which CryptoPkg exposes an abstraction for, it depends on OpenSSL.

---

Is there a problem hosting this in the Features area of edk2-platforms?