FROMLIST: Add TEE based client driver for UEFI Secure Application#1487
FROMLIST: Add TEE based client driver for UEFI Secure Application#1487Harshal Dev (harshaldev27) wants to merge 6 commits into
Conversation
QCOMTEE needs to distinguish between object invocations arriving from kernel clients and user-space clients in order to correctly marshal UBUF parameters and decide whether certain operations should be permitted. Add a kernel_ctx flag to struct qcomtee_object_invoke_context to track the context of object invocation. Objects invoked from the kernel-space are expected to have the MSB of their 64-bit object-id set to indicate a kernel context, whereas objects invoked from user-space should not set it. To ensure this, we restrict the object-id space of user-space invoked objects to 32-bits. This is in-line with QTEE expectation of 32-bit object ids. Link: https://lore.kernel.org/all/20260707-qcom_uefisecapp_migrate_qcomtee-v1-1-f659cbd5d04c@oss.qualcomm.com/ Signed-off-by: Amirreza Zarrabi <amirreza.zarrabi@oss.qualcomm.com> Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
Kernel clients can open a TEE context and invoke regular TA commands through tee_client_invoke_func(). However, there is currently no equivalent helper for invoking TEE objects. Add tee_client_object_invoke_func() as a kernel client API for issuing object invocation requests. The helper checks that the backend provides object_invoke_func() before setting the MSB of the object-id and forwarding the request. The MSB of the object-id informs the TEE backend that the object is invoked from a kernel context. This allows TEE backends that support privileged object-based calls from the kernel-space. Link: https://lore.kernel.org/all/20260707-qcom_uefisecapp_migrate_qcomtee-v1-2-f659cbd5d04c@oss.qualcomm.com/ Signed-off-by: Amirreza Zarrabi <amirreza.zarrabi@oss.qualcomm.com> Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
QCOMTEE currently treats UBUF parameters as userspace addresses and applies userspace restrictions when invoking the root object. This is not suitable for object invocation requests issued by kernel clients. Use the kernel_ctx flag to distinguish kernel client requests from userspace requests. For kernel contexts, do not mark UBUF parameters as user addresses, and allow permitted root-object operations to proceed without applying the userspace-only checks. This allows in-kernel users of tee_client_object_invoke_func() to issue object invocation requests through the qcomtee backend. Link: https://lore.kernel.org/all/20260707-qcom_uefisecapp_migrate_qcomtee-v1-3-f659cbd5d04c@oss.qualcomm.com/ Signed-off-by: Amirreza Zarrabi <amirreza.zarrabi@oss.qualcomm.com> Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
Export the uuidv5() function defined in the TEE core to all TEE backends. This enables the TEE backend drivers to generate a UUID for identifying and registering their secure services on the TEE bus. Link: https://lore.kernel.org/all/20260707-qcom_uefisecapp_migrate_qcomtee-v1-4-f659cbd5d04c@oss.qualcomm.com/ Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
…TEE bus QTEE exposes certain secure services implemented either within the QTEE kernel or via pre-loaded Trusted Applications (TAs). Such always-available services can be readily accessed by TEE client drivers via QTEE's object-IPC protocol if the service is registered as a device on the TEE bus. One such service is the EFI-variables service, implemented by the uefisecapp TA which enables kernel clients to access EFI variables at runtime. Maintain a static list of such always-available secure services and add support for the QCOMTEE driver to register these services as devices on the TEE bus during probe. Link: https://lore.kernel.org/all/20260707-qcom_uefisecapp_migrate_qcomtee-v1-5-f659cbd5d04c@oss.qualcomm.com/ Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
…iver On Qualcomm SoC based platforms, UEFI stores EFI variables within the Replay Protected Memory Block (RPMB) which is only accessible by the Qualcomm Trusted Execution Environment (QTEE). For Qualcomm platforms without emulated RPMB support, specifically platforms where RPMB is not located within SPI-NOR storage and instead located on UFS/EMMC storage, non-volatile EFI variables can only be set via a callback request from the UEFI Trusted Application (TA) to the RPMB service running in user-space (within the QTEE supplicant). Unlike the QCOMTEE driver, the QSEECOM driver (used by the current uefisecapp client driver) does not support callback requests. And on certain Qualcomm platforms such as the RB3Gen2, attempts to access the QSEECOM interface fail due to lack of support within QTEE. On all such platforms, a TEE based uefisecapp client driver must be used to access cached/volatile EFI variables within the uefisecapp TA and ensure persistence of writes to non-volatile EFI variables through the RPMB service hosted in the QTEE supplicant. Add support for a TEE based uefisecapp client driver which installs efivar operations after obtaining an object reference to the uefisecapp service. This enables the kernel/user-space to access/modify both volatile EFI vars stored by the Secure Application (in-memory) and non-volatile ones stored within RPMB. Link: https://lore.kernel.org/all/20260707-qcom_uefisecapp_migrate_qcomtee-v1-6-f659cbd5d04c@oss.qualcomm.com/ Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
qcomlnxci
requested review from
a team,
kuld-sing,
Mukesh Ojha (mukeshojha-linux) and
Kaushal Kumar (quic-kaushalk)
and removed request for
a team
PR #1487 — validate-patchPR: #1487
Final Summary
|
PR #1487 — checker-log-analyzerPR: #1487
Detailed report: Full report
|
3 participants
On Qualcomm SoC based platforms, UEFI stores EFI variables within the
Replay Protected Memory Block (RPMB) which is only accessible by the
Qualcomm Trusted Execution Environment (QTEE).
For Qualcomm platforms without emulated RPMB support, specifically
platforms where RPMB is not located within SPI-NOR storage and instead
located on UFS/EMMC storage, non-volatile EFI variables can only be set via
a callback request from the UEFI Secure Application to the RPMB service
running in user-space (within the QTEE supplicant [1]).
Unlike the QCOM-TEE driver, the QSEECOM driver (used by the current
QSEECOM based uefisecapp) does not support callback requests. And on
certain Qualcomm platforms such as the RB3Gen2, attempts to access the
QSEECOM interface fail due to lack of support within Qualcomm TEE.
On these platforms, a TEE based uefisecapp client driver is required to:
the RPMB service hosted in the QTEE supplicant.
This series introduces such a uefisecapp TEE client driver for the
aforementioned Qualcomm platforms which installs efi-var operations if
the QCOMTEE driver registers support for an object-IPC based uefisecapp
service on the TEE bus during its probe. Only new QTEE firmware versions
available at [2] provide this support.
Thus, QCOMTEE now maintains a static list of always-available object-IPC
based secure services exposed by QTEE. These services are implemented either
within the QTEE kernel or within a pre-loaded Trusted Application (TA)
usually loaded by the bootloader. The uefisecapp TA is an example of a
preloaded TA loaded by UEFI. A static list is required since QTEE does not
yet expose any way to dynamically query and enumerate the services exposed by
it.
To facilitate object-IPC interactions from the kernel-space, this
series also introduces a tee_client_object_invoke_func() to allow
invocation of TEE objects similar to the existing tee_client_invoke_func()
API exported by the TEE subsystem which allows invocation of TEE functions.
Some suporting changes are also introduced to track and handle operations
for TEE contexts opened from the kernel-space in the back-end QCOM-TEE
driver along with associated changes in user-space libqcomtee via Pull
Request [3].
Finally and as previously mentioned, access to the object-IPC based uefisecapp
service is restricted on older QTEE firmware versions. A new QTEE firmware
release must be picked up from QArtifactory [2] for all upstream supported
Qualcomm SoCs to enable access to uefisecapp service via the TEE client
driver.
This patch series has been validated on Kodiak RB3Gen2 platform with UFS
storage by attempting to read/write EFI variables via the efivar tool [4]
after mounting the efivarfs filesystem. See [5] for an example.
Merge Strategy:
This patch series could either be taken from the OP-TEE tree or the
QCOM soc tree. I would prefer it to be picked by the OP-TEE tree since
all except the uefisecapp TEE client driver patch in this series make
changes relevant to the TEE subsystem. It would be great if the QCOM soc
tree maintainers can Ack the uefisecapp driver patch.
[1] https://github.com/qualcomm/minkipc
[2] https://shorturl.at/zQU07
[3] quic/quic-teec#27
[4] https://github.com/rhboot/efivar
[5] https://docs.qualcomm.com/doc/80-70020-27/topic/manage_uefi_environment_variables_using_efivar_tool.html
Link: https://lore.kernel.org/all/20260707-qcom_uefisecapp_migrate_qcomtee-v1-0-f659cbd5d04c@oss.qualcomm.com/
Signed-off-by: Harshal Dev harshal.dev@oss.qualcomm.com