How to Build TA‑to‑TA Communication in Qualcomm’s QSEE Trusted Execution Environment

This guide explains the fundamentals of Trusted Execution Environments, introduces ARM TrustZone and Qualcomm's QSEE, and provides step‑by‑step instructions—including IDL creation, service implementation, and client integration—to establish secure TA‑to‑TA communication with practical code examples and troubleshooting tips.

OPPO Amber Lab
OPPO Amber Lab
OPPO Amber Lab
How to Build TA‑to‑TA Communication in Qualcomm’s QSEE Trusted Execution Environment

Trusted Execution Environment (TEE)

A Trusted Execution Environment provides a secure area for sensitive data and critical applications, protecting them from malicious attacks and unauthorized access. TEE combines hardware and software, widely used in mobile devices to safeguard personal identity, device data, and payment information.

ARM TrustZone

ARM TrustZone is a popular TEE solution that creates hardware‑isolated secure and non‑secure worlds within a single processor. Trusted Applications (TA) run in the secure world, while regular applications (Client Applications, CA) run in the non‑secure world.

Qualcomm QSEE

Qualcomm implements its own TEE, QSEE (Qualcomm Secure Execution Environment), based on ARM TrustZone. Developers create separate TAs for specific functions to avoid bloated monolithic TAs. This article walks through building a communication framework between different TAs in QSEE.

TA‑to‑TA Communication

Qualcomm’s TZService supports IPC between TAs using the mini‑kernel (MINK) mechanism. The example uses a service TA (Test_STA) and a client TA (Test_CTA) to demonstrate the communication setup.

Step One: Create IDL Files

Create two IDL files for the service side, named CTest_STAService.idl and ITest_STAService.idl. These files are compiled by the IDL compiler into corresponding .h and .hpp files, which must be included in the service TA’s build script.

The generated header defines a unique ID for Test_STA, which the TEE OS uses to locate the TA. This ID must be unique and is referenced as CXXXService_UID in actual projects.

Step Two: Implement Service Logic

After the IDL files are compiled, implement the service logic in CTest_STAService.c. Use the macro ITest_STAService_DEFINE_INVOKE to bind the command handler to a concrete function (e.g., CTest_STAService_cmd_handler). Include the generated headers and follow the MINK IPC framework.

Step Three: Build and Invoke from Client TA

Compile the service TA with the IDL‑generated headers, then copy the IDL files to the client TA’s include path. The client uses qsee_open with the service TA’s UID, calls ITest_STAService_cmd_handler to send commands, and finally releases the MINK object with ITest_STAService_release.

Q&A

Q1: qsee_open returns 0xa and cannot open the service TA. A1: The service TA must be loaded in memory; otherwise qsee_open cannot find it.

Q2: Mismatch between rsplen_out and the value assigned in CTest_STAService_cmd_handler. A2: rsplen limits the returned buffer length; if the assigned value exceeds rsplen, it is truncated to rsplen.

Q3: IDL files are not automatically compiled. A3: Ensure the service TA’s service.c includes the generated .h files; the IDL compiler will then process the .idl files.

Reference

[1] https://docs.qualcomm.com/bundle/KBA-201128082512/resource/KBA-201128082512.pdf [2] https://docs.qualcomm.com/bundle/80-NH537-2/resource/80-NH537-2.pdf#page=38

trusted execution environmentarm trustzonesecure enclaveqseeta-to-ta communication
OPPO Amber Lab
Written by

OPPO Amber Lab

Centered on user data security and privacy, we conduct research and open our tech capabilities to developers, building an information‑security fortress for partners and users and safeguarding OPPO device security.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.