This introduces a Trusted Execution Environment (TEE) driver for
Qualcomm TEE (QTEE).
QTEE enables Trusted Applications (TAs) and services to run securely. It
uses an object-based interface, where each service is an object with
sets of operations.
Kernel and userspace services are also available to QTEE through a
similar approach. QTEE makes callback requests that are converted into
object invocations. These objects can represent services within the
kernel or userspace process.
We extend the TEE subsystem to understand object parameters and an ioctl
call so client can invoke objects in QTEE:
- TEE_IOCTL_PARAM_ATTR_TYPE_OBJREF_*
- TEE_IOC_OBJECT_INVOKE
The existing ioctl calls TEE_IOC_SUPPL_RECV and TEE_IOC_SUPPL_SEND are
used for invoking services in the userspace process by QTEE.
The TEE backend driver uses the QTEE Transport Message to communicate
with QTEE. Interactions through the object INVOKE interface are
translated into QTEE messages. Likewise, object invocations from QTEE
for userspace objects are converted into SEND/RECV ioctl calls to
supplicants.
-----BEGIN PGP SIGNATURE-----
iQJOBAABCgA4FiEE0qerISgy2SKkqO79Wr/6JGat8H4FAmjIS8AaHGplbnMud2lr
bGFuZGVyQGxpbmFyby5vcmcACgkQWr/6JGat8H4Wzg/+KnIx5XCYpj1QmL2H8vz5
dkqB5+QEHfaUIKxUrbk7X/Gow7ZTO8IuDPaiWPSIaGhOosio7fr9J6SdGWySSvBw
qXazPLgRP7tvhhUA8H1zGO6J9GSGIGENtzRyeK9QzglmkBQcoK9fLRH7StGiwFdP
f3NKPIx3YZKKL5+I4Xe8J0jvLZmiJW59cSj7m1sfDbPobuLLEKff4VFd4NSv8ufc
JKpxlxwa3xCtpjNsDJFNlpRwtO0YvF10V3xlDtRGZQs7Gq/dbOA48koA0EqZtTc9
Yhigl+F4gjleQcrpVT2QM7qJt8fdmuR77FI67YQCmr1cqY1pT/gT3l3Fri0Ok3XU
Yl+EBI32QLFTjJeGvoEehaEhhpJsWJaLDNDgOV9gDJfZoJK3UgYVjUFwWlVF8Xju
6iplkDBGpexogjDXoBo8vZEP+/EGwr+cGhWvokLymZCe8R8tfmbA4KkU1mhxo3ma
eHleGKKghC78xQzUc7gwt0pVJm4FY+uoCzbdV/S/i5j5Kn6l4un5lkUOzXH6D7lj
HBLExWqL8nxc7mC0Zxtvcd58FiVbLgjEmgMQEGOTliuO8/BXxKU1OJeyNGd4D9vz
8F2vwBSgyCcrpkx1MmDC2NxYPzUOQ58ct6z07UxlpUCcBgCXlnrRBMjX1k8CwJpn
BkiizW+aj53HRTQlWlBZLp0=
=+Jqo
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmjTDEkACgkQmmx57+YA
GNk5ww//TTwhmt8/XMNbozvUHYvz2/BsJJ9jVlFZUp9nuf7nVkDESGiNAvj439Fy
xSwnFKjplRxDwLWixsi92QSF60VfhTm3pQ7ggsga/5IoHr+R2l0L2aMzkZUl4jKX
y6pCg9A/FE1D87AfOh4dzuagddkwzOf1CEcJlE95t7NH9uome3QdsIzmc7/yg/MV
01xq+30YaSRNbGxiQkmIqChU8bJBFqaH+ygPWZVyAX0gzk9nQHhzNgvbsi8v0Otv
iFNO3/VF7uzsv2Q8Qx0unIBq6kJIxhHC3K3M1TXHJKRtax8N/8M6UVVkdfshes5+
reg0CIsOEQ9FqevyabEkirtiwvCF61knmhkKJjCnysd+18PCzLjxnNEVtY+tUomH
sFI++U5MLuybfCAx4jqjW9dEUrLNiGF8sbJTkQ4ToBjRJR1YihT9aBHeoH7OCKfb
izS03PlJqDAK7qGH7PTjabi/YmYujizxVrh29CsP3Lk0FfB5m2h2dsX1gr9Z9V5d
hq0z8nAsh6UJt26Nfq2+hhMaC4AiBn4foc+YaCx/Z8pf9pejzEu/NxRNox05LZem
EThVNRF1zTtI+0SCHGDAwV3Tuj/uuvrOl9FkcdPbP0kFErsW8b5zwZWIDvzqc2FT
L39E/C91Ptoe9ZpmCAfnyzKcfI6FeEfXwtMsLcagHsm6pcVbfyc=
=BBL5
-----END PGP SIGNATURE-----
Merge tag 'tee-qcomtee-for-v6.18' of git://git.kernel.org/pub/scm/linux/kernel/git/jenswi/linux-tee into soc/drivers
Add Qualcomm TEE driver (QTEE)
This introduces a Trusted Execution Environment (TEE) driver for
Qualcomm TEE (QTEE).
QTEE enables Trusted Applications (TAs) and services to run securely. It
uses an object-based interface, where each service is an object with
sets of operations.
Kernel and userspace services are also available to QTEE through a
similar approach. QTEE makes callback requests that are converted into
object invocations. These objects can represent services within the
kernel or userspace process.
We extend the TEE subsystem to understand object parameters and an ioctl
call so client can invoke objects in QTEE:
- TEE_IOCTL_PARAM_ATTR_TYPE_OBJREF_*
- TEE_IOC_OBJECT_INVOKE
The existing ioctl calls TEE_IOC_SUPPL_RECV and TEE_IOC_SUPPL_SEND are
used for invoking services in the userspace process by QTEE.
The TEE backend driver uses the QTEE Transport Message to communicate
with QTEE. Interactions through the object INVOKE interface are
translated into QTEE messages. Likewise, object invocations from QTEE
for userspace objects are converted into SEND/RECV ioctl calls to
supplicants.
* tag 'tee-qcomtee-for-v6.18' of git://git.kernel.org/pub/scm/linux/kernel/git/jenswi/linux-tee:
Documentation: tee: Add Qualcomm TEE driver
tee: qcom: enable TEE_IOC_SHM_ALLOC ioctl
tee: qcom: add primordial object
tee: add Qualcomm TEE driver
tee: increase TEE_MAX_ARG_SIZE to 4096
tee: add TEE_IOCTL_PARAM_ATTR_TYPE_OBJREF
tee: add TEE_IOCTL_PARAM_ATTR_TYPE_UBUF
tee: add close_context to TEE driver operation
tee: allow a driver to allocate a tee_device without a pool
Link: https://lore.kernel.org/r/20250915174957.GA2040478@rayden
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Introduce qcomtee_object, which represents an object in both QTEE and
the kernel. QTEE clients can invoke an instance of qcomtee_object to
access QTEE services. If this invocation produces a new object in QTEE,
an instance of qcomtee_object will be returned.
Similarly, QTEE can request services from by issuing a callback
request, which invokes an instance of qcomtee_object.
Implement initial support for exporting qcomtee_object to userspace
and QTEE, enabling the invocation of objects hosted in QTEE and userspace
through the TEE subsystem.
Tested-by: Neil Armstrong <neil.armstrong@linaro.org>
Tested-by: Harshal Dev <quic_hdev@quicinc.com>
Acked-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Signed-off-by: Amirreza Zarrabi <amirreza.zarrabi@oss.qualcomm.com>
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
- Allocates protected DMA-bufs from a DMA-heap instantiated from the TEE
subsystem.
- The DMA-heap uses a protected memory pool provided by the backend TEE
driver, allowing it to choose how to allocate the protected physical
memory.
- Three use-cases (Secure Video Playback, Trusted UI, and Secure Video
Recording) have been identified so far to serve as examples of what
can be expected.
- The use-cases have predefined DMA-heap names,
"protected,secure-video", "protected,trusted-ui", and
"protected,secure-video-record". The backend driver registers protected
memory pools for the use-cases it supports.
-----BEGIN PGP SIGNATURE-----
iQJOBAABCgA4FiEE0qerISgy2SKkqO79Wr/6JGat8H4FAmjD5vIaHGplbnMud2lr
bGFuZGVyQGxpbmFyby5vcmcACgkQWr/6JGat8H7nMQ//afmnhAZKFnHjCfhSuk8e
u7mOCcL32+SY2R2i/OSvXzLNo6zAfpqKPjyBT5h/DEYK+bAgHSNeCNCgmmxvrKkg
3Zptyi4+kW+XPcUvAY4yT82JwhpZoR2YTnmGjDQzhLBcIlHRDHUmVblK7XUkBHUV
YrCqc6HicqcqCKZT8ZWTWa/K1lfe0xvQWOJYVFN8yF867ThHimyp7XJglEsRjUUQ
ygPLRZHZmMNq3Paoz3WQk4v4RDEC+VNVS8DxAvYvN75dSAn7b0v72i2Y64Ox+0BO
2RQcN+PTeHCvGBng3r6PP8gW/nbPQhtu0pCAkARK8xWkTUamWP5H/DvhgzdgO45T
em9F+K4NnWtep9VtfE1dYLoe4ktyyqjmojaE+izCXOX/xtQ2V9xKyDHuPZccmLXV
p9/fXLSyVEy2NUD9W4x6tkfNdnLMINLfPJzNRT8VCFqu9ebc+ldq3Gg1zCoHaFWx
VaOQ9KtelfuNcRLauFy2f5mXkkzf7GKMTgvj636WZBk5fqCCnMF55JJhucV2hD28
I5vKJkfLGDPAXaEuPJut86MZ2bXXEVxhT9i05hb2qVSGocfPuLqwdrOYYJ253wL7
xUmVxWnwEMMK+JKfiMOOW5wdPxrzee6idUBUWZe3y3xqXkTnwFY8KP/CsXV2a7SE
Zsm9/kcU2N7xBzHwocvCUys=
=l0SR
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmjIH7kACgkQmmx57+YA
GNl8kg/9Gy9WbDLCvfu6CKOT5g7Z58jF0z1RetGA92684rCDW3hZuyiAy3nHp3h5
aSkGpJd8hcbJ6S89de7XXY4u0cvFzW8bxX9Zsb7XlKilGdzR5aNs02AHqeJ1BHkV
UcVH+zTB/qrg5JIH68RBD2CLDr7ScnlCa/1IgjU0rIuyilPDC/hsoGjazHV9mG0u
s9ieaHedVgzruNPtAy7MZyJyehuhgGTZh8mJ6O+AN8qWVSu0EIDYNVaT3dZiG0M+
M1N7C2Hxe0RMWd95+xotnz+o/3ifuqkK5BdsuomZT5X4A2oR7rxYb3En+Wsq7/aq
7x4Gdn+8W4eULKepr3l0wLQYVKCYKxbm1R7rKnfYFDOJFZwOyH/h9H56ouO2bekE
h2MsgV7lhKmMhrcAGIN9OsIz9DdPqj4n+z6lqyrCvSsWXGcKtTyTONsrzS3eKTv9
GdfpIkG9pPSlJFH1sO8OegRsolAkxUOx5P/PgdSmiGazKhnBtmFHlXXn+X56fcia
kdwNEBZxiynOkGZjgvqtQWYYr2yXD2YOp00eQHI9rzj8tL38zM49aSO8DlG41rhT
BK5Q1Qsr+dyCpb0/AUdz71LCAz4cKfIYGRavOpZXoNMi+9/+k+2/natLBOA4jetr
wDp3LH8av435LRj/g87zI8n9d7G1NMHaRWJZzOfXquFdTlH3kYk=
=z4o4
-----END PGP SIGNATURE-----
Merge tag 'tee-prot-dma-buf-for-v6.18' of git://git.kernel.org/pub/scm/linux/kernel/git/jenswi/linux-tee into soc/drivers
TEE protected DMA-bufs for v6.18
- Allocates protected DMA-bufs from a DMA-heap instantiated from the TEE
subsystem.
- The DMA-heap uses a protected memory pool provided by the backend TEE
driver, allowing it to choose how to allocate the protected physical
memory.
- Three use-cases (Secure Video Playback, Trusted UI, and Secure Video
Recording) have been identified so far to serve as examples of what
can be expected.
- The use-cases have predefined DMA-heap names,
"protected,secure-video", "protected,trusted-ui", and
"protected,secure-video-record". The backend driver registers protected
memory pools for the use-cases it supports.
* tag 'tee-prot-dma-buf-for-v6.18' of git://git.kernel.org/pub/scm/linux/kernel/git/jenswi/linux-tee:
optee: smc abi: dynamic protected memory allocation
optee: FF-A: dynamic protected memory allocation
optee: support protected memory allocation
tee: add tee_shm_alloc_dma_mem()
tee: new ioctl to a register tee_shm from a dmabuf file descriptor
tee: refactor params_from_user()
tee: implement protected DMA-heap
dma-buf: dma-heap: export declared functions
optee: sync secure world ABI headers
Link: https://lore.kernel.org/r/20250912101752.GA1453408@rayden
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Implement DMA heap for protected DMA-buf allocation in the TEE
subsystem.
Protected memory refers to memory buffers behind a hardware enforced
firewall. It is not accessible to the kernel during normal circumstances
but rather only accessible to certain hardware IPs or CPUs executing in
higher or differently privileged mode than the kernel itself. This
interface allows to allocate and manage such protected memory buffers
via interaction with a TEE implementation.
The protected memory is allocated for a specific use-case, like Secure
Video Playback, Trusted UI, or Secure Video Recording where certain
hardware devices can access the memory.
The DMA-heaps are enabled explicitly by the TEE backend driver. The TEE
backend drivers needs to implement protected memory pool to manage the
protected memory.
Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
Use the SHA-1 library functions instead of crypto_shash. This is
simpler and faster.
Change uuid_v5() to return void, since it can no longer fail.
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
The Trusted Services project provides a framework for developing and
deploying device Root of Trust services in FF-A Secure Partitions. The
FF-A SPs are accessible through the FF-A driver, but this doesn't
provide a user space interface. The goal of this TEE driver is to make
Trusted Services SPs accessible for user space clients.
All TS SPs have the same FF-A UUID, it identifies the RPC protocol used
by TS. A TS SP can host one or more services, a service is identified by
its service UUID. The same type of service cannot be present twice in
the same SP. During SP boot each service in an SP is assigned an
interface ID, this is just a short ID to simplify message addressing.
There is 1:1 mapping between TS SPs and TEE devices, i.e. a separate TEE
device is registered for each TS SP. This is required since contrary to
the generic TEE design where memory is shared with the whole TEE
implementation, in case of FF-A, memory is shared with a specific SP. A
user space client has to be able to separately share memory with each SP
based on its endpoint ID.
Acked-by: Sumit Garg <sumit.garg@linaro.org>
Signed-off-by: Balint Dobszay <balint.dobszay@arm.com>
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
Don't let TEE occupy two lines in menuconfig when practically no
other (sub)menu does either.
Signed-off-by: Jan Engelhardt <jengelh@inai.de>
Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
TEE Client API defines that from user space only information needed for
specified login operations is group identifier for group based logins.
REE kernel is expected to formulate trustworthy client UUID and pass that
to TEE environment. REE kernel is required to verify that provided group
identifier for group based logins matches calling processes group
memberships.
TEE specification only defines that the information passed from REE
environment to TEE environment is encoded into on UUID.
In order to guarantee trustworthiness of client UUID user space is not
allowed to freely pass client UUID.
UUIDv5 form is used encode variable amount of information needed for
different login types.
Signed-off-by: Vesa Jääskeläinen <vesa.jaaskelainen@vaisala.com>
[jw: remove unused variable application_id]
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
Adds AMD-TEE driver.
* targets AMD APUs which has AMD Secure Processor with software-based
Trusted Execution Environment (TEE) support
* registers with TEE subsystem
* defines tee_driver_ops function callbacks
* kernel allocated memory is used as shared memory between normal
world and secure world.
* acts as REE (Rich Execution Environment) communication agent, which
uses the services of AMD Secure Processor driver to submit commands
for processing in TEE environment
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>
Co-developed-by: Devaraj Rangasamy <Devaraj.Rangasamy@amd.com>
Signed-off-by: Devaraj Rangasamy <Devaraj.Rangasamy@amd.com>
Signed-off-by: Rijo Thomas <Rijo-john.Thomas@amd.com>
Reviewed-by: Gary R Hook <gary.hook@amd.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Allow compilation of tee subsystem for AMD's CPUs which have a dedicated
AMD Secure Processor for Trusted Execution Environment (TEE).
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>
Co-developed-by: Devaraj Rangasamy <Devaraj.Rangasamy@amd.com>
Signed-off-by: Devaraj Rangasamy <Devaraj.Rangasamy@amd.com>
Signed-off-by: Rijo Thomas <Rijo-john.Thomas@amd.com>
Reviewed-by: Gary R Hook <gary.hook@amd.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Add SPDX license identifiers to all Make/Kconfig files which:
- Have no license information of any form
These files fall under the project license, GPL v2 only. The resulting SPDX
license identifier is:
GPL-2.0-only
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
For the moment, the tee subsystem only makes sense in combination with
the op-tee driver that depends on ARM_SMCCC, so let's hide the subsystem
from users that can't select that.
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Adds a OP-TEE driver which also can be compiled as a loadable module.
* Targets ARM and ARM64
* Supports using reserved memory from OP-TEE as shared memory
* Probes OP-TEE version using SMCs
* Accepts requests on privileged and unprivileged device
* Uses OPTEE message protocol version 2 to communicate with secure world
Acked-by: Andreas Dannenberg <dannenberg@ti.com>
Tested-by: Jerome Forissier <jerome.forissier@linaro.org> (HiKey)
Tested-by: Volodymyr Babchuk <vlad.babchuk@gmail.com> (RCAR H3)
Tested-by: Scott Branden <scott.branden@broadcom.com>
Reviewed-by: Javier González <javier@javigon.com>
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
Initial patch for generic TEE subsystem.
This subsystem provides:
* Registration/un-registration of TEE drivers.
* Shared memory between normal world and secure world.
* Ioctl interface for interaction with user space.
* Sysfs implementation_id of TEE driver
A TEE (Trusted Execution Environment) driver is a driver that interfaces
with a trusted OS running in some secure environment, for example,
TrustZone on ARM cpus, or a separate secure co-processor etc.
The TEE subsystem can serve a TEE driver for a Global Platform compliant
TEE, but it's not limited to only Global Platform TEEs.
This patch builds on other similar implementations trying to solve
the same problem:
* "optee_linuxdriver" by among others
Jean-michel DELORME<jean-michel.delorme@st.com> and
Emmanuel MICHEL <emmanuel.michel@st.com>
* "Generic TrustZone Driver" by Javier González <javier@javigon.com>
Acked-by: Andreas Dannenberg <dannenberg@ti.com>
Tested-by: Jerome Forissier <jerome.forissier@linaro.org> (HiKey)
Tested-by: Volodymyr Babchuk <vlad.babchuk@gmail.com> (RCAR H3)
Tested-by: Scott Branden <scott.branden@broadcom.com>
Reviewed-by: Javier González <javier@javigon.com>
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
