March 2025 - OP-TEE - lists.trustedfirmware.org

[PATCH v6 00/10] TEE subsystem for restricted dma-buf allocations

by Jens Wiklander

Hi, This patch set allocates the restricted DMA-bufs from a DMA-heap instantiated from the TEE subsystem. The TEE subsystem handles the DMA-buf allocations since it is the TEE (OP-TEE, AMD-TEE, TS-TEE, or perhaps a future QTEE) which sets up the restrictions for the memory used for the DMA-bufs. The DMA-heap uses a restricted memory pool provided by the backend TEE driver, allowing it to choose how to allocate the restricted physical memory. The allocated DMA-bufs must be imported with a new TEE_IOC_SHM_REGISTER_FD before they can be passed as arguments when requesting services from the secure world. Three use-cases (Secure Video Playback, Trusted UI, and Secure Video Recording) has been identified so far to serve as examples of what can be expected. The use-cases has predefined DMA-heap names, "restricted,secure-video", "restricted,trusted-ui", and "restricted,secure-video-record". The backend driver registers restricted memory pools for the use-cases it supports. Each use-case has it's own restricted memory pool since different use-cases requires isolation from different parts of the system. A restricted memory pool can be based on a static carveout instantiated while probing the TEE backend driver, or dynamically allocated from CMA and made restricted as needed by the TEE. This can be tested on a RockPi 4B+ with the following steps: repo init -u https://github.com/jenswi-linaro/manifest.git -m rockpi4.xml \ -b prototype/sdp-v6 repo sync -j8 cd build make toolchains -j$(nproc) make all -j$(nproc) # Copy ../out/rockpi4.img to an SD card and boot the RockPi from that # Connect a monitor to the RockPi # login and at the prompt: gst-launch-1.0 videotestsrc ! \ aesenc key=1f9423681beb9a79215820f6bda73d0f \ iv=e9aa8e834d8d70b7e0d254ff670dd718 serialize-iv=true ! \ aesdec key=1f9423681beb9a79215820f6bda73d0f ! \ kmssink The aesdec module has been hacked to use an OP-TEE TA to decrypt the stream into restricted DMA-bufs which are consumed by the kmssink. The primitive QEMU tests from previous patch set can be tested on RockPi in the same way with: xtest --sdp-basic The primitive test are tested on QEMU with the following steps: repo init -u https://github.com/jenswi-linaro/manifest.git -m qemu_v8.xml \ -b prototype/sdp-v6 repo sync -j8 cd build make toolchains -j$(nproc) make SPMC_AT_EL=1 all -j$(nproc) make SPMC_AT_EL=1 run-only # login and at the prompt: xtest --sdp-basic The SPMC_AT_EL=1 parameter configures the build with FF-A and an SPMC at S-EL1 inside OP-TEE. The parameter can be changed into SPMC_AT_EL=n to test without FF-A using the original SMC ABI instead. Please remember to do %rm -rf ../trusted-firmware-a/build/qemu for TF-A to be rebuilt properly using the new configuration. https://optee.readthedocs.io/en/latest/building/prerequisites.html list dependencies needed to build the above. The tests are pretty basic, mostly checking that a Trusted Application in the secure world can access and manipulate the memory. There are also some negative tests for out of bounds buffers etc. Thanks, Jens Changes since V5: * Removing "tee: add restricted memory allocation" and "tee: add TEE_IOC_RSTMEM_FD_INFO" * Adding "tee: implement restricted DMA-heap", "tee: new ioctl to a register tee_shm from a dmabuf file descriptor", "tee: add tee_shm_alloc_cma_phys_mem()", "optee: pass parent device to tee_device_alloc()", and "tee: tee_device_alloc(): copy dma_mask from parent device" * The two TEE driver OPs "rstmem_alloc()" and "rstmem_free()" are replaced with a struct tee_rstmem_pool abstraction. * Replaced the the TEE_IOC_RSTMEM_ALLOC user space API with the DMA-heap API Changes since V4: * Adding the patch "tee: add TEE_IOC_RSTMEM_FD_INFO" needed by the GStreamer demo * Removing the dummy CPU access and mmap functions from the dma_buf_ops * Fixing a compile error in "optee: FF-A: dynamic restricted memory allocation" reported by kernel test robot <lkp(a)intel.com> Changes since V3: * Make the use_case and flags field in struct tee_shm u32's instead of u16's * Add more description for TEE_IOC_RSTMEM_ALLOC in the header file * Import namespace DMA_BUF in module tee, reported by lkp(a)intel.com * Added a note in the commit message for "optee: account for direction while converting parameters" why it's needed * Factor out dynamic restricted memory allocation from "optee: support restricted memory allocation" into two new commits "optee: FF-A: dynamic restricted memory allocation" and "optee: smc abi: dynamic restricted memory allocation" * Guard CMA usage with #ifdef CONFIG_CMA, effectively disabling dynamic restricted memory allocate if CMA isn't configured Changes since the V2 RFC: * Based on v6.12 * Replaced the flags for SVP and Trusted UID memory with a u32 field with unique id for each use case * Added dynamic allocation of restricted memory pools * Added OP-TEE ABI both with and without FF-A for dynamic restricted memory * Added support for FF-A with FFA_LEND Changes since the V1 RFC: * Based on v6.11 * Complete rewrite, replacing the restricted heap with TEE_IOC_RSTMEM_ALLOC Changes since Olivier's post [2]: * Based on Yong Wu's post [1] where much of dma-buf handling is done in the generic restricted heap * Simplifications and cleanup * New commit message for "dma-buf: heaps: add Linaro restricted dmabuf heap support" * Replaced the word "secure" with "restricted" where applicable Etienne Carriere (1): tee: new ioctl to a register tee_shm from a dmabuf file descriptor Jens Wiklander (9): tee: tee_device_alloc(): copy dma_mask from parent device optee: pass parent device to tee_device_alloc() optee: account for direction while converting parameters optee: sync secure world ABI headers tee: implement restricted DMA-heap tee: add tee_shm_alloc_cma_phys_mem() optee: support restricted memory allocation optee: FF-A: dynamic restricted memory allocation optee: smc abi: dynamic restricted memory allocation drivers/tee/Makefile | 1 + drivers/tee/optee/Makefile | 1 + drivers/tee/optee/call.c | 10 +- drivers/tee/optee/core.c | 1 + drivers/tee/optee/ffa_abi.c | 194 +++++++++++- drivers/tee/optee/optee_ffa.h | 27 +- drivers/tee/optee/optee_msg.h | 65 ++++- drivers/tee/optee/optee_private.h | 55 +++- drivers/tee/optee/optee_smc.h | 71 ++++- drivers/tee/optee/rpc.c | 31 +- drivers/tee/optee/rstmem.c | 329 +++++++++++++++++++++ drivers/tee/optee/smc_abi.c | 190 ++++++++++-- drivers/tee/tee_core.c | 147 +++++++--- drivers/tee/tee_heap.c | 470 ++++++++++++++++++++++++++++++ drivers/tee/tee_private.h | 7 + drivers/tee/tee_shm.c | 199 ++++++++++++- include/linux/tee_core.h | 67 +++++ include/linux/tee_drv.h | 10 + include/uapi/linux/tee.h | 29 ++ 19 files changed, 1781 insertions(+), 123 deletions(-) create mode 100644 drivers/tee/optee/rstmem.c create mode 100644 drivers/tee/tee_heap.c base-commit: 7eb172143d5508b4da468ed59ee857c6e5e01da6 -- 2.43.0

2 days, 6 hours

2
39
0 0

[PATCH v3 00/11] Trusted Execution Environment (TEE) driver for Qualcomm TEE (QTEE)

by Amirreza Zarrabi

This patch series 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. Clients can invoke these operations on objects, which can generate results, including other objects. For example, an object can load a TA and return another object that represents the loaded TA, allowing access to its services. 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. Note: This patch series focuses on QTEE objects and userspace services. Linux already provides a TEE subsystem, which is described in [1]. The tee subsystem provides a generic ioctl interface, TEE_IOC_INVOKE, which can be used by userspace to talk to a TEE backend driver. We extend the Linux 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. The details of QTEE Transport Message to communicate with QTEE is available in [PATCH 10/10] Documentation: tee: Add Qualcomm TEE driver. You can run basic tests with following steps: git clone https://github.com/quic/quic-teec.git cd quic-teec mkdir build cmake .. -DCMAKE_TOOLCHAIN_FILE=CMakeToolchain.txt -DBUILD_UNITTEST=ON https://github.com/quic/quic-teec/blob/main/README.md lists dependancies needed to build the above. This series has been tested for basic QTEE object invocations and callback requests, including loading a TA and requesting services form the TA. Tested platforms: sm8650-mtp [1] https://www.kernel.org/doc/Documentation/tee.txt Signed-off-by: Amirreza Zarrabi <amirreza.zarrabi(a)oss.qualcomm.com> Changes in v3: - Export shm_bridge create/delete APIs. - Enable support for QTEE memory objects. - Update the memory management code to use the TEE subsystem for all allocations using the pool. - Move all driver states into the driver's main service struct. - Add more documentations. - Link to v2: https://lore.kernel.org/r/20250202-qcom-tee-using-tee-ss-without-mem-obj-v2… Changes in v2: - Clean up commit messages and comments. - Use better names such as ubuf instead of membuf or QCOMTEE prefix instead of QCOM_TEE, or names that are more consistent with other TEE-backend drivers such as qcomtee_context_data instead of qcom_tee_context. - Drop the DTS patch and instantiate the device from the scm driver. - Use a single structure for all driver's internal states. - Drop srcu primitives and use the existing mutex for synchronization between the supplicant and QTEE. - Directly use tee_context to track the lifetime of qcomtee_context_data. - Add close_context() to be called when the user closes the tee_context. - Link to v1: https://lore.kernel.org/r/20241202-qcom-tee-using-tee-ss-without-mem-obj-v1… Changes in v1: - It is a complete rewrite to utilize the TEE subsystem. - Link to RFC: https://lore.kernel.org/all/20240702-qcom-tee-object-and-ioctls-v1-0-633c3d… --- Amirreza Zarrabi (11): tee: allow a driver to allocate a tee_device without a pool tee: add close_context to TEE driver operation tee: add TEE_IOCTL_PARAM_ATTR_TYPE_UBUF tee: add TEE_IOCTL_PARAM_ATTR_TYPE_OBJREF firmware: qcom: scm: add support for object invocation firmware: qcom: scm: remove unused arguments to the shm_brige firmware: qcom: tzmem: export shm_bridge create/delete tee: add Qualcomm TEE driver qcomtee: add primordial object qcomtee: enable TEE_IOC_SHM_ALLOC ioctl Documentation: tee: Add Qualcomm TEE driver Documentation/tee/index.rst | 1 + Documentation/tee/qtee.rst | 150 ++++++ drivers/firmware/qcom/qcom_scm.c | 132 ++++- drivers/firmware/qcom/qcom_scm.h | 7 + drivers/firmware/qcom/qcom_tzmem.c | 57 ++- drivers/tee/Kconfig | 1 + drivers/tee/Makefile | 1 + drivers/tee/qcomtee/Kconfig | 10 + drivers/tee/qcomtee/Makefile | 11 + drivers/tee/qcomtee/async.c | 160 ++++++ drivers/tee/qcomtee/call.c | 759 +++++++++++++++++++++++++++++ drivers/tee/qcomtee/core.c | 810 +++++++++++++++++++++++++++++++ drivers/tee/qcomtee/mem_obj.c | 172 +++++++ drivers/tee/qcomtee/primordial_obj.c | 116 +++++ drivers/tee/qcomtee/qcom_scm.c | 38 ++ drivers/tee/qcomtee/qcomtee_msg.h | 239 +++++++++ drivers/tee/qcomtee/qcomtee_private.h | 264 ++++++++++ drivers/tee/qcomtee/release.c | 48 ++ drivers/tee/qcomtee/shm.c | 146 ++++++ drivers/tee/qcomtee/user_obj.c | 710 +++++++++++++++++++++++++++ drivers/tee/tee_core.c | 159 +++++- drivers/tee/tee_private.h | 6 - include/linux/firmware/qcom/qcom_scm.h | 31 +- include/linux/firmware/qcom/qcom_tee.h | 302 ++++++++++++ include/linux/firmware/qcom/qcom_tzmem.h | 15 + include/linux/tee_core.h | 15 +- include/linux/tee_drv.h | 52 ++ include/uapi/linux/tee.h | 54 ++- 28 files changed, 4434 insertions(+), 32 deletions(-) --- base-commit: db8da9da41bced445077925f8a886c776a47440c change-id: 20241202-qcom-tee-using-tee-ss-without-mem-obj-362c66340527 Best regards, -- Amirreza Zarrabi <amirreza.zarrabi(a)oss.qualcomm.com>

5 days, 15 hours

2
13
0 0

[PATCH v2] tee: shm: fix slab page refcounting

by Marco Felsch

Skip manipulating the refcount in case of slab pages according commit b9c0e49abfca ("mm: decline to manipulate the refcount on a slab page"). Fixes: b9c0e49abfca ("mm: decline to manipulate the refcount on a slab page") Signed-off-by: Marco Felsch <m.felsch(a)pengutronix.de> --- v2: - Make use of page variable v1: - https://lore.kernel.org/all/20250325195021.3589797-1-m.felsch@pengutronix.d… drivers/tee/tee_shm.c | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/drivers/tee/tee_shm.c b/drivers/tee/tee_shm.c index daf6e5cfd59a..35f0ac359b12 100644 --- a/drivers/tee/tee_shm.c +++ b/drivers/tee/tee_shm.c @@ -19,16 +19,24 @@ static void shm_put_kernel_pages(struct page **pages, size_t page_count) { size_t n; - for (n = 0; n < page_count; n++) - put_page(pages[n]); + for (n = 0; n < page_count; n++) { + struct page *page = pages[n]; + + if (!PageSlab(page)) + put_page(page); + } } static void shm_get_kernel_pages(struct page **pages, size_t page_count) { size_t n; - for (n = 0; n < page_count; n++) - get_page(pages[n]); + for (n = 0; n < page_count; n++) { + struct page *page = pages[n]; + + if (!PageSlab(page)) + get_page(page); + } } static void release_registered_pages(struct tee_shm *shm) -- 2.39.5

1 week

4
6
0 0

[PATCH] tee: shm: fix slab page refcounting

by Marco Felsch

Skip manipulating the refcount in case of slab pages according commit b9c0e49abfca ("mm: decline to manipulate the refcount on a slab page"). Fixes: b9c0e49abfca ("mm: decline to manipulate the refcount on a slab page") Signed-off-by: Marco Felsch <m.felsch(a)pengutronix.de> --- drivers/tee/tee_shm.c | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/drivers/tee/tee_shm.c b/drivers/tee/tee_shm.c index daf6e5cfd59a..3d6a3077b6f2 100644 --- a/drivers/tee/tee_shm.c +++ b/drivers/tee/tee_shm.c @@ -19,16 +19,24 @@ static void shm_put_kernel_pages(struct page **pages, size_t page_count) { size_t n; - for (n = 0; n < page_count; n++) - put_page(pages[n]); + for (n = 0; n < page_count; n++) { + struct page *page = pages[n]; + + if (!PageSlab(page)) + put_page(pages[n]); + } } static void shm_get_kernel_pages(struct page **pages, size_t page_count) { size_t n; - for (n = 0; n < page_count; n++) - get_page(pages[n]); + for (n = 0; n < page_count; n++) { + struct page *page = pages[n]; + + if (!PageSlab(page)) + get_page(pages[n]); + } } static void release_registered_pages(struct tee_shm *shm) -- 2.39.5

1 week, 2 days

1
1
0 0

[PATCH v16 0/6] Introduction of a remoteproc tee to load signed firmware

by Arnaud Pouliquen

Main updates from version V15[1]: - Removed the rproc_ops:load_fw() operation introduced in the previous version. - Returned to managing the remoteproc firmware loading in rproc_tee_parse_fw to load and authenticate the firmware before getting the resource table. - Added spinlock and dev_link mechanisms in remoteproc TEE to better manage bind/unbind. More details are available in each patch commit message. [1] https://lore.kernel.org/linux-remoteproc/20241128084219.2159197-7-arnaud.po… Tested-on: commit 0a0ba9924445 ("Linux 6.14-rc7") Description of the feature: -------------------------- This series proposes the implementation of a remoteproc tee driver to communicate with a TEE trusted application responsible for authenticating and loading the remoteproc firmware image in an Arm secure context. 1) Principle: The remoteproc tee driver provides services to communicate with the OP-TEE trusted application running on the Trusted Execution Context (TEE). The trusted application in TEE manages the remote processor lifecycle: - authenticating and loading firmware images, - isolating and securing the remote processor memories, - supporting multi-firmware (e.g., TF-M + Zephyr on a Cortex-M33), - managing the start and stop of the firmware by the TEE. 2) Format of the signed image: Refer to: https://github.com/OP-TEE/optee_os/blob/master/ta/remoteproc/src/remoteproc… 3) OP-TEE trusted application API: Refer to: https://github.com/OP-TEE/optee_os/blob/master/ta/remoteproc/include/ta_rem… 4) OP-TEE signature script Refer to: https://github.com/OP-TEE/optee_os/blob/master/scripts/sign_rproc_fw.py Example of usage: sign_rproc_fw.py --in <fw1.elf> --in <fw2.elf> --out <signed_fw.sign> --key ${OP-TEE_PATH}/keys/default.pem 5) Impact on User space Application No sysfs impact. The user only needs to provide the signed firmware image instead of the ELF image. For more information about the implementation, a presentation is available here (note that the format of the signed image has evolved between the presentation and the integration in OP-TEE). https://resources.linaro.org/en/resource/6c5bGvZwUAjX56fvxthxds Arnaud Pouliquen (6): remoteproc: core: Introduce rproc_pa_to_va helper remoteproc: Add TEE support remoteproc: Introduce release_fw optional operation dt-bindings: remoteproc: Add compatibility for TEE support remoteproc: stm32: Create sub-functions to request shutdown and release remoteproc: stm32: Add support of an OP-TEE TA to load the firmware .../bindings/remoteproc/st,stm32-rproc.yaml | 58 +- drivers/remoteproc/Kconfig | 10 + drivers/remoteproc/Makefile | 1 + drivers/remoteproc/remoteproc_core.c | 52 ++ drivers/remoteproc/remoteproc_internal.h | 6 + drivers/remoteproc/remoteproc_tee.c | 619 ++++++++++++++++++ drivers/remoteproc/stm32_rproc.c | 139 +++- include/linux/remoteproc.h | 4 + include/linux/remoteproc_tee.h | 90 +++ 9 files changed, 935 insertions(+), 44 deletions(-) create mode 100644 drivers/remoteproc/remoteproc_tee.c create mode 100644 include/linux/remoteproc_tee.h base-commit: 0a0ba99244455fea8706c4a53f5f66a45d87905d -- 2.25.1

1 week, 2 days

1
6
0 0

Linaro OP-TEE Contribution, LOC, monthly meeting March 25

by Jens Wiklander

Hi, Tomorrow, Tuesday, it's time for another LOC monthly meeting. For time and connection details see the calendar at https://www.trustedfirmware.org/meetings/ I've posted another version of the Secure Data Path patches [1] if you have any thoughts on that. [1] https://lore.kernel.org/lkml/20250305130634.1850178-1-jens.wiklander@linaro… Are there any other topics? Cheers, Jesn

1 week, 3 days

1
0
0 0

[PATCH v4 0/6] TEE subsystem for restricted dma-buf allocations

by Jens Wiklander

Hi, This patch set allocates the restricted DMA-bufs via the TEE subsystem. The TEE subsystem handles the DMA-buf allocations since it is the TEE (OP-TEE, AMD-TEE, TS-TEE, or perhaps a future QCOMTEE) which sets up the restrictions for the memory used for the DMA-bufs. I've added a new IOCTL, TEE_IOC_RSTMEM_ALLOC, to allocate the restricted DMA-bufs. This IOCTL reaches the backend TEE driver, allowing it to choose how to allocate the restricted physical memory. TEE_IOC_RSTMEM_ALLOC takes in addition to a size and flags parameters also a use-case parameter. This is used by the backend TEE driver to decide on allocation policy and which devices should be able to access the memory. Three use-cases (Secure Video Playback, Trusted UI, and Secure Video Recording) has been identified so far to serve as examples of what can be expected. More use-cases can be added in userspace ABI, but it's up to the backend TEE drivers to provide the implementation. Each use-case has it's own restricted memory pool since different use-cases requires isolation from different parts of the system. A restricted memory pool can be based on a static carveout instantiated while probing the TEE backend driver, or dynamically allocated from CMA and made restricted as needed by the TEE. This can be tested on QEMU with the following steps: repo init -u https://github.com/jenswi-linaro/manifest.git -m qemu_v8.xml \ -b prototype/sdp-v4 repo sync -j8 cd build make toolchains -j$(nproc) make SPMC_AT_EL=1 all -j$(nproc) make SPMC_AT_EL=1 run-only # login and at the prompt: xtest --sdp-basic The SPMC_AT_EL=1 parameter configures the build with FF-A and an SPMC at S-EL1 inside OP-TEE. The parameter can be changed into SPMC_AT_EL=n to test without FF-A using the original SMC ABI instead. Please remember to do %rm -rf ../trusted-firmware-a/build/qemu for TF-A to be rebuilt properly using the new configuration. https://optee.readthedocs.io/en/latest/building/prerequisites.html list dependencies needed to build the above. The tests are pretty basic, mostly checking that a Trusted Application in the secure world can access and manipulate the memory. There are also some negative tests for out of bounds buffers etc. Thanks, Jens Changes since V3: * Make the use_case and flags field in struct tee_shm u32's instead of u16's * Add more description for TEE_IOC_RSTMEM_ALLOC in the header file * Import namespace DMA_BUF in module tee, reported by lkp(a)intel.com * Added a note in the commit message for "optee: account for direction while converting parameters" why it's needed * Factor out dynamic restricted memory allocation from "optee: support restricted memory allocation" into two new commits "optee: FF-A: dynamic restricted memory allocation" and "optee: smc abi: dynamic restricted memory allocation" * Guard CMA usage with #ifdef CONFIG_CMA, effectively disabling dynamic restricted memory allocate if CMA isn't configured Changes since the V2 RFC: * Based on v6.12 * Replaced the flags for SVP and Trusted UID memory with a u32 field with unique id for each use case * Added dynamic allocation of restricted memory pools * Added OP-TEE ABI both with and without FF-A for dynamic restricted memory * Added support for FF-A with FFA_LEND Changes since the V1 RFC: * Based on v6.11 * Complete rewrite, replacing the restricted heap with TEE_IOC_RSTMEM_ALLOC Changes since Olivier's post [2]: * Based on Yong Wu's post [1] where much of dma-buf handling is done in the generic restricted heap * Simplifications and cleanup * New commit message for "dma-buf: heaps: add Linaro restricted dmabuf heap support" * Replaced the word "secure" with "restricted" where applicable Jens Wiklander (6): tee: add restricted memory allocation optee: account for direction while converting parameters optee: sync secure world ABI headers optee: support restricted memory allocation optee: FF-A: dynamic restricted memory allocation optee: smc abi: dynamic restricted memory allocation drivers/tee/Makefile | 1 + drivers/tee/optee/Makefile | 1 + drivers/tee/optee/call.c | 10 +- drivers/tee/optee/core.c | 1 + drivers/tee/optee/ffa_abi.c | 178 +++++++++++++- drivers/tee/optee/optee_ffa.h | 27 ++- drivers/tee/optee/optee_msg.h | 65 ++++- drivers/tee/optee/optee_private.h | 75 ++++-- drivers/tee/optee/optee_smc.h | 71 +++++- drivers/tee/optee/rpc.c | 31 ++- drivers/tee/optee/rstmem.c | 388 ++++++++++++++++++++++++++++++ drivers/tee/optee/smc_abi.c | 213 ++++++++++++++-- drivers/tee/tee_core.c | 38 ++- drivers/tee/tee_private.h | 2 + drivers/tee/tee_rstmem.c | 201 ++++++++++++++++ drivers/tee/tee_shm.c | 2 + drivers/tee/tee_shm_pool.c | 69 +++++- include/linux/tee_core.h | 15 ++ include/linux/tee_drv.h | 2 + include/uapi/linux/tee.h | 44 +++- 20 files changed, 1358 insertions(+), 76 deletions(-) create mode 100644 drivers/tee/optee/rstmem.c create mode 100644 drivers/tee/tee_rstmem.c base-commit: fac04efc5c793dccbd07e2d59af9f90b7fc0dca4 -- 2.43.0

2 weeks, 1 day

10
42
0 0

[PATCH v2 0/8] Trusted Execution Environment (TEE) driver for Qualcomm TEE (QTEE)

by Amirreza Zarrabi

This patch series 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. Clients can invoke these operations on objects, which can generate results, including other objects. For example, an object can load a TA and return another object that represents the loaded TA, allowing access to its services. 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. Note: This patch series focuses on QTEE objects and userspace services. Linux already provides a TEE subsystem, which is described in [1]. The tee subsystem provides a generic ioctl interface, TEE_IOC_INVOKE, which can be used by userspace to talk to a TEE backend driver. We extend the Linux 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. The details of QTEE Transport Message to communicate with QTEE is available in [PATCH 10/10] Documentation: tee: Add Qualcomm TEE driver. You can run basic tests with following steps: git clone https://github.com/quic/quic-teec.git cd quic-teec mkdir build cmake .. -DCMAKE_TOOLCHAIN_FILE=CMakeToolchain.txt -DBUILD_UNITTEST=ON https://github.com/quic/quic-teec/blob/main/README.md lists dependancies needed to build the above. This series has been tested for basic QTEE object invocations and callback requests, including loading a TA and requesting services form the TA. [1] https://www.kernel.org/doc/Documentation/tee.txt Signed-off-by: Amirreza Zarrabi <quic_azarrabi(a)quicinc.com> --- Changes in v2: - Clean up commit messages and comments. - Use better names such as ubuf instead of membuf or QCOMTEE prefix instead of QCOM_TEE, or names that are more consistent with other TEE-backend drivers such as qcomtee_context_data instead of qcom_tee_context. - Drop the DTS patch and instantiate the device from the scm driver. - Use a single structure for all driver's internal states. - Drop srcu primitives and use the existing mutex for synchronization between the supplicant and QTEE. - Directly use tee_context to track the lifetime of qcomtee_context_data. - Add close_context() to be called when the user closes the tee_context. - Link to v1: https://lore.kernel.org/r/20241202-qcom-tee-using-tee-ss-without-mem-obj-v1… Changes in v1: - It is a complete rewrite to utilize the TEE subsystem. - Link to RFC: https://lore.kernel.org/all/20240702-qcom-tee-object-and-ioctls-v1-0-633c3d… --- Amirreza Zarrabi (8): tee: allow a driver to allocate a tee_device without a pool tee: add close_context to TEE driver operation tee: add TEE_IOCTL_PARAM_ATTR_TYPE_UBUF tee: add TEE_IOCTL_PARAM_ATTR_TYPE_OBJREF firmware: qcom: scm: add support for object invocation tee: add Qualcomm TEE driver qcomtee: add primordial object Documentation: tee: Add Qualcomm TEE driver Documentation/tee/index.rst | 1 + Documentation/tee/qtee.rst | 150 ++++++ drivers/firmware/qcom/qcom_scm.c | 128 ++++++ drivers/firmware/qcom/qcom_scm.h | 7 + drivers/tee/Kconfig | 1 + drivers/tee/Makefile | 1 + drivers/tee/qcomtee/Kconfig | 10 + drivers/tee/qcomtee/Makefile | 10 + drivers/tee/qcomtee/async.c | 160 +++++++ drivers/tee/qcomtee/call.c | 741 ++++++++++++++++++++++++++++++ drivers/tee/qcomtee/core.c | 810 +++++++++++++++++++++++++++++++++ drivers/tee/qcomtee/primordial_obj.c | 65 +++ drivers/tee/qcomtee/qcom_scm.c | 36 ++ drivers/tee/qcomtee/qcomtee_msg.h | 234 ++++++++++ drivers/tee/qcomtee/qcomtee_private.h | 226 +++++++++ drivers/tee/qcomtee/release.c | 59 +++ drivers/tee/qcomtee/shm.c | 102 +++++ drivers/tee/qcomtee/user_obj.c | 712 +++++++++++++++++++++++++++++ drivers/tee/tee_core.c | 121 ++++- drivers/tee/tee_private.h | 6 - include/linux/firmware/qcom/qcom_scm.h | 27 ++ include/linux/firmware/qcom/qcom_tee.h | 286 ++++++++++++ include/linux/tee_core.h | 15 +- include/linux/tee_drv.h | 18 + include/uapi/linux/tee.h | 54 ++- 25 files changed, 3964 insertions(+), 16 deletions(-) --- base-commit: dab2734f8e9ecba609d66d1dd087a392a7774c04 change-id: 20241202-qcom-tee-using-tee-ss-without-mem-obj-362c66340527 Best regards, -- Amirreza Zarrabi <quic_azarrabi(a)quicinc.com>

4 weeks, 1 day

5
24
0 0

2025

2024

2023

2022

2021

2020

OP-TEE March 2025