- OP-TEE - lists.trustedfirmware.org

[PATCH v4 0/2] tee: optee: Fixes for supplicant dependent enumeration

by Sumit Garg

Currently supplicant dependent optee device enumeration only registers devices whenever tee-supplicant is invoked for the first time. But it forgets to remove devices when tee-supplicant daemon stops running and closes its context gracefully. This leads to following error for fTPM driver during reboot/shutdown: [ 73.466791] tpm tpm0: ftpm_tee_tpm_op_send: SUBMIT_COMMAND invoke error: 0xffff3024 Fix this by adding an attribute for supplicant dependent devices so that the user-space service can detect and detach supplicant devices before closing the supplicant: $ for dev in /sys/bus/tee/devices/*; do if [[ -f "$dev/need_supplicant" && -f "$dev/driver/unbind" ]]; \ then echo $(basename "$dev") > $dev/driver/unbind; fi done While at it use the global system workqueue for OP-TEE bus scanning work rather than our own custom one. Changes in v4: - Changing the device name would be an ABI break, rather switch to additional device attribute: "need_supplicant" to distinguish for ABI compatibility. - Dropped tested-by for patch #1, I would encourage folks to retest this. Changes in v3: - Split patch into 2 separate ones, one for supplicant fix and other for the workqueue. Changes in v2: - Use device names to separate out tee-supplicant dependent devices via this patch. - Since user-space service is aware about tee-supplicant lifespan, so allow the user-space service to unbind tee-supplicant dependent devices before killing the supplicant. Following command has to be added to the tee-supplicant service file. $ for dev in /sys/bus/tee/devices/*; do if [[ "$dev" == *"optee-ta-supp-"* ]]; \ then echo $(basename "$dev") > $dev/driver/unbind; fi done Sumit Garg (2): tee: optee: Fix supplicant based device enumeration tee: optee: Remove redundant custom workqueue .../ABI/testing/sysfs-bus-optee-devices | 9 +++++++++ drivers/tee/optee/core.c | 13 ++----------- drivers/tee/optee/device.c | 17 +++++++++++++++-- drivers/tee/optee/optee_private.h | 2 -- 4 files changed, 26 insertions(+), 15 deletions(-) -- 2.34.1

2 years, 2 months

4
7
0 0

[GIT PULL] OP-TEE fix for 6.7

by Jens Wiklander

Hello arm-soc maintainers, Please pull this OP-TEE driver fix allowing supplicant dependent devices to be detached by user-space before the supplicant service is shut down. Thanks, Jens The following changes since commit ffc253263a1375a65fa6c9f62a893e9767fbebfa: Linux 6.6 (2023-10-29 16:31:08 -1000) are available in the Git repository at: git://git.linaro.org:/people/jens.wiklander/linux-tee.git tags/optee-supplicant-fix-for-v6.7 for you to fetch changes up to 7269cba53d906cf257c139d3b3a53ad272176bca: tee: optee: Fix supplicant based device enumeration (2023-11-03 09:27:20 +0100) ---------------------------------------------------------------- OP-TEE fix for supplicant based device enumeration Adds a sysfs attribute for devices depending on supplicant services so that the user-space service can detect and detach those devices before closing the supplicant ---------------------------------------------------------------- Sumit Garg (1): tee: optee: Fix supplicant based device enumeration Documentation/ABI/testing/sysfs-bus-optee-devices | 9 +++++++++ drivers/tee/optee/device.c | 17 +++++++++++++++-- 2 files changed, 24 insertions(+), 2 deletions(-)

2 years, 2 months

1
0
0 0

Is it possible to sign a TA twice?

by Jan Claußen

I am currently trying to sing a few TAs using the Yocto environment, namely The three in-tree TAs shipped with optee-os oemcrypto needed for widevine For some reason I can't sign oemcrypto successfully using the offline singing method described in the documentation. I could however successfully exchange the default_ta.pem successfully to accomplish the above. optee-os is then built with the exchanged default private key and the oemcrypto recipe pulls this key as dependency. This is not optimal though, since we want to use an HSM for offline signing to increase security. I am therefore suspecting that oemcrypto is somehow signed differently or that that the stripped.elf is somehow different. From what I have read, it should not matter though what you sign you TA with during the build. You can always create the digest, sign and stitch everything back together. For some reason this does not work. If I sideload the oemcrypto TA that was built by exchanging the default_ta.pem file, everything works again. Do you have an idea what is happening here?

2 years, 2 months

1
0
0 0

[PATCH v2 0/2] OP-TEE kernel private shared memory optimizations

by Jens Wiklander

Hi, This patch set optimizes OP-TEE driver private shared memory allocated as dynamic shared memory (not from the static shared memory pool). The first patch handles kernel private RPC allocatations larger than one page and the second changes from alloc_pages_exact() instead of alloc_pages() for more efficient memory usage. v1->v2: * Split into two patches as requested Jens Wiklander (2): optee: add page list to kernel private shared memory optee: allocate shared memory with alloc_pages_exact() drivers/tee/optee/core.c | 59 +++++++++++++++++++++++++------------ drivers/tee/optee/smc_abi.c | 45 +++++++++++++--------------- 2 files changed, 61 insertions(+), 43 deletions(-) base-commit: 05d3ef8bba77c1b5f98d941d8b2d4aeab8118ef1 -- 2.34.1

2 years, 2 months

2
4
0 0

Does OP TEE support golang & JAVA TA?

by Alex Wang

We are considering to provide professional (data security) service for TA, I think that our service software should be TA because it touches sensitive plain text, and our software are in golang & JAVA. Does OP TEE support golang & JAVA TA? If not, any idea of how to make it? Best Regards [defaultAvatar.png] Alex alex(a)surcloud.net References Visible links: Hidden links: 2. https://maas.mail.163.com/dashi-web-extend/html/proSignature.html?ftlId=1&n…

2 years, 2 months

1
0
0 0

[PATCH v12 0/4] tee: introduce TEE system sssion

by Etienne Carriere

This series introduces TEE system sessions for TEE service sessions that require TEE to provision resources to prevent deadlock when clients call the TEE. This deadlock situation can happen when a TEE service is used by low level system resources as for example when Linux kernel uses SCMI service embedded in TEE for clock, reset, regulator, etc... controls. This case is detailled in patch 2/4: > This feature is needed to prevent a system deadlock when several TEE > client applications invoke TEE, consuming all TEE thread contexts > available in the secure world. The deadlock can happen in the OP-TEE > driver for example if all these TEE threads issue an RPC call from TEE > to Linux OS to access an eMMC RPMB partition (TEE secure storage) which > device clock or regulator controller is accessed through an OP-TEE SCMI > services. In that case, Linux SCMI driver must reach OP-TEE SCMI > service without waiting until one of the consumed TEE threads is freed. Etienne Carriere (4): tee: optee: system call property tee: system session tee: optee: support tracking system threads firmware: arm_scmi: optee: use optee system invocation drivers/firmware/arm_scmi/optee.c | 4 + drivers/tee/optee/call.c | 130 ++++++++++++++++++++++++++++-- drivers/tee/optee/core.c | 5 +- drivers/tee/optee/ffa_abi.c | 14 ++-- drivers/tee/optee/optee_private.h | 29 ++++++- drivers/tee/optee/smc_abi.c | 32 +++++--- drivers/tee/tee_core.c | 8 ++ include/linux/tee_drv.h | 16 ++++ 8 files changed, 211 insertions(+), 27 deletions(-) --- Changes since v11: - Fixed inline description comments in patch 1/3 and 3/4, other patches are unchanged. Changes since v10: - Changes patch 3/4, other are unchanged. -- 2.25.1

2 years, 2 months

2
5
0 0

[PATCH] optee: add missing description of RPC argument reference

by Etienne Carriere

Adds missing inline description comment for RPC optional arguments reference. Reported-by: kernel test robot <lkp(a)intel.com> Closes: https://lore.kernel.org/lkml/202310192021.fvb6JDOY-lkp@intel.com/ Signed-off-by: Etienne Carriere <etienne.carriere(a)foss.st.com> --- drivers/tee/optee/smc_abi.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/tee/optee/smc_abi.c b/drivers/tee/optee/smc_abi.c index d5b28fd35d66..67bfa25d6302 100644 --- a/drivers/tee/optee/smc_abi.c +++ b/drivers/tee/optee/smc_abi.c @@ -806,6 +806,7 @@ static void handle_rpc_func_cmd(struct tee_context *ctx, struct optee *optee, /** * optee_handle_rpc() - handle RPC from secure world * @ctx: context doing the RPC + * @rpc_arg: pointer to RPC arguments if any, or NULL if none * @param: value of registers for the RPC * @call_ctx: call context. Preserved during one OP-TEE invocation * -- 2.25.1

2 years, 2 months

3
2
0 0

[PATCH 0/2] OP-TEE FF-A notifications

by Jens Wiklander

Hi all, This patchset adds support for using FF-A notifications as a delivery mechanism of asynchronous notifications from OP-TEE running in the secure world. Support for asynchronous notifications via the SMC ABI was added in [1], here we add the counterpart needed when using the the FF-A ABI. Support for FF-A notifications is added with [2] and this patch set is based on Sudeeps tree at [3]. [1] https://lore.kernel.org/lkml/20211103090255.998070-1-jens.wiklander@linaro.… [2] https://lore.kernel.org/linux-arm-kernel/20231005-ffa_v1-1_notif-v4-0-cddd3… [3] https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git/tag/… commit bcefd1bf63b1 ("firmware: arm_ffa: Upgrade the driver version to v1.1") Thanks, Jens Jens Wiklander (2): optee: provide optee_do_bottom_half() as a common function optee: ffa_abi: add asynchronous notifications drivers/tee/optee/call.c | 31 ++++++++++- drivers/tee/optee/ffa_abi.c | 91 ++++++++++++++++++++++++++++++- drivers/tee/optee/optee_ffa.h | 28 ++++++++-- drivers/tee/optee/optee_private.h | 9 ++- drivers/tee/optee/smc_abi.c | 36 ++---------- 5 files changed, 153 insertions(+), 42 deletions(-) base-commit: bcefd1bf63b1ec9bb08067021cf47f0fad96f395 -- 2.34.1

2 years, 2 months

3
15
0 0

[PATCH v10 0/5] introduce tee-based EFI Runtime Variable Service

by Masahisa Kojima

This series introduces the tee-based EFI Runtime Variable Service. The eMMC device is typically owned by the non-secure world(linux in this case). There is an existing solution utilizing eMMC RPMB partition for EFI Variables, it is implemented by interacting with OP-TEE, StandaloneMM(as EFI Variable Service Pseudo TA), eMMC driver and tee-supplicant. The last piece is the tee-based variable access driver to interact with OP-TEE and StandaloneMM. This driver depends on the tee-supplicant. When the tee-supplicant stops, this driver needs to be unbound from user-space script or tool, relevant patch is posted[1]. [1] https://lore.kernel.org/all/20231102073056.174480-2-sumit.garg@linaro.org/ Changelog: v9 -> v10 - patch #6 "tee: optee: restore efivars ops when tee-supplicant stops" is removed v8 -> v9 - patch #6 "tee: optee: restore efivars ops when tee-supplicant stops" is newly added - remove !EFI_VARS_PSTORE Kconfig dependency, we have added a non-blocking set_variable and it just returns EFI_UNSUPPORTED. - remove obvious comments v7 -> v8 Only patch #3 "efi: Add tee-based EFI variable driver" is updated. - fix typos - refactor error handling, direct return if applicable - use devm_add_action_or_reset() for closing of tee context/session - remove obvious comment v6 -> v7 Patch #1-#4 are not updated. Patch #5 is added into this series, original patch is here: https://lore.kernel.org/all/20230609094532.562934-1-ilias.apalodimas@linaro… There are two issues in the v6 series and v7 series addresses those. 1) efivar ops is not restored when the tee-supplicant daemon terminates. -> As the following patch says, user must remove the device before terminating tee-supplicant daemon. https://lore.kernel.org/all/20230728134832.326467-1-sumit.garg@linaro.org/ 2) cause panic when someone remounts the efivarfs as RW even if SetVariable is not supported -> The fifth patch addresses this issue. "[PATCH v7 5/5] efivarfs: force RO when remounting if SetVariable is not supported" v5 -> v6 - new patch #4 is added in this series, #1-#3 patches are unchanged. automatically update super block flag when the efivarops support SetVariable runtime service, so that user does not need to manually remount the efivarfs as RW. v4 -> v5 - rebase to efi-next based on v6.4-rc1 - set generic_ops.query_variable_info, it works as expected as follows. $ df -h /sys/firmware/efi/efivars/ Filesystem Size Used Avail Use% Mounted on efivarfs 16K 1.3K 15K 8% /sys/firmware/efi/efivars v3 -> v4: - replace the reference from EDK2 to PI Specification - remove EDK2 source code reference comments - prepare nonblocking variant of set_variable, it just returns EFI_UNSUPPORTED - remove redundant buffer size check - argument name change in mm_communicate - function interface changes in setup_mm_hdr to remove (void **) cast v2 -> v3: - add CONFIG_EFI dependency to TEE_STMM_EFI - add missing return code check for tee_client_invoke_func() - directly call efivars_register/unregister from tee_stmm_efi.c rfc v1 -> v2: - split patch into three patches, one for drivers/tee, one for include/linux/efi.h, and one for the driver/firmware/efi/stmm - context/session management into probe() and remove() same as other tee client driver - StMM variable driver is moved from driver/tee/optee to driver/firmware/efi - use "tee" prefix instead of "optee" in driver/firmware/efi/stmm/tee_stmm_efi.c, this file does not contain op-tee specific code, abstracted by tee layer and StMM variable driver will work on other tee implementation. - PTA_STMM_CMD_COMMUNICATE -> PTA_STMM_CMD_COMMUNICATE - implement query_variable_store() but currently not used - no use of TEEC_SUCCESS, it is defined in driver/tee/optee/optee_private.h. Other tee client drivers use 0 instead of using TEEC_SUCCESS - remove TEEC_ERROR_EXCESS_DATA status, it is referred just to output error message Ilias Apalodimas (1): efivarfs: force RO when remounting if SetVariable is not supported Masahisa Kojima (4): efi: expose efivar generic ops register function efi: Add EFI_ACCESS_DENIED status code efi: Add tee-based EFI variable driver efivarfs: automatically update super block flag drivers/firmware/efi/Kconfig | 15 + drivers/firmware/efi/Makefile | 1 + drivers/firmware/efi/efi.c | 18 + drivers/firmware/efi/stmm/mm_communication.h | 236 +++++++ drivers/firmware/efi/stmm/tee_stmm_efi.c | 616 +++++++++++++++++++ drivers/firmware/efi/vars.c | 8 + fs/efivarfs/super.c | 45 ++ include/linux/efi.h | 12 + 8 files changed, 951 insertions(+) create mode 100644 drivers/firmware/efi/stmm/mm_communication.h create mode 100644 drivers/firmware/efi/stmm/tee_stmm_efi.c base-commit: 5329aa5101f73c451bcd48deaf3f296685849d9c -- 2.39.2

2 years, 2 months

2
7
0 0

HELP for OPTEE Application crash when wakeup from Hiberation

by XiaoXia

Hello All: I have new project for developping TEE in notebook. the system needs to support S4 (Hiberation/STD) in order to reduce the power consume. To make the design simplest, I follow the regular suspend flow as below: 1. the kernel implement suspend flow to freeze thread and store data in swap paritition. then enter into S3 mode 2. system wakeups by pressing poweron event, and boot into kernel as normal. and the TEE OS and Trusted firmware will initialize like in normal boot. Once kernel recover all context, I try to issue CA again, and it prompts the below error message. I know that the context of TEE-OS and TEE driver does not match new after system recovery... I wonder to know if there is way to cleanup TEE driver before entering into S4 to make CA work after wakeup . Thank you for your help . Best Regareds, Vincent Cui

2 years, 2 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

OP-TEE