minkipc: Update tag to v1.2.4 to add support for PKCS#11 by harshaldev27 · Pull Request #1707 · qualcomm-linux/meta-qcom

harshaldev27 · 2026-03-07T13:51:25Z

Updated minkipc tag to v1.2.4 which brings support for PKCS#11 on Qualcomm platforms with QTEE support.

The support is provided through optee_client and optee_test repos v4.0.0 which are placed in the optee-client/ and optee-test/ sub directories. Only the PKCS#11 relevant library and test suites are built and supported, i.e.
libckteec_qtee and xtest_qtee (pkcs11-tests). The recipe license is updated to reflect the licenses of these repos.

The PKCS#11 test-signed Trusted Application binaries is also installed for supported targets (qcm6490, qcs9100, qcs8300 and qcs615) under /lib/qtee-tas as per conclusions in #1454.

On an RPMB provisioned device, the pkcs11-tests can be run by invoking the xtest_qtee binary.

The changes in this PR are as per conclusions based on discussions in the older PR: #1379

Depends on: PR #1733 and PR #1895

ricardosalveti · 2026-03-07T18:12:02Z

Some issues:

WARNING: minkipc-1.2.1-r0 do_fetch: Submodule included by gitsm://github.com/qualcomm/minkipc.git;branch=main;protocol=https;tag=v1.2.1 refers to relative ssh reference git@github.com:OP-TEE/optee_client.git.  References may fail if not absolute.
WARNING: minkipc-1.2.1-r0 do_fetch: Submodule included by gitsm://github.com/qualcomm/minkipc.git;branch=main;protocol=https;tag=v1.2.1 refers to relative ssh reference git@github.com:OP-TEE/optee_test.git.  References may fail if not absolute.
WARNING: minkipc-1.2.1-r0 do_fetch: Submodule included by gitsm://github.com/qualcomm/minkipc.git;branch=main;protocol=https;tag=v1.2.1 refers to relative ssh reference git@github.com:OP-TEE/optee_client.git.  References may fail if not absolute.
WARNING: minkipc-1.2.1-r0 do_fetch: Submodule included by gitsm://github.com/qualcomm/minkipc.git;branch=main;protocol=https;tag=v1.2.1 refers to relative ssh reference git@github.com:OP-TEE/optee_test.git.  References may fail if not absolute.
WARNING: minkipc-1.2.1-r0 do_unpack: Submodule included by gitsm://github.com/qualcomm/minkipc.git;branch=main;protocol=https;tag=v1.2.1 refers to relative ssh reference git@github.com:OP-TEE/optee_client.git.  References may fail if not absolute.
WARNING: minkipc-1.2.1-r0 do_unpack: Submodule included by gitsm://github.com/qualcomm/minkipc.git;branch=main;protocol=https;tag=v1.2.1 refers to relative ssh reference git@github.com:OP-TEE/optee_test.git.  References may fail if not absolute.

You are now installing components of the optee upstream project, make sure this is reflected in the LICENSE description as well.

Also, you should either include as a static library or rename the dynamic library as it will conflict with the same ones provided by optee_client, see the build failure https://github.com/qualcomm-linux/meta-qcom/actions/runs/22800268333/job/66143198461?pr=1707 (path conflict).

image/usr/lib/libckteec.so
image/usr/lib/libckteec.so.0
image/usr/lib/libckteec.so.0.1.0
image/usr/bin/xtest

For xtest, make it specific to this recipe as well.

anujm1 · 2026-03-09T01:33:48Z

Would it be better to include these explicitly in SRC_URI instead of using gitsm:// so we know what is being fetched?

harshaldev27 · 2026-03-09T08:13:10Z

Hi @ricardosalveti,

Some issues:

WARNING: minkipc-1.2.1-r0 do_fetch: Submodule included by gitsm://github.com/qualcomm/minkipc.git;branch=main;protocol=https;tag=v1.2.1 refers to relative ssh reference git@github.com:OP-TEE/optee_client.git.  References may fail if not absolute.
WARNING: minkipc-1.2.1-r0 do_fetch: Submodule included by gitsm://github.com/qualcomm/minkipc.git;branch=main;protocol=https;tag=v1.2.1 refers to relative ssh reference git@github.com:OP-TEE/optee_test.git.  References may fail if not absolute.
WARNING: minkipc-1.2.1-r0 do_fetch: Submodule included by gitsm://github.com/qualcomm/minkipc.git;branch=main;protocol=https;tag=v1.2.1 refers to relative ssh reference git@github.com:OP-TEE/optee_client.git.  References may fail if not absolute.
WARNING: minkipc-1.2.1-r0 do_fetch: Submodule included by gitsm://github.com/qualcomm/minkipc.git;branch=main;protocol=https;tag=v1.2.1 refers to relative ssh reference git@github.com:OP-TEE/optee_test.git.  References may fail if not absolute.
WARNING: minkipc-1.2.1-r0 do_unpack: Submodule included by gitsm://github.com/qualcomm/minkipc.git;branch=main;protocol=https;tag=v1.2.1 refers to relative ssh reference git@github.com:OP-TEE/optee_client.git.  References may fail if not absolute.
WARNING: minkipc-1.2.1-r0 do_unpack: Submodule included by gitsm://github.com/qualcomm/minkipc.git;branch=main;protocol=https;tag=v1.2.1 refers to relative ssh reference git@github.com:OP-TEE/optee_test.git.  References may fail if not absolute.

It appears the warnings are because minkipc is using an ssh url instead of an http url. I will fix this and update the tag.
Ack.

You are now installing components of the optee upstream project, make sure this is reflected in the LICENSE description as well.

So I realize that the sources we're building and shipping from optee-test and optee-client require us to include the BSD-2-Clause and GPL-2.0-only license. But I don't think there's a way to add checksums for these licenses by referring the paths for the submodules.

LICENSE = "BSD-3-Clause & BSD-2-Clause & GPL-2.0-only"
LIC_FILES_CHKSUM = "file://COPYING;md5=abcd1234 \
**file://<what path to provide here?>**"

Should I add these two licenses to the minkipc repo to allow checksum comparison? Legal did not comment on this but I think this should be done.

Also, you should either include as a static library or rename the dynamic library as it will conflict with the same ones provided by optee_client, see the build failure https://github.com/qualcomm-linux/meta-qcom/actions/runs/22800268333/job/66143198461?pr=1707 (path conflict).
image/usr/lib/libckteec.so
image/usr/lib/libckteec.so.0
image/usr/lib/libckteec.so.0.1.0
image/usr/bin/xtest
For xtest, make it specific to this recipe as well.

I am reluctant to change the name of these libraries because users could get confused why the library names have been changed if they are built using exactly the same sources as the ones built by optee_client recipe and provide exactly the same functionality.

I had a chat with @b49020 and I think the better approach here would be to skip building minkipc packages for builds with OPTEE support instead of QTEE. Perhaps I should raise a change in meta-qcom-distro where we only include the minkipc package in packgagegroup-qcom-security if MACHINE_FEATURES =! "optee". Please let me know if you are fine with this approach.

harshaldev27 · 2026-03-09T08:17:04Z

Hi @anujm1,

Would it be better to include these explicitly in SRC_URI instead of using gitsm:// so we know what is being fetched?

It's easy to check this by looking at the .gitmodules file in the minkipc repo. 😄

anujm1 · 2026-03-09T08:19:53Z

Hi @anujm1,

Would it be better to include these explicitly in SRC_URI instead of using gitsm:// so we know what is being fetched?

It's easy to check this by looking at the .gitmodules file in the minkipc repo. 😄

I know how to check those. But I won't go to the repository every time I'm looking at the recipe. It also doesn't say which revision is being fetched. It also should be checked whether these are included in SBoM correctly.

harshaldev27 · 2026-03-09T08:32:56Z

Hi @anujm1,

Would it be better to include these explicitly in SRC_URI instead of using gitsm:// so we know what is being fetched?

It's easy to check this by looking at the .gitmodules file in the minkipc repo. 😄

I know how to check those. But I won't go to the repository every time I'm looking at the recipe. It also doesn't say which revision is being fetched. It also should be checked whether these are included in SBoM correctly.

Agreed, but as per the original PR I did try to create a separate recipe for fetching the optee-test and optee-client repos for building these modules. However, the concern over there was that meta-arm layer is already providing these recipes, and so creating a new recipe in meta-qcom for these does not feel right. To address this, it was suggested to go the submodules way. I agree that submodules have the limitation of not clearly communicating what all is being fetched, but perhaps we can provide this information separately and explicitly? By maintaining the revision tag versions as a comment in the recipe?

As for SBoM, I can see from the Yocto documentation that we do generate a list of all compiled sources. This, along with the added license information for the submodules in the minkipc recipe should provide everything we need. If there is some explicit SBoM data you are concerned about, do let me know:

https://docs.yoctoproject.org/next/dev-manual/sbom.html

Add a description of the compiled source files used to generate host tools and target packages ([SPDX_INCLUDE_COMPILED_SOURCES](https://docs.yoctoproject.org/next/ref-manual/variables.html#term-SPDX_INCLUDE_COMPILED_SOURCES))

anujm1 · 2026-03-09T10:51:59Z

Agreed, but as per the original PR I did try to create a separate recipe for fetching the optee-test and optee-client repos for building these modules. However, the concern over there was that meta-arm layer is already providing these recipes, and so creating a new recipe in meta-qcom for these does not feel right. To address this, it was suggested to go the submodules way.

I didn't suggest separate recipes. I was asking about adding these to SRC_URI explicitly instead of using gitsm://.

ricardosalveti · 2026-03-09T16:26:10Z

Agreed, but as per the original PR I did try to create a separate recipe for fetching the optee-test and optee-client repos for building these modules. However, the concern over there was that meta-arm layer is already providing these recipes, and so creating a new recipe in meta-qcom for these does not feel right. To address this, it was suggested to go the submodules way.

I didn't suggest separate recipes. I was asking about adding these to SRC_URI explicitly instead of using gitsm://.

Yeah, I would also prefer to have the submodules as part of SRC_URI, a lot easier to identify what the recipe is bringing on.

ricardosalveti · 2026-03-09T16:29:56Z

You are now installing components of the optee upstream project, make sure this is reflected in the LICENSE description as well.

So I realize that the sources we're building and shipping from optee-test and optee-client require us to include the BSD-2-Clause and GPL-2.0-only license. But I don't think there's a way to add checksums for these licenses by referring the paths for the submodules.

Add the submodules as part of SRC_URI and you will be able to include them.

Should I add these two licenses to the minkipc repo to allow checksum comparison? Legal did not comment on this but I think this should be done.

No need, we just need to point to the license files available as part of the other repos.

Also, you should either include as a static library or rename the dynamic library as it will conflict with the same ones provided by optee_client, see the build failure https://github.com/qualcomm-linux/meta-qcom/actions/runs/22800268333/job/66143198461?pr=1707 (path conflict).
image/usr/lib/libckteec.so
image/usr/lib/libckteec.so.0
image/usr/lib/libckteec.so.0.1.0
image/usr/bin/xtest
For xtest, make it specific to this recipe as well.
I am reluctant to change the name of these libraries because users could get confused why the library names have been changed if they are built using exactly the same sources as the ones built by optee_client recipe and provide exactly the same functionality.

I had a chat with @b49020 and I think the better approach here would be to skip building minkipc packages for builds with OPTEE support instead of QTEE. Perhaps I should raise a change in meta-qcom-distro where we only include the minkipc package in packgagegroup-qcom-security if MACHINE_FEATURES =! "optee". Please let me know if you are fine with this approach.

This won't work, our target is to have one single rootfs that would work with both normal optee recipes and minkipc. And in your case they are not providing the same thing, just the same files, so we would need to rename them.

b49020 · 2026-03-10T06:16:17Z

I had a chat with @b49020 and I think the better approach here would be to skip building minkipc packages for builds with OPTEE support instead of QTEE. Perhaps I should raise a change in meta-qcom-distro where we only include the minkipc package in packgagegroup-qcom-security if MACHINE_FEATURES =! "optee". Please let me know if you are fine with this approach.

This won't work, our target is to have one single rootfs that would work with both normal optee recipes and minkipc. And in your case they are not providing the same thing, just the same files, so we would need to rename them.

That sounds like nice end objective which is in line with standard distros like Debian too. @harshaldev27 let's just rename to following:

libckqteec.so*
xtest_qtee

Anyhow, in the longer run we need to start discussions in upstream OP-TEE project for proper integration of QTEE implementation.

harshaldev27 · 2026-03-10T12:06:08Z

Agreed, but as per the original PR I did try to create a separate recipe for fetching the optee-test and optee-client repos for building these modules. However, the concern over there was that meta-arm layer is already providing these recipes, and so creating a new recipe in meta-qcom for these does not feel right. To address this, it was suggested to go the submodules way.

I didn't suggest separate recipes. I was asking about adding these to SRC_URI explicitly instead of using gitsm://.

Ack. Thank you for this suggestion @anujm1

harshaldev27 · 2026-03-10T12:07:07Z

Agreed, but as per the original PR I did try to create a separate recipe for fetching the optee-test and optee-client repos for building these modules. However, the concern over there was that meta-arm layer is already providing these recipes, and so creating a new recipe in meta-qcom for these does not feel right. To address this, it was suggested to go the submodules way.

I didn't suggest separate recipes. I was asking about adding these to SRC_URI explicitly instead of using gitsm://.

Yeah, I would also prefer to have the submodules as part of SRC_URI, a lot easier to identify what the recipe is bringing on.

Ack.

You are now installing components of the optee upstream project, make sure this is reflected in the LICENSE description as well.

So I realize that the sources we're building and shipping from optee-test and optee-client require us to include the BSD-2-Clause and GPL-2.0-only license. But I don't think there's a way to add checksums for these licenses by referring the paths for the submodules.

Add the submodules as part of SRC_URI and you will be able to include them.

Ack.

Should I add these two licenses to the minkipc repo to allow checksum comparison? Legal did not comment on this but I think this should be done.

No need, we just need to point to the license files available as part of the other repos.

Ack.

harshaldev27 · 2026-03-10T12:12:42Z

I had a chat with @b49020 and I think the better approach here would be to skip building minkipc packages for builds with OPTEE support instead of QTEE. Perhaps I should raise a change in meta-qcom-distro where we only include the minkipc package in packgagegroup-qcom-security if MACHINE_FEATURES =! "optee". Please let me know if you are fine with this approach.

This won't work, our target is to have one single rootfs that would work with both normal optee recipes and minkipc. And in your case they are not providing the same thing, just the same files, so we would need to rename them.

That sounds like nice end objective which is in line with standard distros like Debian too. @harshaldev27 let's just rename to following:
libckqteec.so*
xtest_qtee
Anyhow, in the longer run we need to start discussions in upstream OP-TEE project for proper integration of QTEE implementation.

I'm trying to take a step back and really think through if this is the only way forward. My biggest concern is, once we have changed the name of the library (I don't care about xtest since it's a test binary anyway), and customers start linking to it, it will be very difficult to convince them in a subsequent release which re-names it again to libckteec (through meta-arm layer) to migrate back to libckteec. Not to mention that it will break their applications until they do so. Maybe we'll have to create libckqteec as a symlink to the final libckteec through the meta-arm layer?

lumag · 2026-03-10T14:44:23Z

I'd prefer if we can have a single roofs which can work in both QTEE and OPTEE cases.

ricardosalveti · 2026-03-10T18:28:18Z

I'm trying to take a step back and really think through if this is the only way forward. My biggest concern is, once we have changed the name of the library (I don't care about xtest since it's a test binary anyway), and customers start linking to it, it will be very difficult to convince them in a subsequent release which re-names it again to libckteec (through meta-arm layer) to migrate back to libckteec. Not to mention that it will break their applications until they do so. Maybe we'll have to create libckqteec as a symlink to the final libckteec through the meta-arm layer?

If they are providing the same symbols, sure, a link would be enough. Otherwise we will just have to document the breaking changes saying they will have to rebuild against an updated ckteec implementation (from the upstream project).

We expect this to be temporary anyway.

harshaldev27 · 2026-03-11T07:47:20Z

I'm trying to take a step back and really think through if this is the only way forward. My biggest concern is, once we have changed the name of the library (I don't care about xtest since it's a test binary anyway), and customers start linking to it, it will be very difficult to convince them in a subsequent release which re-names it again to libckteec (through meta-arm layer) to migrate back to libckteec. Not to mention that it will break their applications until they do so. Maybe we'll have to create libckqteec as a symlink to the final libckteec through the meta-arm layer?

If they are providing the same symbols, sure, a link would be enough. Otherwise we will just have to document the breaking changes saying they will have to rebuild against an updated ckteec implementation (from the upstream project).

We expect this to be temporary anyway.

Yeah, well I think that in the long run, being able to support pkcs11 for QTEE directly from tip of meta-arm and optee-client is going to be a big step that will require QTEE PKCS11 TA updates as well. We can continue to support libckqteec until that becomes possible. Once we have reached that milestone and customers have migrated to libckteec for latest PKCS11 version, we can deprecate libckqteec and corresponding old PKCS11 TA version support from subsequent minkipc releases.

So Ack.

harshaldev27 · 2026-03-11T12:12:15Z

I just wanted to take a moment to double confirm that the alignment we reached on PR #1379 is still valid. That is, once we have optee-client supporting build-flags to selectively build libckteec with linkage to libminkteec, we are fine with introducing a optee-client_%.bbappend file to pass these flags when MACHINE_FEATURES != "optee". I hope this doesn't conflict with the 'single rootfs for all machines' goal since the rootfs remains same, just the library is built differently.

Do let me know since I am relying on this alignment to remain true in the long term.

lumag · 2026-03-11T13:21:09Z

since the rootfs remains same

If its contents depends on machine features, it's not the same.

harshaldev27 · 2026-03-11T14:55:21Z

Well then, this means to meet the goal of a single rootfs for all machines, we need to indefinitely continue with a separate name for the variant of libckteec for QTEE. This discussion also seems to imply that no usage of MACHINE_FEATURES is going to be allowed within any of the recipes.

ricardosalveti · 2026-03-11T15:00:24Z

I just wanted to take a moment to double confirm that the alignment we reached on PR #1379 is still valid. That is, once we have optee-client supporting build-flags to selectively build libckteec with linkage to libminkteec, we are fine with introducing a optee-client_%.bbappend file to pass these flags when MACHINE_FEATURES != "optee". I hope this doesn't conflict with the 'single rootfs for all machines' goal since the rootfs remains same, just the library is built differently.

Do let me know since I am relying on this alignment to remain true in the long term.

Ideally we should try to identify a way to not have exclusive build time options (optee or minkipc) like decision via configuration files, dynamic loading the right library, runtime decision based on what is exposed by the kernel, etc.

We can still leverage MACHINE_FEATURES if the flag is not excluding other options.

harshaldev27 · 2026-03-11T16:05:28Z

We can still leverage MACHINE_FEATURES if the flag is not excluding other options.

But aren't we already violating this as part of OPTEE package-group? Where we are only installing optee related libraries when the MACHINE_FEATURES contains 'optee':
https://github.com/qualcomm-linux/meta-qcom/blob/master/dynamic-layers/meta-arm/recipes-security/packagegroups/packagegroup-optee.bb#L6

I understand the overall pros of not wanting too many complex build time configurations to decide what goes into rootfs and what doesn't. But we already seem to have minor deviations from it at places like above.

If we want to pursue filling the same rootfs with all libraries for all firmware for all machines (e.g. maintaining all Trusted Application binaries for all QC chipsets in the same rootfs), then at some point we are going to run into a problem like this one, where we need to create re-named variants of the library (which used to be build-time configured) for each specific FW that the machine supports like libckqteec and libckteec in our case. This directly conflicts with the aim of leveraging meta-arm recipes for providing the same libraries for both QTEE and OPTEE to lower maintenance burden. Because unless we somehow configure those libraries (libckteec in our case) provided by the optee-client recipe to work with QTEE fw related libraries libminkteec, the only way out is to create a fork of the optee-client repo for QTEE which builds its own libckqteec with all the related changes.

At this point this seems like a question of weighing the cost, is it cheaper to create a fork whenever we run into a situation like this or it is cheaper to allow the use of MACHINE_FEATURES to build-time configure such FW related libraries?

In this particular case, I feel just using MACHINE_FEATURES != "optee" is a lot simpler in the long run. But I will let the maintainers take the final call on this.

ricardosalveti · 2026-03-11T16:15:01Z

We can still leverage MACHINE_FEATURES if the flag is not excluding other options.

But aren't we already violating this as part of OPTEE package-group? Where we are only installing optee related libraries when the MACHINE_FEATURES contains 'optee': https://github.com/qualcomm-linux/meta-qcom/blob/master/dynamic-layers/meta-arm/recipes-security/packagegroups/packagegroup-optee.bb#L6

Installing additional packages when the feature is available is completely fine, this is not removing support for other targets.

A generic image would include everything by default, here we're just optimizing the build per board while we don't have a working and generic armv8 build for all qcom targets (which is the case for debian already).

harshaldev27 · 2026-04-07T06:45:19Z

Test playlist failing because of issues un-related to us. @ricardosalveti may I request your review once again.

github-actions · 2026-04-07T16:06:37Z

Test run workflow

Test jobs for commit `bc33f30`

Test	dragonboard-820c	qcs615-adp-air	qcs6490	qcs8300	qcs9100	qcs9100-rb8	qrb2210-rb1
AudioRecord	🚫	✅ pass	✅ pass	✅ pass	✅ pass	🚫	✅ pass
BT_FW_KMD_Service	🚫	🚫	🚫	🚫	🚫	✅ pass	✅ pass
BT_ON_OFF	🚫	⚠️ skip	⚠️ skip	❌ fail	❌ fail	⚠️ skip	✅ pass
BT_SCAN	🚫	🚫	🚫	🚫	🚫	✅ pass	❌ fail
CPUFreq_Validation	🚫	✅ pass	✅ pass	✅ pass	✅ pass	✅ pass	✅ pass
DSP_AudioPD	🚫	✅ pass	✅ pass	✅ pass	✅ pass	✅ pass	✅ pass
Ethernet	🚫	✅ pass	✅ pass	✅ pass	✅ pass	⚠️ skip	⚠️ skip
Interrupts	🚫	✅ pass	✅ pass	✅ pass	✅ pass	✅ pass	✅ pass
KMSCube	🚫	⚠️ skip	⚠️ skip	⚠️ skip	✅ pass	✅ pass	✅ pass
OpenCV	🚫	✅ pass	✅ pass	✅ pass	✅ pass	✅ pass	✅ pass
WiFi_Firmware_Driver	🚫	✅ pass	✅ pass	✅ pass	✅ pass	✅ pass	✅ pass
WiFi_OnOff	🚫	⚠️ skip	⚠️ skip	✅ pass	✅ pass	⚠️ skip	✅ pass
adsp_remoteproc	🚫	✅ pass	✅ pass	✅ pass	✅ pass	✅ pass	✅ pass
boot	✅ pass	✅ pass	✅ pass	✅ pass	✅ pass	✅ pass	✅ pass
cdsp_remoteproc	🚫	✅ pass	✅ pass	✅ pass	✅ pass	✅ pass	⚠️ skip
core_auth	🚫	✅ pass	✅ pass	✅ pass	✅ pass	✅ pass	✅ pass
fastrpc_test	🚫	✅ pass	✅ pass	✅ pass	✅ pass	✅ pass	✅ pass
hotplug	🚫	✅ pass	✅ pass	✅ pass	✅ pass	✅ pass	✅ pass
irq	🚫	✅ pass	✅ pass	✅ pass	✅ pass	✅ pass	✅ pass
weston-simple-egl	🚫	⚠️ skip	⚠️ skip	⚠️ skip	⚠️ skip	⚠️ skip	⚠️ skip

All jobs summary

Job ID	Device	State	Health
171846	qrb2210-rb1	Finished	Complete
171854	qcs6490	Finished	Complete
171830	qcs615-adp-air	Finished	Complete
171833	qrb2210-rb1	Finished	Incomplete
171851	qcs9100-rb8	Finished	Complete
171329	qcs615-adp-air	Finished	Complete
171336	qcs9100-rb8	Finished	Complete
171824	qcs9100	Finished	Incomplete
171845	qcs9100-rb8	Finished	Complete
171849	qcs9100	Finished	Incomplete
171342	qcs615-adp-air	Finished	Complete
171353	qcs6490	Finished	Complete
171332	qcs615-adp-air	Finished	Complete
171333	qcs9100-rb8	Finished	Complete
171829	qcs9100-rb8	Finished	Complete
171848	qcs9100	Finished	Complete
171855	qcs8300	Finished	Complete
171820	dragonboard-820c	Finished	Complete
171856	qrb2210-rb1	Finished	Complete
171840	qcs8300	Finished	Incomplete
171844	qcs9100-rb8	Finished	Complete
171835	qcs9100	Finished	Complete
171823	qcs8300	Finished	Incomplete
171827	qrb2210-rb1	Finished	Complete
171334	qcs9100	Finished	Complete
171341	qcs8300	Finished	Complete
171839	qcs6490	Finished	Complete
171825	qcs8300	Finished	Incomplete
171347	qcs8300	Finished	Complete
171841	qcs6490	Finished	Complete
171822	qcs9100	Finished	Complete
171831	qcs9100-rb8	Finished	Incomplete
171331	dragonboard-820c	Finished	Complete
171834	qcs9100-rb8	Finished	Complete
171850	qcs615-adp-air	Finished	Complete
171853	qcs8300	Finished	Complete
171344	qcs6490	Finished	Complete
171339	qcs9100-rb8	Finished	Complete
171337	qrb2210-rb1	Finished	Complete
171852	qcs615-adp-air	Running	Unknown
171838	qrb2210-rb1	Finished	Complete
171338	dragonboard-820c	Finished	Complete
171327	dragonboard-820c	Finished	Incomplete
171326	qcs9100	Finished	Complete
171343	qrb2210-rb1	Finished	Complete
171350	dragonboard-820c	Finished	Complete
171340	qcs8300	Finished	Complete
171843	qrb2210-rb1	Finished	Complete
171349	qcs6490	Finished	Complete
171346	qcs6490	Finished	Incomplete
171837	qcs615-adp-air	Finished	Complete
171836	qcs6490	Finished	Incomplete
171345	qrb2210-rb1	Finished	Complete
171330	qcs9100-rb8	Finished	Complete
171826	qcs8300	Finished	Complete
171828	qcs9100	Finished	Complete
171832	qcs6490	Finished	Complete
171328	qrb2210-rb1	Finished	Complete
171351	qcs615-adp-air	Finished	Complete
171842	qcs615-adp-air	Finished	Complete
171819	qcs6490	Finished	Complete
171847	qcs615-adp-air	Finished	Incomplete
171857	qcs6490	Finished	Incomplete
171352	qcs9100	Finished	Complete
171335	qcs9100	Finished	Complete
171348	qcs8300	Finished	Complete

github-actions · 2026-04-07T16:56:38Z

Test run workflow

Test jobs for commit `bc33f30`

Test	dragonboard-820c	qcs615-adp-air	qcs6490	qcs8300	qcs9100	qcs9100-rb8	qrb2210-rb1
AudioRecord	🚫	✅ pass	✅ pass	✅ pass	✅ pass	✅ pass	✅ pass
BT_FW_KMD_Service	🚫	🚫	✅ pass	✅ pass	🚫	✅ pass	✅ pass
BT_ON_OFF	🚫	❌ fail	❌ fail	❌ fail	❌ fail	⚠️ skip	✅ pass
BT_SCAN	🚫	🚫	✅ pass	✅ pass	🚫	✅ pass	✅ pass
CPUFreq_Validation	🚫	✅ pass	✅ pass	✅ pass	✅ pass	✅ pass	✅ pass
DSP_AudioPD	🚫	✅ pass	✅ pass	✅ pass	✅ pass	✅ pass	✅ pass
Ethernet	🚫	✅ pass	✅ pass	✅ pass	✅ pass	⚠️ skip	⚠️ skip
Interrupts	🚫	✅ pass	✅ pass	✅ pass	✅ pass	✅ pass	✅ pass
KMSCube	🚫	⚠️ skip	⚠️ skip	⚠️ skip	✅ pass	⚠️ skip	✅ pass
OpenCV	🚫	✅ pass	✅ pass	✅ pass	✅ pass	✅ pass	✅ pass
WiFi_Firmware_Driver	🚫	✅ pass	✅ pass	✅ pass	✅ pass	✅ pass	✅ pass
WiFi_OnOff	🚫	✅ pass	✅ pass	✅ pass	✅ pass	⚠️ skip	✅ pass
adsp_remoteproc	🚫	✅ pass	✅ pass	✅ pass	✅ pass	✅ pass	✅ pass
boot	✅ pass	✅ pass	✅ pass	✅ pass	✅ pass	✅ pass	✅ pass
cdsp_remoteproc	🚫	✅ pass	✅ pass	✅ pass	✅ pass	✅ pass	⚠️ skip
core_auth	🚫	✅ pass	✅ pass	✅ pass	✅ pass	✅ pass	✅ pass
fastrpc_test	🚫	✅ pass	✅ pass	✅ pass	✅ pass	✅ pass	✅ pass
hotplug	🚫	✅ pass	✅ pass	✅ pass	✅ pass	✅ pass	✅ pass
irq	🚫	✅ pass	✅ pass	✅ pass	✅ pass	✅ pass	✅ pass
weston-simple-egl	🚫	⚠️ skip	⚠️ skip	⚠️ skip	⚠️ skip	⚠️ skip	⚠️ skip

All jobs summary

Job ID	Device	State	Health
171962	qcs6490	Finished	Complete
171846	qrb2210-rb1	Finished	Complete
171854	qcs6490	Finished	Complete
171830	qcs615-adp-air	Finished	Complete
171833	qrb2210-rb1	Finished	Incomplete
171851	qcs9100-rb8	Finished	Complete
171329	qcs615-adp-air	Finished	Complete
171336	qcs9100-rb8	Finished	Complete
171824	qcs9100	Finished	Incomplete
171845	qcs9100-rb8	Finished	Complete
171849	qcs9100	Finished	Incomplete
171342	qcs615-adp-air	Finished	Complete
171353	qcs6490	Finished	Complete
171332	qcs615-adp-air	Finished	Complete
171333	qcs9100-rb8	Finished	Complete
171829	qcs9100-rb8	Finished	Complete
171848	qcs9100	Finished	Complete
171855	qcs8300	Finished	Complete
171820	dragonboard-820c	Finished	Complete
171856	qrb2210-rb1	Finished	Complete
171840	qcs8300	Finished	Incomplete
171844	qcs9100-rb8	Finished	Complete
171967	qcs6490	Finished	Complete
171835	qcs9100	Finished	Complete
171963	qcs9100-rb8	Finished	Complete
171823	qcs8300	Finished	Incomplete
171827	qrb2210-rb1	Finished	Complete
171334	qcs9100	Finished	Complete
171341	qcs8300	Finished	Complete
171839	qcs6490	Finished	Complete
171825	qcs8300	Finished	Incomplete
171347	qcs8300	Finished	Complete
171841	qcs6490	Finished	Complete
171822	qcs9100	Finished	Complete
171960	qcs9100	Finished	Complete
171831	qcs9100-rb8	Finished	Incomplete
171331	dragonboard-820c	Finished	Complete
171834	qcs9100-rb8	Finished	Complete
171850	qcs615-adp-air	Finished	Complete
171966	qcs6490	Finished	Complete
171853	qcs8300	Finished	Complete
171958	qrb2210-rb1	Finished	Incomplete
171344	qcs6490	Finished	Complete
171971	qcs615-adp-air	Submitted	Unknown
171973	qcs8300	Finished	Complete
171339	qcs9100-rb8	Finished	Complete
171337	qrb2210-rb1	Finished	Complete
171852	qcs615-adp-air	Finished	Incomplete
171965	qcs8300	Finished	Complete
171838	qrb2210-rb1	Finished	Complete
171338	dragonboard-820c	Finished	Complete
171957	qrb2210-rb1	Finished	Incomplete
171327	dragonboard-820c	Finished	Incomplete
171972	qcs9100-rb8	Finished	Complete
171326	qcs9100	Finished	Complete
171343	qrb2210-rb1	Finished	Complete
171350	dragonboard-820c	Finished	Complete
171340	qcs8300	Finished	Complete
171843	qrb2210-rb1	Finished	Complete
171968	qcs615-adp-air	Running	Unknown
171349	qcs6490	Finished	Complete
171346	qcs6490	Finished	Incomplete
171837	qcs615-adp-air	Finished	Complete
171836	qcs6490	Finished	Incomplete
171959	qcs8300	Finished	Complete
171345	qrb2210-rb1	Finished	Complete
171955	qcs9100	Finished	Incomplete
171970	qcs9100	Finished	Incomplete
171330	qcs9100-rb8	Finished	Complete
171826	qcs8300	Finished	Complete
171828	qcs9100	Finished	Complete
171969	qcs8300	Finished	Complete
171961	qcs6490	Finished	Complete
171832	qcs6490	Finished	Complete
171328	qrb2210-rb1	Finished	Complete
171351	qcs615-adp-air	Finished	Complete
171842	qcs615-adp-air	Finished	Complete
171819	qcs6490	Finished	Complete
171956	qcs9100	Finished	Complete
171847	qcs615-adp-air	Finished	Incomplete
171857	qcs6490	Finished	Incomplete
171352	qcs9100	Finished	Complete
171888	qcs615-adp-air	Finished	Incomplete
171335	qcs9100	Finished	Complete
171964	qrb2210-rb1	Finished	Complete
171348	qcs8300	Finished	Complete

ricardosalveti · 2026-04-08T03:11:40Z

+-----------------------------------------------------
Result of testsuite pkcs11:
pkcs11_1000 OK
pkcs11_1001 OK
pkcs11_1002 OK
pkcs11_1003 OK
pkcs11_1004 OK
pkcs11_1005 OK
pkcs11_1006 OK
pkcs11_1007 OK
pkcs11_1008 OK
pkcs11_1009 OK
pkcs11_1010 OK
pkcs11_1011 OK
pkcs11_1012 OK
pkcs11_1013 OK
pkcs11_1014 OK
pkcs11_1015 OK
pkcs11_1017 OK
pkcs11_1020 OK
pkcs11_1022 OK
pkcs11_1023 OK
pkcs11_1024 OK
+-----------------------------------------------------
3594 subtests of which 0 failed
21 test cases of which 0 failed
0 test cases were skipped
TEE test application done!

Which image flavor / combination did you use here?

At least it didn't work for me with https://qli-prod-artifacts.qualcomm.com/qcom-prd-gh-artifacts/qualcomm-linux/meta-qcom/23947872135-2/qcom-distro/rb3gen2-core-kit/qcom-multimedia-image-rb3gen2-core-kit.rootfs.qcomflash.tar.gz, which is produced from this run.

root@rb3gen2-core-kit:~# xtest_qtee
Run test suite with level=0

TEE test application started over default TEE instance
######################################################
#
# pkcs11
#
######################################################

* pkcs11_1000 Initialize and close Cryptoki library
IGPAppClient_openSession failed: 15
mink_open_session() failed: 15
ERR [1045] LT:ckteec_invoke_init:304: TEEC open session failed ffff0000 from 2

/usr/src/debug/minkipc/1.2.3/optee-test/optee_test/host/xtest/pkcs11_1000.c:193: rv has an unexpected value: 0x30 = CKR_DEVICE_ERROR, expected 0x0 = CKR_OK
  pkcs11_1000 FAILED

* pkcs11_1001 PKCS11: List PKCS#11 slots and get information from
IGPAppClient_openSession failed: 15
mink_open_session() failed: 15
ERR [1045] LT:ckteec_invoke_init:304: TEEC open session failed ffff0000 from 2

/usr/src/debug/minkipc/1.2.3/optee-test/optee_test/host/xtest/pkcs11_1000.c:233: rv has an unexpected value: 0x30 = CKR_DEVICE_ERROR, expected 0x0 = CKR_OK
  pkcs11_1001 FAILED

* pkcs11_1002 PKCS11: Open and close PKCS#11 sessions
IGPAppClient_openSession failed: 15
mink_open_session() failed: 15
ERR [1045] LT:ckteec_invoke_init:304: TEEC open session failed ffff0000 from 2

/usr/src/debug/minkipc/1.2.3/optee-test/optee_test/host/xtest/pkcs11_1000.c:461: rv has an unexpected value: 0x30 = CKR_DEVICE_ERROR, expected 0x0 = CKR_OK
  pkcs11_1002 FAILED

* pkcs11_1003 PKCS11: Login to PKCS#11 token with PIN based authentication
IGPAppClient_openSession failed: 15
mink_open_session() failed: 15
ERR [1045] LT:ckteec_invoke_init:304: TEEC open session failed ffff0000 from 2

/usr/src/debug/minkipc/1.2.3/optee-test/optee_test/host/xtest/pkcs11_1000.c:1100: rv has an unexpected value: 0x30 = CKR_DEVICE_ERROR, expected 0x0 = CKR_OK
  pkcs11_1003 FAILED

* pkcs11_1004 PKCS11: create/destroy PKCS#11 simple objects
o pkcs11_1004.1 Create and destroy a volatile object
IGPAppClient_openSession failed: 15
mink_open_session() failed: 15
ERR [1045] LT:ckteec_invoke_init:304: TEEC open session failed ffff0000 from 2

/usr/src/debug/minkipc/1.2.3/optee-test/optee_test/host/xtest/pkcs11_1000.c:1175: rv has an unexpected value: 0x30 = CKR_DEVICE_ERROR, expected 0x0 = CKR_OK
  pkcs11_1004.1 FAILED
o pkcs11_1004.2 Create and destroy a persistent object
IGPAppClient_openSession failed: 15
mink_open_session() failed: 15
ERR [1045] LT:ckteec_invoke_init:304: TEEC open session failed ffff0000 from 2

/usr/src/debug/minkipc/1.2.3/optee-test/optee_test/host/xtest/pkcs11_1000.c:1175: rv has an unexpected value: 0x30 = CKR_DEVICE_ERROR, expected 0x0 = CKR_OK
  pkcs11_1004.2 FAILED
o pkcs11_1004.3 Create and destroy many session objects
IGPAppClient_openSession failed: 15
mink_open_session() failed: 15
ERR [1045] LT:ckteec_invoke_init:304: TEEC open session failed ffff0000 from 2

/usr/src/debug/minkipc/1.2.3/optee-test/optee_test/host/xtest/pkcs11_1000.c:1218: rv has an unexpected value: 0x30 = CKR_DEVICE_ERROR, expected 0x0 = CKR_OK
  pkcs11_1004.3 FAILED
o pkcs11_1004.4 Create objects in a read-only session
IGPAppClient_openSession failed: 15
mink_open_session() failed: 15
ERR [1045] LT:ckteec_invoke_init:304: TEEC open session failed ffff0000 from 2

/usr/src/debug/minkipc/1.2.3/optee-test/optee_test/host/xtest/pkcs11_1000.c:1268: rv has an unexpected value: 0x30 = CKR_DEVICE_ERROR, expected 0x0 = CKR_OK
  pkcs11_1004.4 FAILED
o pkcs11_1004.5 Create objects in a read/write session
IGPAppClient_openSession failed: 15
mink_open_session() failed: 15
ERR [1045] LT:ckteec_invoke_init:304: TEEC open session failed ffff0000 from 2

/usr/src/debug/minkipc/1.2.3/optee-test/optee_test/host/xtest/pkcs11_1000.c:1268: rv has an unexpected value: 0x30 = CKR_DEVICE_ERROR, expected 0x0 = CKR_OK
  pkcs11_1004.5 FAILED
  pkcs11_1004 FAILED

* pkcs11_1005 PKCS11: Check ciphering with valid and invalid keys #1
IGPAppClient_openSession failed: 15
mink_open_session() failed: 15
ERR [1045] LT:ckteec_invoke_init:304: TEEC open session failed ffff0000 from 2

/usr/src/debug/minkipc/1.2.3/optee-test/optee_test/host/xtest/pkcs11_1000.c:1513: rv has an unexpected value: 0x30 = CKR_DEVICE_ERROR, expected 0x0 = CKR_OK
  pkcs11_1005 FAILED

* pkcs11_1006 PKCS11: Check ciphering with valid and invalid keys #2
IGPAppClient_openSession failed: 15
mink_open_session() failed: 15
ERR [1045] LT:ckteec_invoke_init:304: TEEC open session failed ffff0000 from 2

/usr/src/debug/minkipc/1.2.3/optee-test/optee_test/host/xtest/pkcs11_1000.c:1575: rv has an unexpected value: 0x30 = CKR_DEVICE_ERROR, expected 0x0 = CKR_OK
  pkcs11_1006 FAILED

* pkcs11_1007 PKCS11: Check operations release at session closure
IGPAppClient_openSession failed: 15
mink_open_session() failed: 15
ERR [1045] LT:ckteec_invoke_init:304: TEEC open session failed ffff0000 from 2

/usr/src/debug/minkipc/1.2.3/optee-test/optee_test/host/xtest/pkcs11_1000.c:1684: rv has an unexpected value: 0x30 = CKR_DEVICE_ERROR, expected 0x0 = CKR_OK
  pkcs11_1007 FAILED

* pkcs11_1008 PKCS11: Check Compliance of C_Sign - HMAC algorithms
IGPAppClient_openSession failed: 15
mink_open_session() failed: 15
ERR [1045] LT:ckteec_invoke_init:304: TEEC open session failed ffff0000 from 2

/usr/src/debug/minkipc/1.2.3/optee-test/optee_test/host/xtest/pkcs11_1000.c:1939: rv has an unexpected value: 0x30 = CKR_DEVICE_ERROR, expected 0x0 = CKR_OK
  pkcs11_1008 FAILED

* pkcs11_1009 PKCS11: Check Compliance of C_Verify - HMAC Algorithms
IGPAppClient_openSession failed: 15
mink_open_session() failed: 15
pkcs11_1004.1 FAILED first error at /usr/src/debug/minkipc/1.2.3/optee-test/optee_test/host/xtest/pkcs11_1000.c:1175
pkcs11_1004.2 FAILED first error at /usr/src/debug/minkipc/1.2.3/optee-test/optee_test/host/xtest/pkcs11_1000.c:1175
pkcs11_1004.3 FAILED first error at /usr/src/debug/minkipc/1.2.3/optee-test/optee_test/host/xtest/pkcs11_1000.c:1218
pkcs11_1004.4 FAILED first error at /usr/src/debug/minkipc/1.2.3/optee-test/optee_test/host/xtest/pkcs11_1000.c:1268
pkcs11_1004.5 FAILED first error at /usr/src/debug/minkipc/1.2.3/optee-test/optee_test/host/xtest/pkcs11_1000.c:1268
pkcs11_1004 FAILED
pkcs11_1005 FAILED first error at /usr/src/debug/minkipc/1.2.3/optee-test/optee_test/host/xtest/pkcs11_1000.c:1513
pkcs11_1006 FAILED first error at /usr/src/debug/minkipc/1.2.3/optee-test/optee_test/host/xtest/pkcs11_1000.c:1575
pkcs11_1007 FAILED first error at /usr/src/debug/minkipc/1.2.3/optee-test/optee_test/host/xtest/pkcs11_1000.c:1684
pkcs11_1008 FAILED first error at /usr/src/debug/minkipc/1.2.3/optee-test/optee_test/host/xtest/pkcs11_1000.c:1939
pkcs11_1009 FAILED first error at /usr/src/debug/minkipc/1.2.3/optee-test/optee_test/host/xtest/pkcs11_1000.c:2114
pkcs11_1010 FAILED first error at /usr/src/debug/minkipc/1.2.3/optee-test/optee_test/host/xtest/pkcs11_1000.c:2378
pkcs11_1011 FAILED first error at /usr/src/debug/minkipc/1.2.3/optee-test/optee_test/host/xtest/pkcs11_1000.c:2650
pkcs11_1012 FAILED first error at /usr/src/debug/minkipc/1.2.3/optee-test/optee_test/host/xtest/pkcs11_1000.c:3067
pkcs11_1013 FAILED first error at /usr/src/debug/minkipc/1.2.3/optee-test/optee_test/host/xtest/pkcs11_1000.c:3305
pkcs11_1014 FAILED first error at /usr/src/debug/minkipc/1.2.3/optee-test/optee_test/host/xtest/pkcs11_1000.c:3623
pkcs11_1015 FAILED first error at /usr/src/debug/minkipc/1.2.3/optee-test/optee_test/host/xtest/pkcs11_1000.c:3819
pkcs11_1017 FAILED first error at /usr/src/debug/minkipc/1.2.3/optee-test/optee_test/host/xtest/pkcs11_1000.c:4322
pkcs11_1020 FAILED first error at /usr/src/debug/minkipc/1.2.3/optee-test/optee_test/host/xtest/pkcs11_1000.c:5985
pkcs11_1022 FAILED first error at /usr/src/debug/minkipc/1.2.3/optee-test/optee_test/host/xtest/pkcs11_1000.c:7170
pkcs11_1023 FAILED first error at /usr/src/debug/minkipc/1.2.3/optee-test/optee_test/host/xtest/pkcs11_1000.c:7555
pkcs11_1024 FAILED first error at /usr/src/debug/minkipc/1.2.3/optee-test/optee_test/host/xtest/pkcs11_1000.c:7729
+-----------------------------------------------------
31 subtests of which 25 failed
21 test cases of which 21 failed
0 test cases were skipped
TEE test application done!

ricardosalveti · 2026-04-08T03:13:41Z

Here is the output of running xtest_qtee now, which can be enabled with CI once I release the PKCS#11 TA in next minkipc release immediately after this

Ah, it is not supported with this release, why can't you just release and bump this pull-request to the revision that includes the TA?

We can't merge a PR that adds support to something that is not functional.

harshaldev27 · 2026-04-08T07:58:58Z

Here is the output of running xtest_qtee now, which can be enabled with CI once I release the PKCS#11 TA in next minkipc release immediately after this

Ah, it is not supported with this release, why can't you just release and bump this pull-request to the revision that includes the TA?

We can't merge a PR that adds support to something that is not functional.

Done. I have bumped up the release to v1.2.4 which installs the PKCS#11 TA for qcm6490, qcs9100, qcs8300 and qcs615 in /lib/qtee-tas as per conclusions on this issue: #1454

I have dropped the other two commits in this PR and moved them to a separate PR since they are un-related to this PR and only for mounting persist partition PR #1895. You should now be able to run the pkcs-11 test suite via xtest_qtee given that you take PR1895 in your workspace first. I hope we can merge this quickly since we already have approval on these changes from this current PR.

Please be aware that your device should be RPMB provisioned with test keys before it can run these test suites. The RPMB provisioning tool is planned for release publicly by the storage team soon. Meanwhile you can use the smcinvoke_client to provision the RPMB via following commands assuming you have access to our internal smplap64.mbn TA. Let me know if you need it. But my hunch is, most internal QC devices are already RPMB provisioned, so you shouldn't face any issues.

#define CLIENT_CMD14_RUN_RPMB_PROV 14
#define CLIENT_CMD15_RUN_RPMB_ERASE 15
#define CLIENT_CMD17_RUN_RPMB_RW 17

smcinvoke_client -i /<path to smplap>/ 15 1 # Erase RPMB
smcinvoke_client -i /<path to smplap>/ 14 1 # Provision RPMB with test keys
smcinvoke_client -i /<path to smplap>/ 17 1 # Test RPMB read/write

# Example
adb push smplap64.mbn /data
smcinvoke_client -i /data 15 1

I tried to ensure that only delta in minkipc recipe should be shown in the commit, but git keeps treating minkipc_1.2.4.bb as a brand new file despite my best efforts.

Thanks,
Harshal

lumag · 2026-04-08T14:58:17Z

Your message still uses adb push and references /data, so it doesn't look integrated. Do we need to start a new repo with TA apps? Or should they go to linux-firmware?

harshaldev27 · 2026-04-08T15:33:16Z

Your message still uses adb push and references /data, so it doesn't look integrated. Do we need to start a new repo with TA apps? Or should they go to linux-firmware?

I only referenced /data for smplap64.mbn because we don't yet have legal approval for releasing it's binary to minkipc and installing it in rootfs. For PKCS#11 tests you don't need to do anything. It's all integrated now.

harshaldev27 · 2026-04-08T15:38:17Z

Your message still uses adb push and references /data, so it doesn't look integrated. Do we need to start a new repo with TA apps? Or should they go to linux-firmware?

We don't need a new repo. As discussed in referenced issue #1454. TA binaries are coming from minkipc repo. They don't need to go to linux-firmware because these aren't firmware binaries driving a device.

ricardosalveti · 2026-04-08T16:24:03Z

Please be aware that your device should be RPMB provisioned with test keys before it can run these test suites. The RPMB provisioning tool is planned for release publicly by the storage team soon. Meanwhile you can use the smcinvoke_client to provision the RPMB via following commands assuming you have access to our internal smplap64.mbn TA. Let me know if you need it. But my hunch is, most internal QC devices are already RPMB provisioned, so you shouldn't face any issues.

What is the reason for requiring RPMB for this TA?

We should not require a test key to be burned there, what happens if I decide to close my device to enable secure-boot (and RPMB provisioning)? Would it work with a test-key as well? I would assume that closing / fusing the device implies using a proper RPMB key.

For follow ups, please specify everything that is required as part of the pull-request description, it is not ideal to keep finding additional steps and setups in order to validate the PR.

@igoropaniuk maybe you can give us a hand here, since you have a closed device in hands.

harshaldev27 · 2026-04-08T16:46:52Z

Please be aware that your device should be RPMB provisioned with test keys before it can run these test suites. The RPMB provisioning tool is planned for release publicly by the storage team soon. Meanwhile you can use the smcinvoke_client to provision the RPMB via following commands assuming you have access to our internal smplap64.mbn TA. Let me know if you need it. But my hunch is, most internal QC devices are already RPMB provisioned, so you shouldn't face any issues.

What is the reason for requiring RPMB for this TA?

The reason is that PKCS#11 TA uses the TEE core specification API implemented by QTEE to store Persistent Objects in the persist partition. These Persistent Objects are stored/created/manipulated by the Secure File System listener running on the Linux side in qtee_supplicant. The QTEE side implementation of it's state machine stores replay protection counters in the RPMB to safe guard against replay protection of these Persistent Objects.

We should not require a test key to be burned there, what happens if I decide to close my device to enable secure-boot (and RPMB provisioning)? Would it work with a test-key as well? I would assume that closing / fusing the device implies using a proper RPMB key.

Yes it will work. In fact test keys are only for secure-boot disabled devices. For secure boot enabled devices there are well documented steps for OEMs to provision the RPMB with proper keys.

For follow ups, please specify everything that is required as part of the pull-request description, it is not ideal to keep finding additional steps and setups in order to validate the PR.

Ack, these steps are provided just in-case the device isn't RPMB provisioned. This is rarely the case unless you have a brand new device. Also for external/secure-boot devices, we have sufficient public documentation explaining how to provision the RPMB for security use cases, including PKCS#11.

@igoropaniuk maybe you can give us a hand here, since you have a closed device in hands.

There is a more complicated procedure for secure boot RPMB provisioning. Please check the documentation. Meanwhile we can validate on internal secure-boot disabled devices via test keys.

harshaldev27 · 2026-04-08T18:30:53Z

One minor point which came to my mind. The RPMB listener is currently not working on EMMC devices. The issue is raised and assigned to storage qualcomm/minkipc#47. So please run your validations on UFS devices for now.

ricardosalveti · 2026-04-08T19:04:42Z

What is the reason for requiring RPMB for this TA?

The reason is that PKCS#11 TA uses the TEE core specification API implemented by QTEE to store Persistent Objects in the persist partition. These Persistent Objects are stored/created/manipulated by the Secure File System listener running on the Linux side in qtee_supplicant. The QTEE side implementation of it's state machine stores replay protection counters in the RPMB to safe guard against replay protection of these Persistent Objects.

Are we ever planning to support this TA without RPMB? With OP-TEE I can use the PKCS#11 TA with both RPMB and normal storage.

This should be described as part of this PR and in our docs.

We should not require a test key to be burned there, what happens if I decide to close my device to enable secure-boot (and RPMB provisioning)? Would it work with a test-key as well? I would assume that closing / fusing the device implies using a proper RPMB key.

Yes it will work. In fact test keys are only for secure-boot disabled devices. For secure boot enabled devices there are well documented steps for OEMs to provision the RPMB with proper keys.

We also need to provide clear documentation for normal users and developers here, which seems to be https://docs.qualcomm.com/doc/80-80021-11/topic/customize.html?product=895724676033554725&facet=Security&version=2.0-rc2#section-customize-rpmb-provisioning-label and https://docs.qualcomm.com/doc/80-80021-11/topic/enable-uefi-secure-boot.html?product=895724676033554725&facet=Security&version=2.0-rc2.

But back to my question, if I burn a test key they I will probably not be able to use RPMB once I close / fuse my device, right? If so, we should not even suggest this scenario, as it will make RPMB useless and break the secure boot use case.

Better to just say that we require secure boot and RPMB to be fused and valid for this TA to work (explaining the reasons behind this).

For follow ups, please specify everything that is required as part of the pull-request description, it is not ideal to keep finding additional steps and setups in order to validate the PR.

Ack, these steps are provided just in-case the device isn't RPMB provisioned. This is rarely the case unless you have a brand new device.

None of my devices (and the ones we use in our lab) have RPMB provisioned :-)

There is a more complicated procedure for secure boot RPMB provisioning. Please check the documentation. Meanwhile we can validate on internal secure-boot disabled devices via test keys.

I won't validate this scenario if this implies burning a test key on RPMB.

harshaldev27 · 2026-04-08T19:23:31Z

What is the reason for requiring RPMB for this TA?

The reason is that PKCS#11 TA uses the TEE core specification API implemented by QTEE to store Persistent Objects in the persist partition. These Persistent Objects are stored/created/manipulated by the Secure File System listener running on the Linux side in qtee_supplicant. The QTEE side implementation of it's state machine stores replay protection counters in the RPMB to safe guard against replay protection of these Persistent Objects.

Are we ever planning to support this TA without RPMB? With OP-TEE I can use the PKCS#11 TA with both RPMB and normal storage.

Yes, on Compute chipsets where NVMe storage does not support RPMB, there is a devcfg.mbn flashed which sets a use_rpmb flag to 0. After this, Secure File System uses the persist partition itself to store replay counters in a vTable. This is somewhat less secure but fine for production use cases. You can do this on Kodiak/Lemans/Monaco as well.

This should be described as part of this PR and in our docs.

I'll work with CE to update the docs once the PR is merged and feature enabled.

We should not require a test key to be burned there, what happens if I decide to close my device to enable secure-boot (and RPMB provisioning)? Would it work with a test-key as well? I would assume that closing / fusing the device implies using a proper RPMB key.

Yes it will work. In fact test keys are only for secure-boot disabled devices. For secure boot enabled devices there are well documented steps for OEMs to provision the RPMB with proper keys.

We also need to provide clear documentation for normal users and developers here, which seems to be https://docs.qualcomm.com/doc/80-80021-11/topic/customize.html?product=895724676033554725&facet=Security&version=2.0-rc2#section-customize-rpmb-provisioning-label and https://docs.qualcomm.com/doc/80-80021-11/topic/enable-uefi-secure-boot.html?product=895724676033554725&facet=Security&version=2.0-rc2.

Let me review these with CE and update.

But back to my question, if I burn a test key they I will probably not be able to use RPMB once I close / fuse my device, right? If so, we should not even suggest this scenario, as it will make RPMB useless and break the secure boot use case.

Hmm. To be honest, I did not yet come across such a scenario where I enabled secure-boot on a device with RPMB provisioned with test keys and it resulted in issues later. I will have to confirm this with storage team. I also never heard anyone telling is to excercise caution in this regard. I'll try to confirm this.

Better to just say that we require secure boot and RPMB to be fused and valid for this TA to work (explaining the reasons behind this).

We can say this in the documentation if I am able to confirm this concern with storage around possible RPMB breakage upon enabling secure-boot on the device. Otherwise, like I said above, TA works without RPMB as well and without secure boot as well.

For follow ups, please specify everything that is required as part of the pull-request description, it is not ideal to keep finding additional steps and setups in order to validate the PR.

Ack, these steps are provided just in-case the device isn't RPMB provisioned. This is rarely the case unless you have a brand new device.

None of my devices (and the ones we use in our lab) have RPMB provisioned :-)

Yikes, looks like we're operating in different worlds then!

There is a more complicated procedure for secure boot RPMB provisioning. Please check the documentation. Meanwhile we can validate on internal secure-boot disabled devices via test keys.

I won't validate this scenario if this implies burning a test key on RPMB.

Hmm okay, if you're concerned about your device maybe someone else can volunteer from QIPL who has a secure-boot disabled device and is fine with using test keys? @vivpuar maybe? :)

ricardosalveti · 2026-04-08T19:28:12Z

Are we ever planning to support this TA without RPMB? With OP-TEE I can use the PKCS#11 TA with both RPMB and normal storage.

Yes, on Compute chipsets where NVMe storage does not support RPMB, there is a devcfg.mbn flashed which sets a use_rpmb flag to 0. After this, Secure File System uses the persist partition itself to store replay counters in a vTable. This is somewhat less secure but fine for production use cases.

Can I use this settings on other targets such as rb3gen2?

But back to my question, if I burn a test key they I will probably not be able to use RPMB once I close / fuse my device, right? If so, we should not even suggest this scenario, as it will make RPMB useless and break the secure boot use case.

Hmm. To be honest, I did not yet come across such a scenario where I enabled secure-boot on a device with RPMB provisioned with test keys and it resulted in issues later. I will have to confirm this with storage team. I also never heard anyone telling is to excercise caution in this regard. I'll try to confirm this.

Thanks, my assumption is that once the test-key is burned there, there is no way back and securing the device won't make it really secure at that point, since the rpmb key is known.

There is a more complicated procedure for secure boot RPMB provisioning. Please check the documentation. Meanwhile we can validate on internal secure-boot disabled devices via test keys.

I won't validate this scenario if this implies burning a test key on RPMB.

Hmm okay, if you're concerned about your device maybe someone else can volunteer from QIPL who has a secure-boot disabled device and is fine with using test keys? @vivpuar maybe? :)

Yup, please, someone that has access to a closed device (@igoropaniuk ^^) or someone with a test-key burned, then we can add a tested-by git tag in your commit.

harshaldev27 · 2026-04-08T19:32:25Z

Are we ever planning to support this TA without RPMB? With OP-TEE I can use the PKCS#11 TA with both RPMB and normal storage.

Yes, on Compute chipsets where NVMe storage does not support RPMB, there is a devcfg.mbn flashed which sets a use_rpmb flag to 0. After this, Secure File System uses the persist partition itself to store replay counters in a vTable. This is somewhat less secure but fine for production use cases.

Can I use this settings on other targets such as rb3gen2?

Yes yes. I just updated my comment above to add it's doable for all devices. I have a devcfg.mbn with this flag set to 0 for rb3gen2 if you'd like to use it.

But back to my question, if I burn a test key they I will probably not be able to use RPMB once I close / fuse my device, right? If so, we should not even suggest this scenario, as it will make RPMB useless and break the secure boot use case.

Hmm. To be honest, I did not yet come across such a scenario where I enabled secure-boot on a device with RPMB provisioned with test keys and it resulted in issues later. I will have to confirm this with storage team. I also never heard anyone telling is to excercise caution in this regard. I'll try to confirm this.

Thanks, my assumption is that once the test-key is burned there, there is no way back and securing the device won't make it really secure at that point, since the rpmb key is known.

I believe a reprovision of the RPMB is required upon enabling secure-boot to ensure security and overwriting of the test keys. I'll double confirm this regardless.

There is a more complicated procedure for secure boot RPMB provisioning. Please check the documentation. Meanwhile we can validate on internal secure-boot disabled devices via test keys.

I won't validate this scenario if this implies burning a test key on RPMB.

Hmm okay, if you're concerned about your device maybe someone else can volunteer from QIPL who has a secure-boot disabled device and is fine with using test keys? @vivpuar maybe? :)

Yup, please, someone that has access to a closed device (@igoropaniuk ^^) or someone with a test-key burned, then we can add a tested-by git tag in your commit.

Sounds great!

ricardosalveti · 2026-04-08T19:34:21Z

Yes yes. I just updated my comment above to add it's doable for all devices. I have a devcfg.mbn with this flag set to 0 for rb3gen2 if you'd like to use it.

Please, then I can at least test it myself without involving rpmb here.

lumag · 2026-04-09T00:07:56Z

Your message still uses adb push and references /data, so it doesn't look integrated. Do we need to start a new repo with TA apps? Or should they go to linux-firmware?

We don't need a new repo. As discussed in referenced issue #1454. TA binaries are coming from minkipc repo. They don't need to go to linux-firmware because these aren't firmware binaries driving a device.

Will you accept binaries coming from Lenovo / Dell / other OEMs (see linux-firmware and hexagon-dsp-binaries).

harshaldev27 · 2026-04-09T05:38:33Z

Your message still uses adb push and references /data, so it doesn't look integrated. Do we need to start a new repo with TA apps? Or should they go to linux-firmware?

We don't need a new repo. As discussed in referenced issue #1454. TA binaries are coming from minkipc repo. They don't need to go to linux-firmware because these aren't firmware binaries driving a device.

Will you accept binaries coming from Lenovo / Dell / other OEMs (see linux-firmware and hexagon-dsp-binaries).

I don't see any reason why we cannot. As discussed in issue #1454 , we can create soc/vendor specific directories inside the ta folder to place OEM signed TA binaries there. However, I don't really understand why an OEM would want to place their binaries there. If they received a TA binary from us (or built one themselves) it is going to be signed with their own unique key, and so even if it is made public, I don't think it's going to benefit anyone. The OEM can just push/install the binary into the rootfs themselves and ship their product.

lumag · 2026-04-09T07:00:46Z

@harshaldev27 neither Lenovo nor Dell distribute a Linux rootfs with their laptops. Instead it is expected that a generic Linux distro (like Debian or Fedora) can work on their devices.

Updated minkipc tag to v1.2.4 which brings support for PKCS#11 on Qualcomm platforms with QTEE support. The support is provided through optee_client and optee_test repos v4.0.0 which are placed in the optee-client/ and optee-test/ sub directories. Only the PKCS#11 relevant library and test suites are built and supported, i.e. libckteec_qtee and xtest_qtee (pkcs11-tests). The recipe license is updated to reflect the licenses of these repos. The PKCS#11 test-signed Trusted Application binaries is also installed for supported targets (qcm6490, qcs9100, qcs8300 and qcs615) under /lib/qtee-tas. On an RPMB provisioned device, the pkcs11-tests can be run by invoking the xtest_qtee binary. Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>

vivpuar · 2026-04-09T10:58:29Z

Y:\TZ.XF.5.29.1-00146-KODIAKAAAAANAAZT-1\trustzone_images\build\ms\bin\EACAANAA>adb push smplap64.mbn /data
smplap64.mbn: 1 file pushed. 4.3 MB/s (2008936 bytes in 0.442s)

Y:\TZ.XF.5.29.1-00146-KODIAKAAAAANAAZT-1\trustzone_images\build\ms\bin\EACAANAA>adb shell
root@rb3gen2-core-kit:/# smcinvoke_client -i /data/smplap64.mbn 15 1
Run internal test...
Load /data/smplap64.mbn, size 2008936, buf 0xffffad6e5010.
[run_internal_app:669] TEST SUCCEEDED for 1 iterations
root@rb3gen2-core-kit:/# smcinvoke_client -i /data/smplap64.mbn 14 1
Run internal test...
Load /data/smplap64.mbn, size 2008936, buf 0xffff99ff5010.
[run_internal_app:669] TEST SUCCEEDED for 1 iterations
root@rb3gen2-core-kit:/# smcinvoke_client -i /data/smplap64.mbn 17 1
Run internal test...
Load /data/smplap64.mbn, size 2008936, buf 0xffff8d225010.
[run_internal_app:669] TEST SUCCEEDED for 1 iterations
root@rb3gen2-core-kit:/# xtest_qtee
Run test suite with level=0

TEE test application started over default TEE instance
######################################################
#
# pkcs11
#
######################################################

* pkcs11_1000 Initialize and close Cryptoki library
  pkcs11_1000 OK
[...]
[...]
+-----------------------------------------------------
Result of testsuite pkcs11:
pkcs11_1000 OK
pkcs11_1001 OK
pkcs11_1002 OK
pkcs11_1003 OK
pkcs11_1004 OK
pkcs11_1005 OK
pkcs11_1006 OK
pkcs11_1007 OK
pkcs11_1008 OK
pkcs11_1009 OK
pkcs11_1010 OK
pkcs11_1011 OK
pkcs11_1012 OK
pkcs11_1013 OK
pkcs11_1014 OK
pkcs11_1015 OK
pkcs11_1017 OK
pkcs11_1020 OK
pkcs11_1022 OK
pkcs11_1023 OK
pkcs11_1024 OK
+-----------------------------------------------------
3608 subtests of which 0 failed
21 test cases of which 0 failed
0 test cases were skipped
TEE test application done!

Tested-by: Vivek Puar vpuar@qti.qualcomm.com
Tested on an internal rb3gen2 RPMB test provisioned device.

ricardosalveti

Result of testsuite pkcs11:
pkcs11_1000 OK
pkcs11_1001 OK
pkcs11_1002 OK
pkcs11_1003 OK
pkcs11_1004 OK
pkcs11_1005 OK
pkcs11_1006 OK
pkcs11_1007 OK
pkcs11_1008 OK
pkcs11_1009 OK
pkcs11_1010 OK
pkcs11_1011 OK
pkcs11_1012 OK
pkcs11_1013 OK
pkcs11_1014 OK
pkcs11_1015 OK
pkcs11_1017 OK
pkcs11_1020 OK
pkcs11_1022 OK
pkcs11_1023 OK
pkcs11_1024 OK
+-----------------------------------------------------
3594 subtests of which 0 failed
21 test cases of which 0 failed
0 test cases were skipped
TEE test application done!

Finally and thanks for all the work on this PR.

ricardosalveti · 2026-04-10T02:39:04Z

Merging based on previous approvals.

harshaldev27 requested review from anujm1, koenkooi, lumag, ndechesne, ricardosalveti, sbanerjee-quic and vkraleti as code owners March 7, 2026 13:51

arakshit011 mentioned this pull request Mar 11, 2026

Migrate to http urls for gitsubmodules and re-name the libckteec library qualcomm/minkipc#42

Merged

harshaldev27 force-pushed the master branch 2 times, most recently from 42881ec to 1292209 Compare April 8, 2026 07:41

harshaldev27 changed the title ~~minkipc: Update tag to v1.2.3 to add support for PKCS#11~~ minkipc: Update tag to v1.2.4 to add support for PKCS#11 Apr 8, 2026

knaveen-qc added this to the qli-2.0-rc3 pull-request freeze milestone Apr 9, 2026

harshaldev27 force-pushed the master branch from 1292209 to 88b6899 Compare April 9, 2026 09:59

ricardosalveti approved these changes Apr 10, 2026

View reviewed changes

ricardosalveti merged commit 0b19e96 into qualcomm-linux:master Apr 10, 2026
1 check passed

Conversation

harshaldev27 commented Mar 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ricardosalveti commented Mar 7, 2026

Uh oh!

anujm1 commented Mar 9, 2026

Uh oh!

harshaldev27 commented Mar 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

harshaldev27 commented Mar 9, 2026

Uh oh!

anujm1 commented Mar 9, 2026

Uh oh!

harshaldev27 commented Mar 9, 2026

Uh oh!

anujm1 commented Mar 9, 2026

Uh oh!

ricardosalveti commented Mar 9, 2026

Uh oh!

ricardosalveti commented Mar 9, 2026

Uh oh!

b49020 commented Mar 10, 2026

Uh oh!

harshaldev27 commented Mar 10, 2026

Uh oh!

harshaldev27 commented Mar 10, 2026

Uh oh!

harshaldev27 commented Mar 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

lumag commented Mar 10, 2026

Uh oh!

ricardosalveti commented Mar 10, 2026

Uh oh!

harshaldev27 commented Mar 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

harshaldev27 commented Mar 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

lumag commented Mar 11, 2026

Uh oh!

harshaldev27 commented Mar 11, 2026

Uh oh!

ricardosalveti commented Mar 11, 2026

Uh oh!

harshaldev27 commented Mar 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ricardosalveti commented Mar 11, 2026

Uh oh!

harshaldev27 commented Apr 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions Bot commented Apr 7, 2026

Test run workflow

Test jobs for commit bc33f30

All jobs summary

Uh oh!

github-actions Bot commented Apr 7, 2026

Test run workflow

Test jobs for commit bc33f30

All jobs summary

Uh oh!

ricardosalveti commented Apr 8, 2026

Uh oh!

ricardosalveti commented Apr 8, 2026

Uh oh!

harshaldev27 commented Apr 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

lumag commented Apr 8, 2026

Uh oh!

harshaldev27 commented Apr 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

harshaldev27 commented Apr 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

harshaldev27 commented Mar 7, 2026 •

edited

Loading

harshaldev27 commented Mar 9, 2026 •

edited

Loading

harshaldev27 commented Mar 10, 2026 •

edited

Loading

harshaldev27 commented Mar 11, 2026 •

edited

Loading

harshaldev27 commented Mar 11, 2026 •

edited

Loading

harshaldev27 commented Mar 11, 2026 •

edited

Loading

harshaldev27 commented Apr 7, 2026 •

edited

Loading

Test jobs for commit `bc33f30`

Test jobs for commit `bc33f30`

harshaldev27 commented Apr 8, 2026 •

edited

Loading

harshaldev27 commented Apr 8, 2026 •

edited

Loading

harshaldev27 commented Apr 8, 2026 •

edited

Loading

harshaldev27 commented Apr 8, 2026 •

edited

Loading

harshaldev27 commented Apr 8, 2026 •

edited

Loading