- OP-TEE - lists.trustedfirmware.org

Linaro OP-TEE Contribution, LOC, monthly meeting August 26

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/ - Thomas Stauffer started an interesting thread [2] on RCU stalls - The Secure Data Path patchset [1] is at v11 Are there any other topics? Cheers, Jens [1] https://lore.kernel.org/op-tee/aKa_132R8SSZHywJ@sumit-X1/T/#mc88abedd1ad977… [2] https://lore.kernel.org/op-tee/20250813060339.2977604-1-jens.wiklander@lina…

1 year

1
0
0 0

rcu_preempt detected stalls on CPUs/tasks

by Stauffer Thomas MTANA

Hi, I'm running OP-TEE 4.5 with PKCS11TA and ATF lts-v2.12.4 on an iMX8MP. When I create new rsa 4096 bit keypair with OP-TEE, I often get rcu_preempt detected stalls on CPUs/tasks from Linux 6.6.90 (mainline) Also PID 0 is sometimes blocked for more than 30 seconds. When I create a RT task with even higher priority, this process is also blocked up to 2 seconds. For a test I disabled saving/restoring the NS timer register in ATF (arm-trusted-firmware/lib/el3_runtime/aarch64/context_mgmt.c), this seems to get completely rid of the problem. Neither creating nor signing leads to any issue anymore. This hack may lead to other problems I do not fully understand yet. I "believe" that at least since ARMv8, the CPU have their own timers for secure/non-secure world, but I would assume that ATF implements this correctly already. Maybe I'm completely wrong here (assuming that it cannot be I'm the first person having this issue on this platform). Hint in any direction would be helpful. Regards Thomas

1 year

5
10
1 0

[GIT PULL] OP-TEE typo fix for v6.17

by Jens Wiklander

Hello arm-soc maintainers, Please pull this small patch fixing a recently introduced typo in the OP-TEE driver. Thanks, Jens The following changes since commit 8f5ae30d69d7543eee0d70083daf4de8fe15d585: Linux 6.17-rc1 (2025-08-10 19:41:16 +0300) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jenswi/linux-tee.git tags/optee-typo-fix-for-v6.17 for you to fetch changes up to 75dbd4304afe574fcfc4118a5b78776a9f48fdc4: tee: optee: ffa: fix a typo of "optee_ffa_api_is_compatible" (2025-08-18 15:05:49 +0200) ---------------------------------------------------------------- OP-TEE driver fix for v6.17 Fixing a typo in a function name. ---------------------------------------------------------------- Sungbae Yoo (1): tee: optee: ffa: fix a typo of "optee_ffa_api_is_compatible" drivers/tee/optee/ffa_abi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)

1 year

1
0
0 0

[GIT PULL] TEE fixes for v6.17

by Jens Wiklander

Hello arm-soc maintainers Please pull these two small patches fixing a NULL pointer dereference and memory leak in the TEE subsystem. Thanks, Jens The following changes since commit 038d61fd642278bab63ee8ef722c50d10ab01e8f: Linux 6.16 (2025-07-27 14:26:38 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jenswi/linux-tee.git tags/tee-fixes-for-v6.17 for you to fetch changes up to 50a74d0095cd23d2012133e208df45a298868870: tee: fix memory leak in tee_dyn_shm_alloc_helper (2025-08-04 14:28:04 +0200) ---------------------------------------------------------------- TEE fixes for v6.17 - Fixing a memory leak in the error path for tee_dyn_shm_alloc_helper() - Fixing a NULL pointer dereference in tee_shm_put() ---------------------------------------------------------------- Pei Xiao (2): tee: fix NULL pointer dereference in tee_shm_put tee: fix memory leak in tee_dyn_shm_alloc_helper drivers/tee/tee_shm.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-)

1 year

1
0
0 0

[PATCH] tee: optee: ffa: fix a typo of "optee_ffa_api_is_compatible"

by Sungbae Yoo

Fix: commit 4615e5a34b95 ("optee: add FF-A support") Signed-off-by: Sungbae Yoo <sungbaey(a)nvidia.com> diff --git a/drivers/tee/optee/ffa_abi.c b/drivers/tee/optee/ffa_abi.c index f9ef7d94cebd..a963eed70c1d 100644 --- a/drivers/tee/optee/ffa_abi.c +++ b/drivers/tee/optee/ffa_abi.c @@ -657,7 +657,7 @@ static int optee_ffa_do_call_with_arg(struct tee_context *ctx, * with a matching configuration. */ -static bool optee_ffa_api_is_compatbile(struct ffa_device *ffa_dev, +static bool optee_ffa_api_is_compatible(struct ffa_device *ffa_dev, const struct ffa_ops *ops) { const struct ffa_msg_ops *msg_ops = ops->msg_ops; @@ -908,7 +908,7 @@ static int optee_ffa_probe(struct ffa_device *ffa_dev) ffa_ops = ffa_dev->ops; notif_ops = ffa_ops->notifier_ops; - if (!optee_ffa_api_is_compatbile(ffa_dev, ffa_ops)) + if (!optee_ffa_api_is_compatible(ffa_dev, ffa_ops)) return -EINVAL; if (!optee_ffa_exchange_caps(ffa_dev, ffa_ops, &sec_caps, -- 2.34.1

1 year, 1 month

3
6
0 0

BEE support and TA_RAM usage in Op-Tee 3.10.0

by Robert Delien

Hi, We would like to protect trusted application heap memory against cryogenic attacks. We think a good method to achieve this is by employing the Bus Encryption Engine hardware in our i.MX6UL. For testing, I currently configure the BEE in U-Boot, to encrypt the Op-Tee TA_RAM area (0x8e100000-8f9fffff), and make it available unencryptedly at 0x10000000-0x118fffff. TA_RAM_START is set to 0x10000000 and this seems to work, but I have a few questions: 1. Does area TA_RAM_START:TA_RAM_SIZE hold all TA code, stack and heap? 2. Access privileges to 0x10000000-0x118fffff have been set to *Non-Secure User none, Non-Secure Spvr none, Secure User RD + WR, Secure Spvr RD + WR*, but much to my surprise, *Non-Secure User none, Non-Secure Spvr none, Secure User none, Secure Spvr RD + WR* worked equally well. I can provide a memory map if useful, but I'd rather not post that at forehand. If this works well, achieves our goal and the performance penalty is acceptable, we will roll this into an Op-Tee driver. With kind regards, Robert. -- DISCLAIMER De informatie, verzonden in of met dit e-mailbericht, is vertrouwelijk en uitsluitend voor de geadresseerde(n) bestemd. Het gebruik van de informatie in dit bericht, de openbaarmaking, vermenigvuldiging, verspreiding en|of verstrekking daarvan aan derden is niet toegestaan. Gebruik van deze informatie door anderen dan geadresseerde(n) is strikt verboden. Aan deze informatie kunnen geen rechten worden ontleend. U wordt verzocht bij onjuiste adressering de afzender direct te informeren door het bericht te retourneren en het bericht uit uw computersysteem te verwijderen.

1 year, 1 month

2
2
0 0

[PATCH] treewide: Replace scnprintf with sysfs_emit in

by Abhinav Ananthu

Use sysfs_emit() to format sysfs output instead of scnprintf() as recommended by the kernel documentation. Signed-off-by: Abhinav Ananthu <abhinav.ogl(a)gmail.com> --- drivers/tee/optee/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c index c75fddc83576..ce44e3498d37 100644 --- a/drivers/tee/optee/core.c +++ b/drivers/tee/optee/core.c @@ -72,7 +72,7 @@ static ssize_t rpmb_routing_model_show(struct device *dev, else s = "user"; - return scnprintf(buf, PAGE_SIZE, "%s\n", s); + return sysfs_emit(buf, "%s\n", s); } static DEVICE_ATTR_RO(rpmb_routing_model); -- 2.34.1

1 year, 1 month

2
1
0 0

[PATCH] tee: Use SHA-1 library instead of crypto_shash

by Eric Biggers

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(a)kernel.org> --- Note: this patch depends on the SHA-1 library functions that were merged in v6.17-rc1. drivers/tee/Kconfig | 3 +-- drivers/tee/tee_core.c | 55 +++++++----------------------------------- 2 files changed, 10 insertions(+), 48 deletions(-) diff --git a/drivers/tee/Kconfig b/drivers/tee/Kconfig index 61b507c187801..a84767940fbfc 100644 --- a/drivers/tee/Kconfig +++ b/drivers/tee/Kconfig @@ -1,12 +1,11 @@ # SPDX-License-Identifier: GPL-2.0-only # Generic Trusted Execution Environment Configuration menuconfig TEE tristate "Trusted Execution Environment support" depends on HAVE_ARM_SMCCC || COMPILE_TEST || CPU_SUP_AMD - select CRYPTO - select CRYPTO_SHA1 + select CRYPTO_LIB_SHA1 select DMA_SHARED_BUFFER select GENERIC_ALLOCATOR help This implements a generic interface towards a Trusted Execution Environment (TEE). diff --git a/drivers/tee/tee_core.c b/drivers/tee/tee_core.c index acc7998758ad8..d079aeee0690a 100644 --- a/drivers/tee/tee_core.c +++ b/drivers/tee/tee_core.c @@ -12,11 +12,10 @@ #include <linux/module.h> #include <linux/overflow.h> #include <linux/slab.h> #include <linux/tee_core.h> #include <linux/uaccess.h> -#include <crypto/hash.h> #include <crypto/sha1.h> #include "tee_private.h" #define TEE_NUM_DEVICES 32 @@ -140,72 +139,36 @@ static int tee_release(struct inode *inode, struct file *filp) * UUIDv5 is specific in RFC 4122. * * This implements section (for SHA-1): * 4.3. Algorithm for Creating a Name-Based UUID */ -static int uuid_v5(uuid_t *uuid, const uuid_t *ns, const void *name, - size_t size) +static void uuid_v5(uuid_t *uuid, const uuid_t *ns, const void *name, + size_t size) { unsigned char hash[SHA1_DIGEST_SIZE]; - struct crypto_shash *shash = NULL; - struct shash_desc *desc = NULL; - int rc; - - shash = crypto_alloc_shash("sha1", 0, 0); - if (IS_ERR(shash)) { - rc = PTR_ERR(shash); - pr_err("shash(sha1) allocation failed\n"); - return rc; - } - - desc = kzalloc(sizeof(*desc) + crypto_shash_descsize(shash), - GFP_KERNEL); - if (!desc) { - rc = -ENOMEM; - goto out_free_shash; - } - - desc->tfm = shash; + struct sha1_ctx ctx; - rc = crypto_shash_init(desc); - if (rc < 0) - goto out_free_desc; - - rc = crypto_shash_update(desc, (const u8 *)ns, sizeof(*ns)); - if (rc < 0) - goto out_free_desc; - - rc = crypto_shash_update(desc, (const u8 *)name, size); - if (rc < 0) - goto out_free_desc; - - rc = crypto_shash_final(desc, hash); - if (rc < 0) - goto out_free_desc; + sha1_init(&ctx); + sha1_update(&ctx, (const u8 *)ns, sizeof(*ns)); + sha1_update(&ctx, (const u8 *)name, size); + sha1_final(&ctx, hash); memcpy(uuid->b, hash, UUID_SIZE); /* Tag for version 5 */ uuid->b[6] = (hash[6] & 0x0F) | 0x50; uuid->b[8] = (hash[8] & 0x3F) | 0x80; - -out_free_desc: - kfree(desc); - -out_free_shash: - crypto_free_shash(shash); - return rc; } int tee_session_calc_client_uuid(uuid_t *uuid, u32 connection_method, const u8 connection_data[TEE_IOCTL_UUID_LEN]) { gid_t ns_grp = (gid_t)-1; kgid_t grp = INVALID_GID; char *name = NULL; int name_len; - int rc; + int rc = 0; if (connection_method == TEE_IOCTL_LOGIN_PUBLIC || connection_method == TEE_IOCTL_LOGIN_REE_KERNEL) { /* Nil UUID to be passed to TEE environment */ uuid_copy(uuid, &uuid_null); @@ -258,11 +221,11 @@ int tee_session_calc_client_uuid(uuid_t *uuid, u32 connection_method, default: rc = -EINVAL; goto out_free_name; } - rc = uuid_v5(uuid, &tee_client_uuid_ns, name, name_len); + uuid_v5(uuid, &tee_client_uuid_ns, name, name_len); out_free_name: kfree(name); return rc; } base-commit: 0905809b38bda1fa0b206986c44d846e46f13c1d -- 2.50.1

1 year, 1 month

3
2
0 0

Re: optee_ftpm + ms-tpm-20-ref support for RSA key sizes 3072 or 4096 causes a panic

by Olivier Deprez

Hi, I believe the optee mailing is better placed to provide answers. Regards, Olivier. ________________________________ From: Dennis Kong via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 07 August 2025 23:44 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] optee_ftpm + ms-tpm-20-ref support for RSA key sizes 3072 or 4096 causes a panic Dear community: I apologize in advance if this is the incorrect place to solicit for input on an issue I am having when enabling support of RSA key sizes > 2048. The environment is described below: TI AM642-EVM board Debian Bookworm running kernel 6.6.100, tpm_ftpm_tee.ko kernel module Uboot booting from sdcard UEFI partition and rootfs partition optee_os version 4.5.0 , 4.6.0, 4.7.0 (no difference in behaviour) optee_client version 4.5.0, 4.6.0, 4.7.0 (no difference in behaviour) optee_ftpm version 4.5.0 or 4.6.0, 4.7.0 (no difference in behaviour) ms-tpm-20-ref commit id 98b60a44aba79b15fcce1c0d1e46cf5918400f6a and e9fc7b89d865536c46deb63f9c7d0121a3ded49c Due to issues with RPMB, we decided to use REE_FS instead. Everything works correctly when I create RSA 2048 keys using tpm2-openssl and related tools: sudo tpm2_createprimary -C o -G rsa2048 -g sha256 -c primary.ctx, When I try rsa3072 or 4096, I get errors from the command line response saying invalid input parameters. I changed the ms-tpm-20-ref include file TpmProfile.h to set RSA_3072 and RSA_4096 macros both to (ALG_RSA && YES). After rebuilding and running, I now get an optee panic for ANY RSA key request INCLUDING rsa2048. I read suggestions to increase the MAX_COMMAND_SIZE/MAX_RESPONSE_SIZE on both the kernel driver tpm_ftpm_tee.ko and also optee_os/optee_ftpm, as well to increase relevant TA_STACK_SIZE and TA_HEAP_SIZE and TA_DATA_SIZE, but nothing seems to change the panic output: sudo tpm2_createprimary -C o -G rsa2048 -g sha256 -c primary.ctx============================================================ E/TC:? 0 E/TC:? 0 TA panicked with code 0xffff0007 E/LD: Status of TA bc50d971-d4c9-42c4-82cb-343fb7f37896 E/LD: arch: aarch64 E/LD: region 0: va 0x40005000 pa 0x9e8b0000 size 0x002000 flags rw-s (ldelf) E/LD: region 1: va 0x40007000 pa 0x9e8b2000 size 0x008000 flags r-xs (ldelf) E/LD: region 2: va 0x4000f000 pa 0x9e8ba000 size 0x001000 flags rw-s (ldelf) E/LD: region 3: va 0x40010000 pa 0x9e8bb000 size 0x004000 flags rw-s (ldelf) E/LD: region 4: va 0x40014000 pa 0x9e8bf000 size 0x001000 flags r--s E/LD: region 5: va 0x40015000 pa 0x9e934000 size 0x011000 flags rw-s (stack) E/LD: region 6: va 0x40026000 pa 0x8ebf0000 size 0x002000 flags rw-- (param) E/LD: region 7: va 0x4006e000 pa 0x9e8c0000 size 0x058000 flags r-xs [0] E/LD: region 8: va 0x400c6000 pa 0x9e918000 size 0x01c000 flags rw-s [0] E/LD: [0] bc50d971-d4c9-42c4-82cb-343fb7f37896 @ 0x4006e000 E/LD: Call stack: E/LD: 0x4006f394 E/LD: 0x40095edc E/LD: 0x4007b5a8 E/LD: 0x400985fc E/LD: 0x40098a70 E/LD: 0x4006fae0 E/LD: 0x400a5508 E/LD: 0x40098b9c D/TC:? 0 user_ta_enter:195 tee_user_ta_enter: TA panicked with code 0xffff0007 D/TC:? 0 release_ta_ctx:670 Releasing panicked TA ctx D/TC:? 0 tee_ta_invoke_command:798 Error: ffff3024 of 3 [ 218.944680] tpm tpm0: ftpm_tee_tpm_op_send: SUBMIT_COMMAND invoke error: 0xffff3024 [ 218.952379] tpm tpm0: tpm_try_transmit: send(): error -53212 D/TC:? 0 tee_ta_invoke_command:798 Error: ffff3024 of 3 [ 218.963359] tpm tpm0: ftpm_tee_tpm_op_send: SUBMIT_COMMAND invoke error: 0xffff3024 [ 218.974241] tpm tpm0: tpm_try_transmit: send(): error -53212 D/TC:? 0 tee_ta_invoke_command:798 Error: ffff3024 of 3 [ 218.985675] tpm tpm0: ftpm_tee_tpm_op_send: SUBMIT_COMMAND invoke error: 0xffff3024 [ 218.993366] tpm tpm0: tpm_try_transmit: send(): error -53212 [ 218.999044] tpm tpm0: tpm2_commit_space: error -14 ERROR:tcti:src/tss2-tcti/tcti-device.c:198:tcti_device_receive()D/TC:? 0 tee_ta_invoke_command:798 Error: ffff3024 of 3 Failed to get response size fd 3, got errno 14: Bad address E[ 219.015351] tpm tpm0: ftpm_tee_tpm_op_send: SUBMIT_COMMAND invoke error: 0xffff3024 RROR:esys:src/tss2-esys/api/Esys_CreatePrimary.c:404:Esys_Create[ 219.028348] tpm tpm0: tpm_try_transmit: send(): error -53212 Primary_Finish() Received a non-TPM Error ERROR:esys:src/tss2-esys/api/Esys_CreatePrimary.c:135:Esys_CreatePrimary() Esys Finish ErrorCode (0x000a000a) ERROR: Esys_CreatePrimary(0xA000A) - tcti:IO failure ERROR:esys:src/tss2-esys/esys_iutil.c:1145:iesys_check_sequence_async() Esys called in bad sequence. ERROR:esys:src/tss2-esys/api/Esys_FlushContext.c:66:Esys_FlushContext() Error in async function ErrorCode (0x00070007) ============================================================================= The last suggestion I saw was to change my dtb file to include a reserved memory region for optee shared memory and not use the default dynamic shared memory. The issue I have is kernel 6.6.100's tpm_ftpm_tee ignores the "memory-region" dts statement that references the optee_shm reserved memory at at 0xa4000000 in my case. Below is my snippet of the dts file. I heard there are patches in the kernel ftpm driver to support the reserved shared memory, but before I try the patches, can anyone opine whether this could cause the panic that I am seeing? Thanks in advance for anyone who can share any information optee_shm: optee-shm@a4000000 { compatible = "shared-dma-pool"; reg = <0x0 0xa4000000 0x0 0x01000000>; no-map; reusable; }; .... firmware { optee { compatible = "linaro,optee-tz"; method = "smc"; memory-region = <&optee_shm>; }; } Dennis Kong, P.Eng. Staff Engineer Perle Systems Limited 60 Renfrew Drive, Markham, ON L3R 0E1 (905) 475-6070 ext. 2126

1 year, 1 month

2
1
0 0

Question on OPTEE Support on Raspberry

by Yogesh Deshpande

Hi, I just wanted to know, has anyone ported OPTEE on Raspberry Pi 5 ? Is there an environment where one can run OPTEE with a Trusted App on a Pi 5 Hardware ? Please let me know. Regards, Yogesh Deshpande Principal Engineer, ATG Arm, Cambridge

1 year, 1 month

2
4
0 0

2026

2025

2024

2023

2022

2021

2020

OP-TEE