- OP-TEE - lists.trustedfirmware.org

[PATCH v13 0/7] Introduction of a remoteproc tee to load signed firmware

by Arnaud Pouliquen

Main updates from version V12[1]: Fix warning build by fixing the inline declaration in remoteproc_tee.h (when CONFIG_REMOTEPROC_TEE is not set). Reported-by: kernel test robot <lkp(a)intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202410262040.PWNrKv2Q-lkp@intel.com/ Main updates from version V11[2]: - rename structures, functions, and variables from "tee_rproc_xxx" to "rproc_tee_xxx", - update rproc_tee_register to return an error instead of "struct rproc_tee *" pointer [1] https://lore.kernel.org/lkml/20241025205924.2087768-1-arnaud.pouliquen@foss… [2] https://lore.kernel.org/lkml/ZxZ4cBilIlpf3IPw@p14s/T/ Tested-on: commit 42f7652d3eb5 ("Linux 6.12-rc4") 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 (7): remoteproc: core: Introduce rproc_pa_to_va helper remoteproc: Add TEE support remoteproc: core: Refactor resource table cleanup into rproc_release_fw 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 | 72 ++- drivers/remoteproc/remoteproc_tee.c | 510 ++++++++++++++++++ drivers/remoteproc/stm32_rproc.c | 139 +++-- include/linux/remoteproc.h | 8 + include/linux/remoteproc_tee.h | 105 ++++ 8 files changed, 848 insertions(+), 55 deletions(-) create mode 100644 drivers/remoteproc/remoteproc_tee.c create mode 100644 include/linux/remoteproc_tee.h base-commit: 42f7652d3eb527d03665b09edac47f85fb600924 -- 2.25.1

1 year

3
18
0 0

Dynamic shared memory

by Patryk

Hello, I've been currently looking at the possibility of storing u-boot environment variables in RPMB and I've stumbled upon this article: https://www.linaro.org/blog/protected-uefi-variables-with-u-boot/ which briefly describes what needs to be done in order to achieve this. Unfortunately there is no comment section in this article so I cannot ask the author so I decided to try here. The article mentions that for that purpose, my board should support dynamic shared memory, therefore the OP-TEE port for my board should register that memory in platform main using the "register_ddr" function. For my platform (ls1028ardb) I do not see anything like this, thus I assume it's not supported. However, I'm wondering - is it my platform's hardware limitation or missing software implementation? Making this question more generic - does dynamic shared memory depend on hardware, meaning that there is no way to register dynamic shared memory if hardware does not support some particular features? I would be grateful for some hints. Best regards Patryk

1 year

2
1
0 0

tee-supplicant priority

by Matteo Facchinetti

Hi, I have a doubt about the correct priority that tee-supplicant should have in the system. In detail, we have 2 user-space applications (user-pkcs11-0, user-pkcs11-1) that use the same PKCS11 services from OPTEE-OS (access to RPDB partition for private key). For project reason we use the following nice priority values: user-pkcs11-0, nice=-5 user-pkcs11-1, nice=-10 .... tee-supplcant, nice=0 ... a lot of other services with nice=0 ... Unfortunately, in some strange case when CPU is overload (booting).... appear a strange problem in user-pkcs11-1: occasionally the time for the certificate's signature check explode to 400ms. Due to the problem to replicate this defect, I have try to investigate in theory if could be verify a starvation/race-condition between tee-supplicant and user-pkcs11-1 or other-services. In this scenario, what is the correct priority value that tee-supplicant should have? I suspect that we should change the priority of tee-supplcant = user-pkcs11-1 = -10 Is it make sense for you, or maybe better to search the problem from an other side :-) ? Thanks in advance for your attention BR Matteo Facchinetti

1 year

2
1
0 0

optee-based efi runtime variable service on TI j784s4 platforms

by Enric Balletbo i Serra

Hi all, I'm looking for any advice/clue to help me to progress on enabling TEE-base EFI Runtime Variable Service on TI a j784s4 platforms. I basically followed the steps described in u-boot documentation [1], I enabled some debugging messages but I think I'm at the point that the problem might be in the StandaloneMM application, and I'm not sure how to debug it. What I see is that when I run the tee-supplicant daemon, it looks like the tee_client_open_session() call loops forever and the tee_stmm_efi driver never ends to probe. With debug enabled I got the following messages. # tee-supplicant D/TC:? 0 tee_ta_init_session_with_context:557 Re-open trusted service 7011a688-ddde-4053-a5a9-7b3c4ddf13b8 D/TC:? 0 load_stmm:297 stmm load address 0x40004000 D/TC:? 0 spm_handle_scall:859 Received FFA version D/TC:? 0 spm_handle_scall:867 Received FFA direct request D/TC:? 0 spm_handle_scall:867 Received FFA direct request D/TC:? 0 spm_handle_scall:867 Received FFA direct request D/TC:? 0 spm_handle_scall:867 Received FFA direct request D/TC:? 0 spm_handle_scall:867 Received FFA direct request D/TC:? 0 spm_handle_scall:867 Received FFA direct request D/TC:? 0 spm_handle_scall:867 Received FFA direct request D/TC:? 0 spm_handle_scall:867 Received FFA direct request D/TC:? 0 spm_handle_scall:867 Received FFA direct request D/TC:? 0 spm_handle_scall:867 Received FFA direct request D/TC:? 0 spm_handle_scall:867 Received FFA direct request D/TC:? 0 spm_handle_scall:867 Received FFA direct request D/TC:? 0 spm_handle_scall:867 Received FFA direct request D/TC:? 0 spm_handle_scall:867 Received FFA direct request D/TC:? 0 spm_handle_scall:867 Received FFA direct request D/TC:? 0 spm_handle_scall:867 Received FFA direct request And tracing the function calls gives me that: tee_stmm_efi_probe() { tee_client_open_context() { optee_get_version() { tee_get_drvdata(); (ret=0xffff000002e55800) } (ret=0xd) tee_ctx_match(); (ret=0x1) optee_smc_open() { tee_get_drvdata(); (ret=0xffff000002e55800) optee_open() { tee_get_drvdata(); (ret=0xffff000002e55800) } (ret=0x0) } (ret=0x0) } (ret=0xffff000004e71c80) tee_client_open_session() { optee_open_session() { tee_get_drvdata(); (ret=0xffff000002e55800) optee_get_msg_arg() { tee_get_drvdata(); (ret=0xffff000002e55800) tee_shm_get_va(); (ret=0xffff000002909000) } (ret=0xffff000002909000) tee_session_calc_client_uuid(); (ret=0x0) optee_to_msg_param(); (ret=0x0) optee_smc_do_call_with_arg() { tee_get_drvdata(); (ret=0xffff000002e55800) tee_shm_get_va(); (ret=0xffff000002909000) tee_shm_get_va(); (ret=0xffff000002909060) optee_cq_wait_init(); (ret=0xffff000002e55910) optee_smccc_smc(); (ret=0xffff0004) tee_get_drvdata(); (ret=0xffff000002e55800) optee_smccc_smc(); (ret=0xffff0004) tee_get_drvdata(); (ret=0xffff000002e55800) optee_smccc_smc(); (ret=0xffff0004) tee_get_drvdata(); (ret=0xffff000002e55800) optee_smccc_smc(); (ret=0xffff0004) tee_get_drvdata(); (ret=0xffff000002e55800) optee_smccc_smc(); (ret=0xffff0004) ... continues sending this forever ... ... Hit ^C to stop recording ... tee_get_drvdata(); (ret=0xffff000002e55800) optee_smccc_smc() { [1] https://docs.u-boot.org/en/latest/develop/uefi/uefi.html#using-op-tee-for-e… Thanks in advance, Enric

1 year, 1 month

2
17
0 0

Linux user-level implementation of OP-TEE

by Jork Loeser (he/him)

Hello, I am Jork Loeser from Microsoft, and we are looking into providing the OP-TEE internal core API from Linux user-level, as well as hosting a derivative of OP-TEE OS in Linux user-level. Can you say is something like this has been attempted in the past, and perhaps provide pointers? How interesting would it be for OP-TEE to have such an implementation - e.g., for early/rapid-development purposes? Best, Jork

1 year, 1 month

2
2
0 0

[PATCH v12 0/7] Introduction of a remoteproc tee to load signed firmware

by Arnaud Pouliquen

Main updates from version V11[1]: - rename structures, functions, and variables from "tee_rproc_xxx" to "rproc_tee_xxx", - update rproc_tee_register to return an error instead of "struct rproc_tee *" pointer [1] https://lore.kernel.org/lkml/ZxZ4cBilIlpf3IPw@p14s/T/ Tested-on: 42f7652d3eb5 ("Linux 6.12-rc4") 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 (7): remoteproc: core: Introduce rproc_pa_to_va helper remoteproc: Add TEE support remoteproc: core: Refactor resource table cleanup into rproc_release_fw 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 | 72 ++- drivers/remoteproc/remoteproc_tee.c | 510 ++++++++++++++++++ drivers/remoteproc/stm32_rproc.c | 139 +++-- include/linux/remoteproc.h | 8 + include/linux/remoteproc_tee.h | 106 ++++ 8 files changed, 849 insertions(+), 55 deletions(-) create mode 100644 drivers/remoteproc/remoteproc_tee.c create mode 100644 include/linux/remoteproc_tee.h base-commit: 42f7652d3eb527d03665b09edac47f85fb600924 -- 2.25.1

1 year, 1 month

2
10
0 0

[PATCH v11 0/7] Introduction of a remoteproc tee to load signed firmware

by Arnaud Pouliquen

Main updates from version V10[1]: - remove "select REMOTEPROC_TEE" in STM32_RPROC config to fix kernel robot To keep history of the updates I have kept in each patches the description of the updates versus the V9[2] revision. Main updates from version V9[2]: - Introduce release_fw remoteproc ops to avoid direct call of tee_rproc_release_fw() in remoteproc_core.c: - allow to remove link between remoteproc and remoteproc_tee - allow to build the remoteproc_tee as a module [1] https://lore.kernel.org/linux-arm-kernel/ZwVATlRbo0OdRLbj@p14s/T/ [2] https://lore.kernel.org/linux-arm-kernel/ZuMIEp4cVrp1hWa7@p14s/T/ Tested-on: commit 9852d85ec9d4 ("Linux 6.12-rc1") 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 (7): remoteproc: core: Introduce rproc_pa_to_va helper remoteproc: Add TEE support remoteproc: core: Refactor resource table cleanup into rproc_release_fw 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 | 72 ++- drivers/remoteproc/remoteproc_tee.c | 506 ++++++++++++++++++ drivers/remoteproc/stm32_rproc.c | 145 +++-- include/linux/remoteproc.h | 8 + include/linux/remoteproc_tee.h | 107 ++++ 8 files changed, 852 insertions(+), 55 deletions(-) create mode 100644 drivers/remoteproc/remoteproc_tee.c create mode 100644 include/linux/remoteproc_tee.h base-commit: 9852d85ec9d492ebef56dc5f229416c925758edc -- 2.25.1

1 year, 1 month

2
10
0 0

Linaro OP-TEE Contribution, LOC, monthly meeting October 22

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 started the Pull Request https://github.com/OP-TEE/optee_os/pull/7054 to import the TA-specific part of fTPM into the OP-TEE git. It appears that MS has filed for patents on fTPM. How does that affect downstream usage? Would it be safer or more convenient for downstream if the fTPM TA was in a separate git instead of the optee_os git? Are there any other topics? Thanks, Jens

1 year, 1 month

1
0
0 0

OP-TEE 4.4.0 has been released

by Jerome Forissier

Hi, I'm pleased to announce that OP-TEE version 4.4.0 is now available. The list of changes can be found in the changelog [1]. A blog post will be published soon on trustedfirmware.org [2]. A big thank you to everyone who participated with contributions and helping out with testing the release [3]. [1] https://github.com/OP-TEE/optee_os/blob/master/CHANGELOG.md [2] https://www.trustedfirmware.org/blog/ [3] https://github.com/OP-TEE/optee_os/commit/8f645256efc0dc66bd5c118778b0b50c4… Regards, -- Jerome

1 year, 1 month

1
0
0 0

[RFC PATCH v2 0/2] TEE subsystem for restricted dma-buf allocations

by Jens Wiklander

Hi, This patch set allocates the restricted DMA-bufs via the TEE subsystem. This a complete rewrite compared to the previous patch set [1], and other earlier proposals [2] and [3] with a separate restricted heap. The TEE subsystem handles the DMA-buf allocations since it is the TEE (OP-TEE, AMD-TEE, TS-TEE, or a future QTEE) 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 new IOCTL reaches the backend TEE driver, allowing it to choose how to allocate the restricted physical memory. TEE_IOC_RSTMEM_ALLOC is quite similar to TEE_IOC_SHM_ALLOC so it's tempting to extend TEE_IOC_SHM_ALLOC with two new flags TEE_IOC_SHM_FLAG_SECURE_VIDEO and TEE_IOC_SHM_FLAG_SECURE_TRUSTED_UI for the same feature. However, it might be a bit confusing since TEE_IOC_SHM_ALLOC only returns an anonymous file descriptor, but TEE_IOC_SHM_FLAG_SECURE_VIDEO and TEE_IOC_SHM_FLAG_SECURE_TRUSTED_UI would return a DMA-buf file descriptor instead. What do others think? 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-v2 repo sync -j8 cd build make toolchains -j4 make all -j$(nproc) make run-only # login and at the prompt: xtest --sdp-basic 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 [1] https://lore.kernel.org/lkml/20240830070351.2855919-1-jens.wiklander@linaro… [2] https://lore.kernel.org/dri-devel/20240515112308.10171-1-yong.wu@mediatek.c… [3] https://lore.kernel.org/lkml/20220805135330.970-1-olivier.masse@nxp.com/ 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 (2): tee: add restricted memory allocation optee: support restricted memory allocation drivers/tee/Makefile | 1 + drivers/tee/optee/core.c | 21 ++++ drivers/tee/optee/optee_private.h | 6 + drivers/tee/optee/optee_smc.h | 35 ++++++ drivers/tee/optee/smc_abi.c | 45 ++++++- drivers/tee/tee_core.c | 33 ++++- drivers/tee/tee_private.h | 2 + drivers/tee/tee_rstmem.c | 200 ++++++++++++++++++++++++++++++ drivers/tee/tee_shm.c | 2 + drivers/tee/tee_shm_pool.c | 69 ++++++++++- include/linux/tee_core.h | 6 + include/linux/tee_drv.h | 9 ++ include/uapi/linux/tee.h | 33 ++++- 13 files changed, 455 insertions(+), 7 deletions(-) create mode 100644 drivers/tee/tee_rstmem.c -- 2.43.0

1 year, 1 month

2
6
0 0

2025

2024

2023

2022

2021

2020

OP-TEE