- OP-TEE - lists.trustedfirmware.org

Re: Compilation Issue for plat-k3 for am67a beagleY-AI Board

by ANAND MOHAN Tiwari

Hi Team, Request you to add support for am67a beagleY-AI board. Let me know if i can help in any way for the same. Thanks & Regards, Anand Mohan Tiwari (M) +91 82 99106839 (M) +91 87 65696940 On Mon, 7 Jul 2025 at 12:45 PM, ANAND MOHAN Tiwari < anandmohantiwari94(a)gmail.com> wrote: > Hi Jens, > > Thanks for the confirmation. I’ll report this to optee. How we can make > sure to get its support added ?? > > > Thanks & Regards, > Anand Mohan Tiwari > (M) +91 82 99106839 > (M) +91 87 65696940 > > > On Mon, 7 Jul 2025 at 12:19 PM, Jens Wiklander <jens.wiklander(a)linaro.org> > wrote: > >> Hi Anand, >> >> https://github.com/OP-TEE/optee_os/issues/ is the best place to report >> issues like this, or possibly op-tee(a)lists.trustedfirmware.org. >> >> Anyway, from the source code, it looks like k3-am67a isn't supported. >> >> Cheers, >> Jens >> >> On Mon, Jul 7, 2025 at 8:34 AM ANAND MOHAN Tiwari >> <anandmohantiwari94(a)gmail.com> wrote: >> > >> > Dear All, >> > >> > This is to bring your attention towards compilation issue faced by me >> for k3-am67a board. I can see compilation works till PLATFORM=k3-65x for >> optee_os but when i tried compiling the same am67x it throws >> core/arch/arm/plat-k3/drivers/sa2ul.c:36 error: ‘SA2UL_BASE’ undeclared >> here same error is thrown for SA2UL_TI_SCI_FW_ID, >> > SA2UL_TI_SCI_FW_RGN_ID, >> > SA2UL_TI_SCI_DEV_ID, >> > >> > core/arch/arm/plat-k3/./platform_configs.h:91 >> > ‘SA2UL_BASE’ undeclared >> > >> > Not sure whom to contact to report this but i found these mails in >> commit messages. Request you to check on this or let me know if I’m missing >> something >> > Tried below steps. >> > >> > git clone -b 11.01.03 >> https://github.com/beagleboard/ti-linux-firmware.git --depth=1 >> > >> > git clone -b lts-v2.12.4 >> https://github.com/TrustedFirmware-A/trusted-firmware-a.git --depth=1 >> > >> > make -C ./trusted-firmware-a/ -j4 CROSS_COMPILE=${CC64} PLAT=k3 >> ARCH=aarch64 SPD=opteed TARGET_BOARD=lite all >> > >> > >> > git clone -b 4.6.0 https://github.com/OP-TEE/optee_os.git --depth=1 >> > >> > >> > make -C ./optee_os/ -j4 CROSS_COMPILE=${CC32} CROSS_COMPILE64=${CC64} >> CFG_ARM64_core=y PLATFORM=k3-am62x all ————-> working >> > >> > make -C ./optee_os/ -j4 CROSS_COMPILE=${CC32} CROSS_COMPILE64=${CC64} >> CFG_ARM64_core=y PLATFORM=k3-am65x all ————-> working till this but tried >> for compiling below >> > >> > make -C ./optee_os/ -j4 CROSS_COMPILE=${CC32} CROSS_COMPILE64=${CC64} >> CFG_ARM64_core=y PLATFORM=k3-am67x all ————-> not working also tried by >> putting k3-am67a —this my board beagleY-AI >> > >> > Let me know if I’m missing something or we need to follow different >> procedures apart from above >> > >> > Thanks in advance. You can reach out me via below numbers or reply on >> same email. >> > >> > Thanks & Regards, >> > Anand Mohan Tiwari >> > (M) +91 82 99106839 >> > (M) +91 87 65696940 >> >

1 year, 1 month

2
1
0 0

Preparing for OP-TEE 4.7.0

by Jerome Forissier

[BCC all OP-TEE maintainers] Hi OP-TEE maintainers & contributors, OP-TEE version 4.7.0 is scheduled to be released on 2025-07-11. So, now is a good time to start testing the master branch on the various platforms and report/fix any bugs. The GitHub pull request for collecting Tested-by tags or any other comments is https://github.com/OP-TEE/optee_os/pull/7439. We will create the release candidate tag 4.7.0-rc1 next Friday, allowing for a two week testing period before the planned release. You can find more information related to releases here: https://optee.readthedocs.io/en/latest/general/releases.html Thanks, -- Jerome

1 year, 1 month

1
2
0 0

Linaro OP-TEE Contribution, LOC, monthly meeting June 24

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/ - Jerome just announced that OP-TEE version 4.7.0 is scheduled for July 11. - Dynamic memory configuration in OP-TEE is nearing an end with https://github.com/OP-TEE/optee_os/pull/7426. I have a few more patches in store, but almost all the big and difficult things are done. - The Secure Data Path patchset [1] is at v10 Are there any other topics? [1] https://lore.kernel.org/op-tee/20250610131600.2972232-1-jens.wiklander@lina… Thanks, Jens

1 year, 1 month

1
0
0 0

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

by Arnaud Pouliquen

Main updates from version V17[1]: - Fix: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing More details are available in each patch commit message. [1] https://lore.kernel.org/linux-remoteproc/20250613091650.2337411-1-arnaud.po… Tested-on: commit 19272b37aa4f ("Linux 6.16-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 (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 | 620 ++++++++++++++++++ drivers/remoteproc/stm32_rproc.c | 139 +++- include/linux/remoteproc.h | 4 + include/linux/remoteproc_tee.h | 90 +++ 9 files changed, 936 insertions(+), 44 deletions(-) create mode 100644 drivers/remoteproc/remoteproc_tee.c create mode 100644 include/linux/remoteproc_tee.h base-commit: 19272b37aa4f83ca52bdf9c16d5d81bdd1354494 -- 2.25.1

1 year, 1 month

3
10
0 0

[GIT PULL] OP-TEE fix for 6.16

by Jens Wiklander

Hello arm-soc maintainers, Please pull this patch for the optee driver. It relates to the FF-A driver PR https://lore.kernel.org/all/20250609105207.1185570-1-sudeep.holla@arm.com but it makes sense on its own and can be applied independently. Thanks, Jens The following changes since commit 0ff41df1cb268fc69e703a08a57ee14ae967d0ca: Linux 6.15 (2025-05-25 16:09:23 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jenswi/linux-tee.git tags/optee-fix-for-v6.16 for you to fetch changes up to 312d02adb959ea199372f375ada06e0186f651e4: optee: ffa: fix sleep in atomic context (2025-06-12 12:04:57 +0200) ---------------------------------------------------------------- A fix in the OP-TEE driver for v6.16 Fixing a sleep in atomic context in the FF-A notification callback by adding a work queue to process in a non-atomic context. ---------------------------------------------------------------- Jens Wiklander (1): optee: ffa: fix sleep in atomic context drivers/tee/optee/ffa_abi.c | 41 ++++++++++++++++++++++++++++++--------- drivers/tee/optee/optee_private.h | 2 ++ 2 files changed, 34 insertions(+), 9 deletions(-)

1 year, 1 month

1
0
0 0

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

by Arnaud Pouliquen

Main updates from version V16[1]: - rebase on Linux Kernel v6.16-rc1, - fix double space typos. More details are available in each patch commit message. [1] https://lore.kernel.org/linux-remoteproc/CANLsYky=AAnQ3P6J9E9R1=ufVKpGniiVT… Tested-on: commit 19272b37aa4f ("Linux 6.16-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 (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: 19272b37aa4f83ca52bdf9c16d5d81bdd1354494 -- 2.25.1

1 year, 2 months

2
7
0 0

Firmware Handoff for DT Overlay created by OP-TEE?

by Ahmad Fatoum

Hello Manish, In your recent talk[1] at LinaroConnect about the Firmware Handoff specification, you were asking about what other use cases it could address for OP-TEE. We ran into a possible use case that we would like to share: BL2 can pass a DT to OP-TEE, which it would use to discover memory and to fix up with memory reservations covering the memory it carves out for itself. OP-TEE also supports passing along the reservations as a device tree overlay. AFAICS, there is no way currently to have both: A DT for OP-TEE to probe hardware from and a way to pass the normal world a device tree overlay in return. I think this could be neatly addressed with Firmware Handoff and would be a motivation for us to implement support in barebox BL2/BL33 to take advantage of this. The current way is suboptimal as we would prefer the DT passed to OP-TEE to be read-only. This avoids either having to copy it or to pad it sufficiently in anticipation of it growing with the addition of the new nodes. [1]: https://www.youtube.com/watch?v=RxU798h8aiE Cheers, Ahmad -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |

1 year, 2 months

2
2
0 0

[PATCH] optee: ffa: fix sleep in atomic context

by Jens Wiklander

The OP-TEE driver registers the function notif_callback() for FF-A notifications. However, this function is called in an atomic context leading to errors like this when processing asynchronous notifications: | BUG: sleeping function called from invalid context at kernel/locking/mutex.c:258 | in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 9, name: kworker/0:0 | preempt_count: 1, expected: 0 | RCU nest depth: 0, expected: 0 | CPU: 0 UID: 0 PID: 9 Comm: kworker/0:0 Not tainted 6.14.0-00019-g657536ebe0aa #13 | Hardware name: linux,dummy-virt (DT) | Workqueue: ffa_pcpu_irq_notification notif_pcpu_irq_work_fn | Call trace: | show_stack+0x18/0x24 (C) | dump_stack_lvl+0x78/0x90 | dump_stack+0x18/0x24 | __might_resched+0x114/0x170 | __might_sleep+0x48/0x98 | mutex_lock+0x24/0x80 | optee_get_msg_arg+0x7c/0x21c | simple_call_with_arg+0x50/0xc0 | optee_do_bottom_half+0x14/0x20 | notif_callback+0x3c/0x48 | handle_notif_callbacks+0x9c/0xe0 | notif_get_and_handle+0x40/0x88 | generic_exec_single+0x80/0xc0 | smp_call_function_single+0xfc/0x1a0 | notif_pcpu_irq_work_fn+0x2c/0x38 | process_one_work+0x14c/0x2b4 | worker_thread+0x2e4/0x3e0 | kthread+0x13c/0x210 | ret_from_fork+0x10/0x20 Fix this by adding work queue to process the notification in a non-atomic context. Fixes: d0476a59de06 ("optee: ffa_abi: add asynchronous notifications") Signed-off-by: Jens Wiklander <jens.wiklander(a)linaro.org> --- drivers/tee/optee/ffa_abi.c | 41 ++++++++++++++++++++++++------- drivers/tee/optee/optee_private.h | 2 ++ 2 files changed, 34 insertions(+), 9 deletions(-) diff --git a/drivers/tee/optee/ffa_abi.c b/drivers/tee/optee/ffa_abi.c index f3af5666bb11..f9ef7d94cebd 100644 --- a/drivers/tee/optee/ffa_abi.c +++ b/drivers/tee/optee/ffa_abi.c @@ -728,12 +728,21 @@ static bool optee_ffa_exchange_caps(struct ffa_device *ffa_dev, return true; } +static void notif_work_fn(struct work_struct *work) +{ + struct optee_ffa *optee_ffa = container_of(work, struct optee_ffa, + notif_work); + struct optee *optee = container_of(optee_ffa, struct optee, ffa); + + optee_do_bottom_half(optee->ctx); +} + static void notif_callback(int notify_id, void *cb_data) { struct optee *optee = cb_data; if (notify_id == optee->ffa.bottom_half_value) - optee_do_bottom_half(optee->ctx); + queue_work(optee->ffa.notif_wq, &optee->ffa.notif_work); else optee_notif_send(optee, notify_id); } @@ -817,9 +826,11 @@ static void optee_ffa_remove(struct ffa_device *ffa_dev) struct optee *optee = ffa_dev_get_drvdata(ffa_dev); u32 bottom_half_id = optee->ffa.bottom_half_value; - if (bottom_half_id != U32_MAX) + if (bottom_half_id != U32_MAX) { ffa_dev->ops->notifier_ops->notify_relinquish(ffa_dev, bottom_half_id); + destroy_workqueue(optee->ffa.notif_wq); + } optee_remove_common(optee); mutex_destroy(&optee->ffa.mutex); @@ -835,6 +846,13 @@ static int optee_ffa_async_notif_init(struct ffa_device *ffa_dev, u32 notif_id = 0; int rc; + INIT_WORK(&optee->ffa.notif_work, notif_work_fn); + optee->ffa.notif_wq = create_workqueue("optee_notification"); + if (!optee->ffa.notif_wq) { + rc = -EINVAL; + goto err; + } + while (true) { rc = ffa_dev->ops->notifier_ops->notify_request(ffa_dev, is_per_vcpu, @@ -851,19 +869,24 @@ static int optee_ffa_async_notif_init(struct ffa_device *ffa_dev, * notifications in that case. */ if (rc != -EACCES) - return rc; + goto err_wq; notif_id++; if (notif_id >= OPTEE_FFA_MAX_ASYNC_NOTIF_VALUE) - return rc; + goto err_wq; } optee->ffa.bottom_half_value = notif_id; rc = enable_async_notif(optee); - if (rc < 0) { - ffa_dev->ops->notifier_ops->notify_relinquish(ffa_dev, - notif_id); - optee->ffa.bottom_half_value = U32_MAX; - } + if (rc < 0) + goto err_rel; + + return 0; +err_rel: + ffa_dev->ops->notifier_ops->notify_relinquish(ffa_dev, notif_id); +err_wq: + destroy_workqueue(optee->ffa.notif_wq); +err: + optee->ffa.bottom_half_value = U32_MAX; return rc; } diff --git a/drivers/tee/optee/optee_private.h b/drivers/tee/optee/optee_private.h index dc0f355ef72a..9526087f0e68 100644 --- a/drivers/tee/optee/optee_private.h +++ b/drivers/tee/optee/optee_private.h @@ -165,6 +165,8 @@ struct optee_ffa { /* Serializes access to @global_ids */ struct mutex mutex; struct rhashtable global_ids; + struct workqueue_struct *notif_wq; + struct work_struct notif_work; }; struct optee; -- 2.43.0

1 year, 2 months

3
6
0 0

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

by Arnaud Pouliquen

Hello Bjorn and Mathieu, I am resending this series after waiting for over two months for Bjorn's feedback, despite a prior reminder. Please could you coordinate between yourselves to determine who will continue reviewing this series? It would be greatly appreciated if the review could proceed within a more reasonable timeframe. Thanks in advance and best regards, Arnaud 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 0ff41df1cb26 ("Linux 6.15") 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: 0ff41df1cb268fc69e703a08a57ee14ae967d0ca -- 2.25.1

1 year, 2 months

3
10
0 0

[PATCH] tee: optee: prevent use-after-free when the client exits before the supplicant

by Amirreza Zarrabi

Commit 70b0d6b0a199 ("tee: optee: Fix supplicant wait loop") made the client wait as killable so it can be interrupted during shutdown or after a supplicant crash. This changes the original lifetime expectations: the client task can now terminate while the supplicant is still processing its request. If the client exits first it removes the request from its queue and kfree()s it, while the request ID remains in supp->idr. A subsequent lookup on the supplicant path then dereferences freed memory, leading to a use-after-free. Serialise access to the request with supp->mutex: * Hold supp->mutex in optee_supp_recv() and optee_supp_send() while looking up and touching the request. * Let optee_supp_thrd_req() notice that the client has terminated and signal optee_supp_send() accordingly. With these changes the request cannot be freed while the supplicant still has a reference, eliminating the race. Fixes: 70b0d6b0a199 ("tee: optee: Fix supplicant wait loop") Signed-off-by: Amirreza Zarrabi <amirreza.zarrabi(a)oss.qualcomm.com> --- drivers/tee/optee/supp.c | 114 ++++++++++++++++++++++++++++++++--------------- 1 file changed, 77 insertions(+), 37 deletions(-) diff --git a/drivers/tee/optee/supp.c b/drivers/tee/optee/supp.c index d0f397c90242..62c9c75f48a6 100644 --- a/drivers/tee/optee/supp.c +++ b/drivers/tee/optee/supp.c @@ -9,6 +9,7 @@ struct optee_supp_req { struct list_head link; + int id; bool in_queue; u32 func; @@ -19,6 +20,9 @@ struct optee_supp_req { struct completion c; }; +/* It is temporary request used for invalid pending request in supp->idr. */ +static struct optee_supp_req invalid_req; + void optee_supp_init(struct optee_supp *supp) { memset(supp, 0, sizeof(*supp)); @@ -102,6 +106,7 @@ u32 optee_supp_thrd_req(struct tee_context *ctx, u32 func, size_t num_params, mutex_lock(&supp->mutex); list_add_tail(&req->link, &supp->reqs); req->in_queue = true; + req->id = -1; mutex_unlock(&supp->mutex); /* Tell an eventual waiter there's a new request */ @@ -117,21 +122,40 @@ u32 optee_supp_thrd_req(struct tee_context *ctx, u32 func, size_t num_params, if (wait_for_completion_killable(&req->c)) { mutex_lock(&supp->mutex); if (req->in_queue) { + /* Supplicant has not seen this request yet. */ list_del(&req->link); req->in_queue = false; + + ret = TEEC_ERROR_COMMUNICATION; + } else if (req->id == -1) { + /* + * Supplicant has processed this request. Ignore the + * kill signal for now and submit the result. + */ + ret = req->ret; + } else { + /* + * Supplicant is in the middle of processing this + * request. Replace req with invalid_req so that the ID + * remains busy, causing optee_supp_send() to fail on + * the next call to supp_pop_req() with this ID. + */ + idr_replace(&supp->idr, &invalid_req, req->id); + ret = TEEC_ERROR_COMMUNICATION; } + + kfree(req); mutex_unlock(&supp->mutex); - req->ret = TEEC_ERROR_COMMUNICATION; + } else { + ret = req->ret; + kfree(req); } - ret = req->ret; - kfree(req); - return ret; } static struct optee_supp_req *supp_pop_entry(struct optee_supp *supp, - int num_params, int *id) + int num_params) { struct optee_supp_req *req; @@ -153,8 +177,8 @@ static struct optee_supp_req *supp_pop_entry(struct optee_supp *supp, return ERR_PTR(-EINVAL); } - *id = idr_alloc(&supp->idr, req, 1, 0, GFP_KERNEL); - if (*id < 0) + req->id = idr_alloc(&supp->idr, req, 1, 0, GFP_KERNEL); + if (req->id < 0) return ERR_PTR(-ENOMEM); list_del(&req->link); @@ -214,7 +238,6 @@ int optee_supp_recv(struct tee_context *ctx, u32 *func, u32 *num_params, struct optee *optee = tee_get_drvdata(teedev); struct optee_supp *supp = &optee->supp; struct optee_supp_req *req = NULL; - int id; size_t num_meta; int rc; @@ -223,16 +246,45 @@ int optee_supp_recv(struct tee_context *ctx, u32 *func, u32 *num_params, return rc; while (true) { - mutex_lock(&supp->mutex); - req = supp_pop_entry(supp, *num_params - num_meta, &id); - mutex_unlock(&supp->mutex); + scoped_guard(mutex, &supp->mutex) { + req = supp_pop_entry(supp, *num_params - num_meta); + if (!req) + goto wait_for_request; - if (req) { if (IS_ERR(req)) return PTR_ERR(req); - break; + + /* + * Popped a request: process it while holding the lock, + * so that optee_supp_thrd_req() doesn't pull the + * request out from under us. + */ + + if (num_meta) { + /* + * tee-supplicant support meta parameters -> + * requests can be processed asynchronously. + */ + param->attr = + TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INOUT | + TEE_IOCTL_PARAM_ATTR_META; + param->u.value.a = req->id; + param->u.value.b = 0; + param->u.value.c = 0; + } else { + supp->req_id = req->id; + } + + *func = req->func; + *num_params = req->num_params + num_meta; + memcpy(param + num_meta, req->param, + sizeof(struct tee_param) * req->num_params); } + /* Check for the next request in the queue. */ + continue; + +wait_for_request: /* * If we didn't get a request we'll block in * wait_for_completion() to avoid needless spinning. @@ -245,27 +297,6 @@ int optee_supp_recv(struct tee_context *ctx, u32 *func, u32 *num_params, return -ERESTARTSYS; } - if (num_meta) { - /* - * tee-supplicant support meta parameters -> requsts can be - * processed asynchronously. - */ - param->attr = TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INOUT | - TEE_IOCTL_PARAM_ATTR_META; - param->u.value.a = id; - param->u.value.b = 0; - param->u.value.c = 0; - } else { - mutex_lock(&supp->mutex); - supp->req_id = id; - mutex_unlock(&supp->mutex); - } - - *func = req->func; - *num_params = req->num_params + num_meta; - memcpy(param + num_meta, req->param, - sizeof(struct tee_param) * req->num_params); - return 0; } @@ -297,12 +328,21 @@ static struct optee_supp_req *supp_pop_req(struct optee_supp *supp, if (!req) return ERR_PTR(-ENOENT); + /* optee_supp_thrd_req() already returned to optee. */ + if (req == &invalid_req) { + req = ERR_PTR(-ENOENT); + goto failed_req; + } + if ((num_params - nm) != req->num_params) return ERR_PTR(-EINVAL); + req->id = -1; + *num_meta = nm; +failed_req: idr_remove(&supp->idr, id); supp->req_id = -1; - *num_meta = nm; + return req; } @@ -328,9 +368,8 @@ int optee_supp_send(struct tee_context *ctx, u32 ret, u32 num_params, mutex_lock(&supp->mutex); req = supp_pop_req(supp, num_params, param, &num_meta); - mutex_unlock(&supp->mutex); - if (IS_ERR(req)) { + mutex_unlock(&supp->mutex); /* Something is wrong, let supplicant restart. */ return PTR_ERR(req); } @@ -358,6 +397,7 @@ int optee_supp_send(struct tee_context *ctx, u32 ret, u32 num_params, /* Let the requesting thread continue */ complete(&req->c); + mutex_unlock(&supp->mutex); return 0; } --- base-commit: 3be1a7a31fbda82f3604b6c31e4f390110de1b46 change-id: 20250604-fix-use-after-free-8ff1b5d5d774 Best regards, -- Amirreza Zarrabi <amirreza.zarrabi(a)oss.qualcomm.com>

1 year, 2 months

2
2
0 0

2026

2025

2024

2023

2022

2021

2020

OP-TEE