- OP-TEE - lists.trustedfirmware.org

[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

7 months, 1 week

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

7 months, 1 week

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

7 months, 1 week

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 |

7 months, 2 weeks

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

7 months, 2 weeks

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

7 months, 2 weeks

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>

7 months, 2 weeks

2
2
0 0

Issue with optee fixing supplicant wait loop

by Amirreza Zarrabi

Hi Jens, Sumit, The following change has recently been merged: tee: optee: Fix supplicant wait loop (https://github.com/torvalds/linux/commit/70b0d6b0a199c5a3ee6c72f5e61681ed6f…). This fix addresses the issue where the supplicant may terminate before the client due to the shutdown sequence or a crash. However, it introduces a potential new issue - now that the client is killable, what happens if it terminates before the supplicant? During cleanup, the client would remove/free the request, while the request would still be available in the request idr for the supplicant. Although I have not been able to reproduce it, this could theoretically result in a kernel page fault. To address this, there are a few options: (1) Use rcu and access request under a read lock in optee_supp_recv and optee_supp_send. (2) Reuse supp->mutex, ensuring that most of these functions run within the lock, even though it may not always be necessary. Could you confirm whether this behavior was intentional? If not, I am happy to prepare a patch. Additionally, please let me know whether you prefer solution (1) or (2), or if you have any other suggestions. Thank you for your time. Regards, Amir

7 months, 2 weeks

2
2
0 0

[PATCH AUTOSEL 5.4 4/5] tee: Prevent size calculation wraparound on 32-bit kernels

by Sasha Levin

From: Jann Horn <jannh(a)google.com> [ Upstream commit 39bb67edcc582b3b386a9ec983da67fa8a10ec03 ] The current code around TEE_IOCTL_PARAM_SIZE() is a bit wrong on 32-bit kernels: Multiplying a user-provided 32-bit value with the size of a structure can wrap around on such platforms. Fix it by using saturating arithmetic for the size calculation. This has no security consequences because, in all users of TEE_IOCTL_PARAM_SIZE(), the subsequent kcalloc() implicitly checks for wrapping. Signed-off-by: Jann Horn <jannh(a)google.com> Signed-off-by: Jens Wiklander <jens.wiklander(a)linaro.org> Tested-by: Rouven Czerwinski <rouven.czerwinski(a)linaro.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- **YES** This commit should be backported to stable kernel trees. Here's my extensive analysis: ## Vulnerability Analysis The commit fixes a real integer overflow vulnerability in the TEE (Trusted Execution Environment) subsystem on 32-bit kernels. The issue occurs in the `TEE_IOCTL_PARAM_SIZE()` macro defined as: ```c #define TEE_IOCTL_PARAM_SIZE(x) (sizeof(struct tee_param) * (x)) ``` Where `struct tee_ioctl_param` is 32 bytes (4 × 8-byte fields). On 32-bit systems, when a user provides a large `num_params` value, the multiplication `32 * num_params` can wrap around, potentially bypassing buffer length validation checks. ## Specific Vulnerable Code Locations The vulnerable pattern appears in 4 locations in `drivers/tee/tee_core.c`: 1. **Line 490**: `tee_ioctl_open_session()` - `sizeof(arg) + TEE_IOCTL_PARAM_SIZE(arg.num_params) != buf.buf_len` 2. **Line 568**: `tee_ioctl_invoke()` - `sizeof(arg) + TEE_IOCTL_PARAM_SIZE(arg.num_params) != buf.buf_len` 3. **Line 702**: `tee_ioctl_supp_recv()` - `sizeof(*uarg) + TEE_IOCTL_PARAM_SIZE(num_params) != buf.buf_len` 4. **Line 801**: `tee_ioctl_supp_send()` - `sizeof(*uarg) + TEE_IOCTL_PARAM_SIZE(num_params) > buf.buf_len` ## Attack Scenario On 32-bit systems, if `num_params = 0x08000000` (134,217,728), then: - `TEE_IOCTL_PARAM_SIZE(0x08000000) = 32 * 0x08000000 = 0x100000000` - This wraps to `0x00000000` on 32-bit systems - The size validation `sizeof(arg) + 0 != buf.buf_len` could be bypassed - Subsequent `kcalloc()` would allocate a huge buffer, but the size calculations would be wrong ## Why This Should Be Backported **Matches "YES" backport criteria from similar commits:** 1. **Security Fix**: Like Similar Commit #2 (rtl8188eu security hole) and #4 (gup_benchmark integer overflow), this prevents user-controlled integer overflow that could lead to memory corruption. 2. **Small, Contained Change**: The fix uses the kernel's standard `size_add()` and `size_mul()` helpers from `linux/overflow.h` - exactly like Similar Commit #3 which was noted as using `size_add()` for similar protection. 3. **Critical Subsystem**: TEE handles sensitive cryptographic operations and trusted applications, making security fixes here particularly important. 4. **Low Regression Risk**: The fix only adds overflow protection without changing functionality. The `size_mul()` and `size_add()` functions are well- tested kernel overflow helpers. 5. **User-Controllable Input**: The `num_params` value comes directly from user space through ioctl calls, making this a user-triggerable condition. 6. **Clear Security Impact**: While the commit states "no security consequences because kcalloc() implicitly checks for wrapping," this is defense-in-depth - the size validation should not rely on downstream allocation checks. The fix pattern exactly matches Similar Commit #4 (mm/gup_benchmark.c) which was backported for preventing integer overflow in size calculations with user-provided values. This commit follows the same security principle and uses the same overflow-safe arithmetic helpers that the kernel has standardized on for these scenarios. drivers/tee/tee_core.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/drivers/tee/tee_core.c b/drivers/tee/tee_core.c index 2db144d2d26f3..357944bc73b19 100644 --- a/drivers/tee/tee_core.c +++ b/drivers/tee/tee_core.c @@ -9,6 +9,7 @@ #include <linux/fs.h> #include <linux/idr.h> #include <linux/module.h> +#include <linux/overflow.h> #include <linux/slab.h> #include <linux/tee_drv.h> #include <linux/uaccess.h> @@ -16,7 +17,7 @@ #define TEE_NUM_DEVICES 32 -#define TEE_IOCTL_PARAM_SIZE(x) (sizeof(struct tee_param) * (x)) +#define TEE_IOCTL_PARAM_SIZE(x) (size_mul(sizeof(struct tee_param), (x))) /* * Unprivileged devices in the lower half range and privileged devices in @@ -327,7 +328,7 @@ static int tee_ioctl_open_session(struct tee_context *ctx, if (copy_from_user(&arg, uarg, sizeof(arg))) return -EFAULT; - if (sizeof(arg) + TEE_IOCTL_PARAM_SIZE(arg.num_params) != buf.buf_len) + if (size_add(sizeof(arg), TEE_IOCTL_PARAM_SIZE(arg.num_params)) != buf.buf_len) return -EINVAL; if (arg.num_params) { @@ -398,7 +399,7 @@ static int tee_ioctl_invoke(struct tee_context *ctx, if (copy_from_user(&arg, uarg, sizeof(arg))) return -EFAULT; - if (sizeof(arg) + TEE_IOCTL_PARAM_SIZE(arg.num_params) != buf.buf_len) + if (size_add(sizeof(arg), TEE_IOCTL_PARAM_SIZE(arg.num_params)) != buf.buf_len) return -EINVAL; if (arg.num_params) { @@ -532,7 +533,7 @@ static int tee_ioctl_supp_recv(struct tee_context *ctx, if (get_user(num_params, &uarg->num_params)) return -EFAULT; - if (sizeof(*uarg) + TEE_IOCTL_PARAM_SIZE(num_params) != buf.buf_len) + if (size_add(sizeof(*uarg), TEE_IOCTL_PARAM_SIZE(num_params)) != buf.buf_len) return -EINVAL; params = kcalloc(num_params, sizeof(struct tee_param), GFP_KERNEL); @@ -631,7 +632,7 @@ static int tee_ioctl_supp_send(struct tee_context *ctx, get_user(num_params, &uarg->num_params)) return -EFAULT; - if (sizeof(*uarg) + TEE_IOCTL_PARAM_SIZE(num_params) > buf.buf_len) + if (size_add(sizeof(*uarg), TEE_IOCTL_PARAM_SIZE(num_params)) > buf.buf_len) return -EINVAL; params = kcalloc(num_params, sizeof(struct tee_param), GFP_KERNEL); -- 2.39.5

7 months, 3 weeks

1
0
0 0

[PATCH AUTOSEL 5.10 4/5] tee: Prevent size calculation wraparound on 32-bit kernels

by Sasha Levin

From: Jann Horn <jannh(a)google.com> [ Upstream commit 39bb67edcc582b3b386a9ec983da67fa8a10ec03 ] The current code around TEE_IOCTL_PARAM_SIZE() is a bit wrong on 32-bit kernels: Multiplying a user-provided 32-bit value with the size of a structure can wrap around on such platforms. Fix it by using saturating arithmetic for the size calculation. This has no security consequences because, in all users of TEE_IOCTL_PARAM_SIZE(), the subsequent kcalloc() implicitly checks for wrapping. Signed-off-by: Jann Horn <jannh(a)google.com> Signed-off-by: Jens Wiklander <jens.wiklander(a)linaro.org> Tested-by: Rouven Czerwinski <rouven.czerwinski(a)linaro.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- **YES** This commit should be backported to stable kernel trees. Here's my extensive analysis: ## Vulnerability Analysis The commit fixes a real integer overflow vulnerability in the TEE (Trusted Execution Environment) subsystem on 32-bit kernels. The issue occurs in the `TEE_IOCTL_PARAM_SIZE()` macro defined as: ```c #define TEE_IOCTL_PARAM_SIZE(x) (sizeof(struct tee_param) * (x)) ``` Where `struct tee_ioctl_param` is 32 bytes (4 × 8-byte fields). On 32-bit systems, when a user provides a large `num_params` value, the multiplication `32 * num_params` can wrap around, potentially bypassing buffer length validation checks. ## Specific Vulnerable Code Locations The vulnerable pattern appears in 4 locations in `drivers/tee/tee_core.c`: 1. **Line 490**: `tee_ioctl_open_session()` - `sizeof(arg) + TEE_IOCTL_PARAM_SIZE(arg.num_params) != buf.buf_len` 2. **Line 568**: `tee_ioctl_invoke()` - `sizeof(arg) + TEE_IOCTL_PARAM_SIZE(arg.num_params) != buf.buf_len` 3. **Line 702**: `tee_ioctl_supp_recv()` - `sizeof(*uarg) + TEE_IOCTL_PARAM_SIZE(num_params) != buf.buf_len` 4. **Line 801**: `tee_ioctl_supp_send()` - `sizeof(*uarg) + TEE_IOCTL_PARAM_SIZE(num_params) > buf.buf_len` ## Attack Scenario On 32-bit systems, if `num_params = 0x08000000` (134,217,728), then: - `TEE_IOCTL_PARAM_SIZE(0x08000000) = 32 * 0x08000000 = 0x100000000` - This wraps to `0x00000000` on 32-bit systems - The size validation `sizeof(arg) + 0 != buf.buf_len` could be bypassed - Subsequent `kcalloc()` would allocate a huge buffer, but the size calculations would be wrong ## Why This Should Be Backported **Matches "YES" backport criteria from similar commits:** 1. **Security Fix**: Like Similar Commit #2 (rtl8188eu security hole) and #4 (gup_benchmark integer overflow), this prevents user-controlled integer overflow that could lead to memory corruption. 2. **Small, Contained Change**: The fix uses the kernel's standard `size_add()` and `size_mul()` helpers from `linux/overflow.h` - exactly like Similar Commit #3 which was noted as using `size_add()` for similar protection. 3. **Critical Subsystem**: TEE handles sensitive cryptographic operations and trusted applications, making security fixes here particularly important. 4. **Low Regression Risk**: The fix only adds overflow protection without changing functionality. The `size_mul()` and `size_add()` functions are well- tested kernel overflow helpers. 5. **User-Controllable Input**: The `num_params` value comes directly from user space through ioctl calls, making this a user-triggerable condition. 6. **Clear Security Impact**: While the commit states "no security consequences because kcalloc() implicitly checks for wrapping," this is defense-in-depth - the size validation should not rely on downstream allocation checks. The fix pattern exactly matches Similar Commit #4 (mm/gup_benchmark.c) which was backported for preventing integer overflow in size calculations with user-provided values. This commit follows the same security principle and uses the same overflow-safe arithmetic helpers that the kernel has standardized on for these scenarios. drivers/tee/tee_core.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/drivers/tee/tee_core.c b/drivers/tee/tee_core.c index 9cc4a7b63b0d6..e6de0e80b793e 100644 --- a/drivers/tee/tee_core.c +++ b/drivers/tee/tee_core.c @@ -10,6 +10,7 @@ #include <linux/fs.h> #include <linux/idr.h> #include <linux/module.h> +#include <linux/overflow.h> #include <linux/slab.h> #include <linux/tee_drv.h> #include <linux/uaccess.h> @@ -19,7 +20,7 @@ #define TEE_NUM_DEVICES 32 -#define TEE_IOCTL_PARAM_SIZE(x) (sizeof(struct tee_param) * (x)) +#define TEE_IOCTL_PARAM_SIZE(x) (size_mul(sizeof(struct tee_param), (x))) #define TEE_UUID_NS_NAME_SIZE 128 @@ -492,7 +493,7 @@ static int tee_ioctl_open_session(struct tee_context *ctx, if (copy_from_user(&arg, uarg, sizeof(arg))) return -EFAULT; - if (sizeof(arg) + TEE_IOCTL_PARAM_SIZE(arg.num_params) != buf.buf_len) + if (size_add(sizeof(arg), TEE_IOCTL_PARAM_SIZE(arg.num_params)) != buf.buf_len) return -EINVAL; if (arg.num_params) { @@ -570,7 +571,7 @@ static int tee_ioctl_invoke(struct tee_context *ctx, if (copy_from_user(&arg, uarg, sizeof(arg))) return -EFAULT; - if (sizeof(arg) + TEE_IOCTL_PARAM_SIZE(arg.num_params) != buf.buf_len) + if (size_add(sizeof(arg), TEE_IOCTL_PARAM_SIZE(arg.num_params)) != buf.buf_len) return -EINVAL; if (arg.num_params) { @@ -704,7 +705,7 @@ static int tee_ioctl_supp_recv(struct tee_context *ctx, if (get_user(num_params, &uarg->num_params)) return -EFAULT; - if (sizeof(*uarg) + TEE_IOCTL_PARAM_SIZE(num_params) != buf.buf_len) + if (size_add(sizeof(*uarg), TEE_IOCTL_PARAM_SIZE(num_params)) != buf.buf_len) return -EINVAL; params = kcalloc(num_params, sizeof(struct tee_param), GFP_KERNEL); @@ -803,7 +804,7 @@ static int tee_ioctl_supp_send(struct tee_context *ctx, get_user(num_params, &uarg->num_params)) return -EFAULT; - if (sizeof(*uarg) + TEE_IOCTL_PARAM_SIZE(num_params) > buf.buf_len) + if (size_add(sizeof(*uarg), TEE_IOCTL_PARAM_SIZE(num_params)) > buf.buf_len) return -EINVAL; params = kcalloc(num_params, sizeof(struct tee_param), GFP_KERNEL); -- 2.39.5

7 months, 3 weeks

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

OP-TEE