- OP-TEE - lists.trustedfirmware.org

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(-)

5 months

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(-)

5 months

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

5 months

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.

5 months

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

5 months, 1 week

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

5 months, 1 week

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

5 months, 1 week

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

5 months, 2 weeks

2
4
0 0

[PATCH] tee: fix memory leak in tee_dyn_shm_alloc_helper

by Pei Xiao

When shm_register() fails in tee_dyn_shm_alloc_helper(), the pre-allocated pages array is not freed, resulting in a memory leak. Fixes: cf4441503e20 ("tee: optee: Move pool_op helper functions") Signed-off-by: Pei Xiao <xiaopei01(a)kylinos.cn> --- drivers/tee/tee_shm.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/tee/tee_shm.c b/drivers/tee/tee_shm.c index 915239b033f5..2a7d253d9c55 100644 --- a/drivers/tee/tee_shm.c +++ b/drivers/tee/tee_shm.c @@ -230,7 +230,7 @@ int tee_dyn_shm_alloc_helper(struct tee_shm *shm, size_t size, size_t align, pages = kcalloc(nr_pages, sizeof(*pages), GFP_KERNEL); if (!pages) { rc = -ENOMEM; - goto err; + goto err_pages; } for (i = 0; i < nr_pages; i++) @@ -243,11 +243,13 @@ int tee_dyn_shm_alloc_helper(struct tee_shm *shm, size_t size, size_t align, rc = shm_register(shm->ctx, shm, pages, nr_pages, (unsigned long)shm->kaddr); if (rc) - goto err; + goto err_kfree; } return 0; -err: +err_kfree: + kfree(pages); +err_pages: free_pages_exact(shm->kaddr, shm->size); shm->kaddr = NULL; return rc; -- 2.25.1

5 months, 2 weeks

4
3
0 0

[PATCH] tee: fix NULL pointer dereference in tee_shm_put

by Pei Xiao

tee_shm_put have NULL pointer dereference: __optee_disable_shm_cache --> shm = reg_pair_to_ptr(...);//shm maybe return NULL tee_shm_free(shm); --> tee_shm_put(shm);//crash Add check in tee_shm_put to fix it. panic log: Unable to handle kernel paging request at virtual address 0000000000100cca Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=0000002049d07000 [0000000000100cca] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP CPU: 2 PID: 14442 Comm: systemd-sleep Tainted: P OE ------- ---- 6.6.0-39-generic #38 Source Version: 938b255f6cb8817c95b0dd5c8c2944acfce94b07 Hardware name: greatwall GW-001Y1A-FTH, BIOS Great Wall BIOS V3.0 10/26/2022 pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : tee_shm_put+0x24/0x188 lr : tee_shm_free+0x14/0x28 sp : ffff001f98f9faf0 x29: ffff001f98f9faf0 x28: ffff0020df543cc0 x27: 0000000000000000 x26: ffff001f811344a0 x25: ffff8000818dac00 x24: ffff800082d8d048 x23: ffff001f850fcd18 x22: 0000000000000001 x21: ffff001f98f9fb88 x20: ffff001f83e76218 x19: ffff001f83e761e0 x18: 000000000000ffff x17: 303a30303a303030 x16: 0000000000000000 x15: 0000000000000003 x14: 0000000000000001 x13: 0000000000000000 x12: 0101010101010101 x11: 0000000000000001 x10: 0000000000000001 x9 : ffff800080e08d0c x8 : ffff001f98f9fb88 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : ffff001f83e761e0 x1 : 00000000ffff001f x0 : 0000000000100cca Call trace: tee_shm_put+0x24/0x188 tee_shm_free+0x14/0x28 __optee_disable_shm_cache+0xa8/0x108 optee_shutdown+0x28/0x38 platform_shutdown+0x28/0x40 device_shutdown+0x144/0x2b0 kernel_power_off+0x3c/0x80 hibernate+0x35c/0x388 state_store+0x64/0x80 kobj_attr_store+0x14/0x28 sysfs_kf_write+0x48/0x60 kernfs_fop_write_iter+0x128/0x1c0 vfs_write+0x270/0x370 ksys_write+0x6c/0x100 __arm64_sys_write+0x20/0x30 invoke_syscall+0x4c/0x120 el0_svc_common.constprop.0+0x44/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x24/0x88 el0t_64_sync_handler+0x134/0x150 el0t_64_sync+0x14c/0x15 Fixes: dfd0743f1d9e ("tee: handle lookup of shm with reference count 0") Signed-off-by: Pei Xiao <xiaopei01(a)kylinos.cn> --- drivers/tee/tee_shm.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/tee/tee_shm.c b/drivers/tee/tee_shm.c index daf6e5cfd59a..915239b033f5 100644 --- a/drivers/tee/tee_shm.c +++ b/drivers/tee/tee_shm.c @@ -560,9 +560,13 @@ EXPORT_SYMBOL_GPL(tee_shm_get_from_id); */ void tee_shm_put(struct tee_shm *shm) { - struct tee_device *teedev = shm->ctx->teedev; + struct tee_device *teedev; bool do_release = false; + if (!shm || !shm->ctx || !shm->ctx->teedev) + return; + + teedev = shm->ctx->teedev; mutex_lock(&teedev->mutex); if (refcount_dec_and_test(&shm->refcount)) { /* -- 2.25.1

5 months, 2 weeks

3
2
0 0

2026

2025

2024

2023

2022

2021

2020

OP-TEE