optee-client: Add support for libckteec from optee_client

[harshaldev27]

Added support for the ckteec library v4.0.0 via an optee-client recipe.

libckteec provides the PKCS#11 platform-agnostic interface for talking to cryptographic hardware such as smart cards and HSMs. It calls into the Global Platform defined standard TEE APIs for talking to the PKCS#11 Trusted Application (TA) running on the platform's TEE.

On Qualcomm platforms, these Global Platform APIs are implemented via the minkteec library and so the ckteec library must link to it instead of the teec library. This is due to Qualcomm TEE only understanding the MINK IPC protocol.

The optee-client recipe is written to only install the ckteec library from the optee-client package since the other libraries from this package cannot be currently used on Qualcomm platforms which only support QTEE. The recipe also patches the CMake file to alter it's linkage from the default teec library to minkteec.

The ckteec library interface is tested by running the pkcs11 test suite from the xtest client v4.0.0 hosted at github.com/OP-TEE/optee_test on the RB3Gen2 board with a compatible PKCS#11 TA.

[lumag]

Please submit upstream

[lumag]

Likewise

[lumag]

Why are we not using optee-client from meta-arm?

[ricardosalveti]

Both patches added here are needed because you are not building against libteec, can you please work directly with upstream to add support for building TAs with alternatives like minkteec?

[ricardosalveti]

This will break other layers that are also building optee-client, since nothing here is isolated to the qcom override.

[anujm1]

I wonder if this is even needed as the recipe is using cmake.

[ricardosalveti]

We are expecting to integrate OP-TEE (not just this TA) soon (see #1172), so NAK for including a custom optee-client recipe that is only suitable for minkipc.

What should be done here:

• Work with upstream to support building with minkipc (and remove the need for extra patches)
• Leverage the optee recipes from meta-arm, no need to duplicate any recipe, and should be aligned with the latest optee-client revision
• Supporting specific minkipc options based on the qcom override (and here should also need to find a way to support building traditional optee and just optee-client when qtee is used)

[b49020]

@harshaldev27 IIRC, last time we talked about this feature was to add support for libckteec in the minkipc library itself [1] as an immediate solution. For sure directly patching optee-client like this will break OP-TEE use-cases. The long-term solution as @ricardosalveti mentioned and we discussed earlier as well was to contribute directly to OP-TEE projects to allow for QTEE trusted OS as an alternative backend to OP-TEE OS.

[1] https://github.com/qualcomm/minkipc

[harshaldev27]

Hi @ricardosalveti , thank you so much for your comments and providing useful pointers.

We are expecting to integrate OP-TEE (not just this TA) soon (see #1172), so NAK for including a custom optee-client recipe that is only suitable for minkipc.

I think there is a slight confusion here. This PR is not for integrating the PKCS#11 Trusted Application (TA). This PR is for fetching and building the libckteec Linux library from the optee_client repo with patches to change its linkage from libteec to libminkteec provided as part of the minkipc package already integrated into meta-qcom.

Also, this PR is orthogonal to the OP-TEE enablement PR. I can see that there is a discussion on PR #1172 between @lumag and @b49020 regarding whether meta-arm should be a dynamic layer or a default layer dependency of meta-qcom. And I agree with @lumag on that discussion that right now, Kodiak currently boots with proprietary firmware blobs, QTEE (tz.mbn image) being one of them.
And so, this PR is targeting Kodiak which boots with QTEE, and not OP-TEE. As such, it appears to me that I cannot as-is leverage the recipes from meta-arm, since the optee-client recipe provided by it is building and installing all libraries/daemons from the optee_client repo, out of which only libckteec is useful when we are booting with QTEE. None of the other libraries, such as libteec, libseteec or the tee-supplicant daemon are applicable to us currently.
See: https://git.yoctoproject.org/meta-arm/tree/meta-arm/recipes-security/optee/optee-client.inc

When OP-TEE support comes, I have no doubt that these will become relevant again, and must be included as part of an alternate OPTEE-based distro configuration perhaps? (I don't know what is the plan there, please let me know)

What should be done here:

• Work with upstream to support building with minkipc (and remove the need for extra patches)

I agree with this, I believe I can try to send the patch for providing a build-time option for linking libckteec with either libteec (default) or libminkteec (for QC boards booting with QTEE). @b49020 I would appreciate your input on this.

• Leverage the optee recipes from meta-arm, no need to duplicate any recipe, and should be aligned with the latest optee-client revision

Like I mentioned, I am fine with leveraging the meta-arm recipes, but I realize that I will have to find some way to modify its behavior such that it builds libckteec with linkage to libminkteec followed by uninstallation of all the other irrelevant libraries provided by it.
Also, we cannot currently support the latest revision of optee-client from that layer, because the PKCS#11 TA currently supported by QTEE is only aligned with v4.0.0 of the libckteec library. Work for upgrading to newer versions is planned by QTEE team internally.

Is there some recommendation for writing an override for the optee-client recipe leveraged from meta-arm to achieve these objectives? If so, I'd be happy to pursue this path.

• Supporting specific minkipc options based on the qcom override (and here should also need to find a way to support building traditional optee and just optee-client when qtee is used)

I could not understand this comment fully @ricardosalveti , could you please elaborate a bit further what are you requesting here?

Thanks,
Harshal

[harshaldev27]

Hi Sumit,

@harshaldev27 IIRC, last time we talked about this feature was to add support for libckteec in the minkipc library itself > [1] as an immediate solution. For sure directly patching optee-client like this will break OP-TEE use-cases.

We did not want to pursue the temporary solution of adding libckteec code directly in minkipc for the following reasons which came to light a bit later for me:

1. The PKCS#11 TA for Kodiak is currently only supporting v4.0.0 of the libckteec library. However, work for upgrading the versions is constantly underway. Going this path would make it a repeated effort for us to support newer and newer versions of libckteec in the minkipc repo.
2. Since libckteec is not exactly related to MINK IPC. We would need some additional approvals from legal to get this going, which anyways means that this is not a immediate solution.
3. I believe being able to directly sync from the optee-client repo and support in meta-qcom is the most convenient way forward in the long-term. Allowing us to leverage both new releases and bug fixes seamlessly overtime.

Also, my intent wasn't to break any OPTEE-use cases. The .patch was meant only for this repo. Now I see based on your PR work is underway to support OP-TEE boot as well, in that case we do need a way to not affect the optee-client binaries you plan to install via recipe overrides.

The long-term solution as @ricardosalveti mentioned and we discussed earlier as well was to contribute directly to OP-TEE > projects to allow for QTEE trusted OS as an alternative backend to OP-TEE OS.

I agree, I think better to allow a build-time option which enables alternatively linking libckteec with libminkteec?

[1] https://github.com/qualcomm/minkipc

Thanks,
Harshal

[b49020]

@harshaldev27 first of all you need to understand that libckteec is a wrapper library built on top of Global platform TEE client APIs for PKCS#11 support.

optee-client added support for it since it exposes OP-TEE based TA as the PKCS#11 token with backend GP TEE APIs implementation supported via libteec. In case you want to support QTEE based GP interfaces with optee-client then you need to port libminkteec to optee-client which doesn't make sense to me.

It is rather better you import libckteec from optee-client into your minkipc repo as a submodule such that you can keep track of any updates happening for the generic wrapper. Then it will be your minkipc recipe exposing that libckteec based on libminkteec.

Handling this logic in meta-qcom as you did doesn't seem logical to patch optee-client in a way that breaks OP-TEE use-cases.

I agree with this, I believe I can try to send the patch for providing a build-time option for linking libckteec with either libteec (default) or libminkteec (for QC boards booting with QTEE). @b49020 I would appreciate your input on this.

Start a thread upstream here: https://github.com/OP-TEE/optee_client/issues with your proposal and gather feedback from the community. To me libminkteec not present in optee-client repo itself might not favor the build time option there since you can't build it standalone there.

[b49020]

@harshaldev27

The PKCS#11 TA for Kodiak is currently only supporting v4.0.0 of the libckteec library. However, work for upgrading the versions is constantly underway. Going this path would make it a repeated effort for us to support newer and newer versions of libckteec in the minkipc repo.

This effort has to be done irrespective of that since libminkteec and libckteec aren't developed in the same repo. The suggestion to import libckteec in minkipc repo gives you control over supporting future updates of libckteec.

Since libckteec is not exactly related to MINK IPC. We would need some additional approvals from legal to get this going, which anyways means that this is not a immediate solution.

Open-source projects usually have third party dependencies. Both projects follow the BSD license.

I believe being able to directly sync from the optee-client repo and support in meta-qcom is the most convenient way forward in the long-term. Allowing us to leverage both new releases and bug fixes seamlessly overtime.

Nope meta-qcom shouldn't be used to manage inter-dependencies via patching different components. It simply becomes un-manageable in the long term and especially since we want to support both QTEE and OP-TEE based stacks.