Linux kernel stable tree (mirror) https://git.radix-linux.su/kernel/linux.git/atom?h=v6.19.11 2025-09-23T21:08:25+00:00 2025-09-23T21:08:25+00:00 Arnd Bergmann arnd@arndb.de 2025-09-23T21:08:23+00:00 urn:sha1:ff0bebab778c7474c328bc7e5e9bf3c39bf4fc1a 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> 2025-09-15T15:34:06+00:00 Amirreza Zarrabi amirreza.zarrabi@oss.qualcomm.com 2025-09-12T04:07:47+00:00 urn:sha1:d6e290837e50f73f88f31f19bd8a7213d92e6e46 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> 2025-09-15T14:16:25+00:00 Arnd Bergmann arnd@arndb.de 2025-09-15T14:05:04+00:00 urn:sha1:820429d53bd7c8b19beb5686540f372be2a18eea 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> 2025-09-11T09:22:20+00:00 Jens Wiklander jens.wiklander@linaro.org 2025-08-13T06:02:52+00:00 urn:sha1:c924c65f52c300ba36373e140a43a8e723c3abdd 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> 2025-08-13T12:29:49+00:00 Eric Biggers ebiggers@kernel.org 2025-08-01T23:55:41+00:00 urn:sha1:dfb2a4f76ff7f60d6e2a55b6a973dd42930adf50 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> 2024-04-03T12:03:09+00:00 Balint Dobszay balint.dobszay@arm.com 2024-03-25T15:11:03+00:00 urn:sha1:c835e5a3153cae2956efdbb9948b90f2b9e5e64d 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> 2022-04-05T05:32:23+00:00 Jan Engelhardt jengelh@inai.de 2021-12-28T19:57:37+00:00 urn:sha1:a4b75fe8e1c15c96c4eb083e211ccbbfd56599f9 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> 2020-05-28T10:38:00+00:00 Arnd Bergmann arnd@arndb.de 2020-05-27T13:39:16+00:00 urn:sha1:60b4000f54649546b4780ac61b67e5601382225d When selecting a crypto cipher, we also need to select the subsystem itself: WARNING: unmet direct dependencies detected for CRYPTO_SHA1 Depends on [m]: CRYPTO [=m] Selected by [y]: - TEE [=y] && (HAVE_ARM_SMCCC [=n] || COMPILE_TEST [=y] || CPU_SUP_AMD [=y]) Selected by [m]: - CRYPTO_DEV_QAT [=m] && CRYPTO [=m] && CRYPTO_HW [=y] - CRYPTO_DEV_MEDIATEK [=m] && CRYPTO [=m] && CRYPTO_HW [=y] && (ARM && ARCH_MEDIATEK || COMPILE_TEST [=y]) - CRYPTO_DEV_SAFEXCEL [=m] && CRYPTO [=m] && CRYPTO_HW [=y] && (OF [=y] || PCI [=y] || COMPILE_TEST [=y]) && HAS_IOMEM [=y] - CRYPTO_DEV_CCREE [=m] && CRYPTO [=m] && CRYPTO_HW [=y] && OF [=y] && HAS_DMA [=y] - CRYPTO_DEV_SP_CCP [=y] && CRYPTO [=m] && CRYPTO_HW [=y] && CRYPTO_DEV_CCP [=y] && CRYPTO_DEV_CCP_DD [=m] && DMADEVICES [=y] Link: https://lore.kernel.org/r/20200527133924.724819-1-arnd@arndb.de Fixes: e33bcbab16d1 ("tee: add support for session's client UUID generation") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Vesa Jääskeläinen <vesa.jaaskelainen@vaisala.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> 2020-05-11T12:11:26+00:00 Vesa Jääskeläinen vesa.jaaskelainen@vaisala.com 2020-04-30T12:37:09+00:00 urn:sha1:e33bcbab16d1c0dd85d72bec275308369ad901f5 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> 2020-01-04T05:49:51+00:00 Rijo Thomas Rijo-john.Thomas@amd.com 2019-12-27T05:24:01+00:00 urn:sha1:757cc3e9ff1d72d014096399d6e2bf03974d9da1 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>