Documentation/tee/qtee.rst
Source file repositories/reference/linux-study-clean/Documentation/tee/qtee.rst
File Facts
- System
- Linux kernel
- Corpus path
Documentation/tee/qtee.rst- Extension
.rst- Size
- 4827 bytes
- Lines
- 97
- Domain
- Support Tooling And Documentation
- Bucket
- Documentation
- Inferred role
- Support Tooling And Documentation: documentation
- Status
- atlas-only
Why This File Exists
Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
Dependency Surface
- No C-style include directives detected by the generator.
Detected Declarations
- No top-level syscall, struct, function, initcall, or export declaration detected by the generator.
Annotated Snippet
.. SPDX-License-Identifier: GPL-2.0
=============================================
QTEE (Qualcomm Trusted Execution Environment)
=============================================
The QTEE driver handles communication with Qualcomm TEE [1].
The lowest level of communication with QTEE builds on the ARM SMC Calling
Convention (SMCCC) [2], which is the foundation for QTEE's Secure Channel
Manager (SCM) [3] used internally by the driver.
In a QTEE-based system, services are represented as objects with a series of
operations that can be called to produce results, including other objects.
When an object is hosted within QTEE, executing its operations is referred
to as "direct invocation". QTEE can also invoke objects hosted in the non-secure
world using a method known as "callback request".
The SCM provides two functions to support direct invocation and callback requests:
- QCOM_SCM_SMCINVOKE_INVOKE: Used for direct invocation. It can return either
a result or initiate a callback request.
- QCOM_SCM_SMCINVOKE_CB_RSP: Used to submit a response to a callback request
triggered by a previous direct invocation.
The QTEE Transport Message [4] is stacked on top of the SCM driver functions.
A message consists of two buffers shared with QTEE: inbound and outbound
buffers. The inbound buffer is used for direct invocation, and the outbound
buffer is used to make callback requests. This picture shows the contents of
a QTEE transport message::
+---------------------+
| v
+-----------------+-------+-------+------+--------------------------+
| qcomtee_msg_ |object | buffer | |
| object_invoke | id | offset, size | | (inbound buffer)
+-----------------+-------+--------------+--------------------------+
<---- header -----><---- arguments ------><- in/out buffer payload ->
+-----------+
| v
+-----------------+-------+-------+------+----------------------+
| qcomtee_msg_ |object | buffer | |
| callback | id | offset, size | | (outbound buffer)
+-----------------+-------+--------------+----------------------+
Each buffer is started with a header and array of arguments.
QTEE Transport Message supports four types of arguments:
- Input Object (IO) is an object parameter to the current invocation
or callback request.
- Output Object (OO) is an object parameter from the current invocation
or callback request.
- Input Buffer (IB) is (offset, size) pair to the inbound or outbound region
to store parameter to the current invocation or callback request.
- Output Buffer (OB) is (offset, size) pair to the inbound or outbound region
to store parameter from the current invocation or callback request.
Picture of the relationship between the different components in the QTEE
architecture::
User space Kernel Secure world
~~~~~~~~~~ ~~~~~~ ~~~~~~~~~~~~
+--------+ +----------+ +--------------+
| Client | |callback | | Trusted |
+--------+ |server | | Application |
/\ +----------+ +--------------+
Annotation
- Atlas domain: Support Tooling And Documentation / Documentation.
- Implementation status: atlas-only.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.