kernel/linux.git/drivers/tee/tee_core.c, branch v6.18.21

Merge tag 'tee-qcomtee-for-v6.18' of git://git.kernel.org/pub/scm/linux/kernel/git/jenswi/linux-tee into soc/drivers

2025-09-23T21:08:25+00:00

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

tee: add TEE_IOCTL_PARAM_ATTR_TYPE_OBJREF

2025-09-15T15:34:06+00:00

The TEE subsystem allows session-based access to trusted services, requiring a session to be established to receive a service. This is not suitable for an environment that represents services as objects. An object supports various operations that a client can invoke, potentially generating a result or a new object that can be invoked independently of the original object. Add TEE_IOCTL_PARAM_ATTR_TYPE_OBJREF_INPUT/OUTPUT/INOUT to represent an object. Objects may reside in either TEE or userspace. To invoke an object in TEE, introduce a new ioctl. Use the existing SUPPL_RECV and SUPPL_SEND to invoke an object in userspace. Reviewed-by: Sumit Garg Tested-by: Neil Armstrong Tested-by: Harshal Dev Signed-off-by: Amirreza Zarrabi Signed-off-by: Jens Wiklander

tee: add TEE_IOCTL_PARAM_ATTR_TYPE_UBUF

2025-09-15T15:34:06+00:00

For drivers that can transfer data to the TEE without using shared memory from client, it is necessary to receive the user address directly, bypassing any processing by the TEE subsystem. Introduce TEE_IOCTL_PARAM_ATTR_TYPE_UBUF_INPUT/OUTPUT/INOUT to represent userspace buffers. Reviewed-by: Sumit Garg Tested-by: Neil Armstrong Tested-by: Harshal Dev Signed-off-by: Amirreza Zarrabi Signed-off-by: Jens Wiklander

tee: add close_context to TEE driver operation

2025-09-15T15:34:06+00:00

The tee_context can be used to manage TEE user resources, including those allocated by the driver for the TEE on behalf of the user. The release() callback is invoked only when all resources, such as tee_shm, are released and there are no references to the tee_context. When a user closes the device file, the driver should notify the TEE to release any resources it may hold and drop the context references. To achieve this, a close_context() callback is introduced to initiate resource release in the TEE driver when the device file is closed. Relocate teedev_ctx_get, teedev_ctx_put, tee_device_get, and tee_device_get functions to tee_core.h to make them accessible outside the TEE subsystem. Reviewed-by: Sumit Garg Tested-by: Neil Armstrong Tested-by: Harshal Dev Signed-off-by: Amirreza Zarrabi Signed-off-by: Jens Wiklander

tee: allow a driver to allocate a tee_device without a pool

2025-09-15T15:34:06+00:00

A TEE driver doesn't always need to provide a pool if it doesn't support memory sharing ioctls and can allocate memory for TEE messages in another way. Although this is mentioned in the documentation for tee_device_alloc(), it is not handled correctly. Reviewed-by: Sumit Garg Signed-off-by: Amirreza Zarrabi Signed-off-by: Jens Wiklander

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

2025-09-15T14:16:25+00:00

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

Merge tag 'tee-sha1-lib-for-v6.18' of git://git.kernel.org/pub/scm/linux/kernel/git/jenswi/linux-tee into soc/drivers

2025-09-15T14:01:36+00:00

Use SHA-1 library instead of crypto_shash * tag 'tee-sha1-lib-for-v6.18' of git://git.kernel.org/pub/scm/linux/kernel/git/jenswi/linux-tee: tee: Use SHA-1 library instead of crypto_shash Link: https://lore.kernel.org/r/20250912091611.GA1442659@rayden Signed-off-by: Arnd Bergmann

tee: new ioctl to a register tee_shm from a dmabuf file descriptor

2025-09-11T09:22:29+00:00

Add a userspace API to create a tee_shm object that refers to a dmabuf reference. Userspace registers the dmabuf file descriptor as in a tee_shm object. The registration is completed with a tee_shm returned file descriptor. Userspace is free to close the dmabuf file descriptor after it has been registered since all the resources are now held via the new tee_shm object. Closing the tee_shm file descriptor will eventually release all resources used by the tee_shm object when all references are released. The new IOCTL, TEE_IOC_SHM_REGISTER_FD, supports dmabuf references to physically contiguous memory buffers. Dmabuf references acquired from the TEE DMA-heap can be used as protected memory for Secure Video Path and such use cases. It depends on the TEE and the TEE driver if dmabuf references acquired by other means can be used. A new tee_shm flag is added to identify tee_shm objects built from a registered dmabuf, TEE_SHM_DMA_BUF. Signed-off-by: Etienne Carriere Signed-off-by: Olivier Masse Reviewed-by: Sumit Garg Signed-off-by: Jens Wiklander

tee: refactor params_from_user()

2025-09-11T09:22:26+00:00

Break out the memref handling into a separate helper function. No change in behavior. Reviewed-by: Sumit Garg Signed-off-by: Jens Wiklander

tee: implement protected DMA-heap

2025-09-11T09:22:20+00:00

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 Signed-off-by: Jens Wiklander