- OP-TEE - lists.trustedfirmware.org

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

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

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

1 year

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

1 year

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

1 year

1
0
0 0

[PATCH AUTOSEL 5.15 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 a44e5b53e7a91..a7e89c229fc51 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 @@ -493,7 +494,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) { @@ -571,7 +572,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) { @@ -705,7 +706,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); @@ -804,7 +805,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

1 year

1
0
0 0

[PATCH AUTOSEL 6.1 5/6] 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 98da206cd7615..a9a893bc19fa4 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 @@ -487,7 +488,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) { @@ -565,7 +566,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) { @@ -699,7 +700,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); @@ -798,7 +799,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

1 year

1
0
0 0

[PATCH AUTOSEL 6.6 5/6] 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 0eb342de0b001..d7ad16f262b2e 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 @@ -487,7 +488,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) { @@ -565,7 +566,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) { @@ -699,7 +700,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); @@ -798,7 +799,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

1 year

1
0
0 0

[PATCH AUTOSEL 6.12 5/6] 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 d113679b1e2d7..acc7998758ad8 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_core.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 @@ -487,7 +488,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) { @@ -565,7 +566,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) { @@ -699,7 +700,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); @@ -798,7 +799,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

1 year

1
0
0 0

[PATCH AUTOSEL 6.14 7/8] 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 d113679b1e2d7..acc7998758ad8 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_core.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 @@ -487,7 +488,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) { @@ -565,7 +566,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) { @@ -699,7 +700,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); @@ -798,7 +799,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

1 year

1
0
0 0

[PATCH AUTOSEL 6.15 8/9] 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 d113679b1e2d7..acc7998758ad8 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_core.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 @@ -487,7 +488,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) { @@ -565,7 +566,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) { @@ -699,7 +700,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); @@ -798,7 +799,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

1 year

1
0
0 0

[PATCH v9 0/9] TEE subsystem for protected dma-buf allocations

by Jens Wiklander

Hi, This patch set allocates the protected DMA-bufs from a DMA-heap instantiated from the TEE subsystem. The TEE subsystem handles the DMA-buf allocations since it is the TEE (OP-TEE, AMD-TEE, TS-TEE, or perhaps a future QTEE) which sets up the protection for the memory used for the DMA-bufs. The DMA-heap uses a protected memory pool provided by the backend TEE driver, allowing it to choose how to allocate the protected physical memory. The allocated DMA-bufs must be imported with a new TEE_IOC_SHM_REGISTER_FD before they can be passed as arguments when requesting services from the secure world. Three use-cases (Secure Video Playback, Trusted UI, and Secure Video Recording) have been identified so far to serve as examples of what can be expected. The use-cases have predefined DMA-heap names, "protected,secure-video", "protected,trusted-ui", and "protected,secure-video-record". The backend driver registers protected memory pools for the use-cases it supports. Each use-case has its own protected memory pool since different use-cases require isolation from different parts of the system. A protected memory pool can be based on a static carveout instantiated while probing the TEE backend driver, or dynamically allocated from CMA (dma_alloc_pages()) and made protected as needed by the TEE. This can be tested on a RockPi 4B+ with the following steps: repo init -u https://github.com/jenswi-linaro/manifest.git -m rockpi4.xml \ -b prototype/sdp-v9 repo sync -j8 cd build make toolchains -j$(nproc) make all -j$(nproc) # Copy ../out/rockpi4.img to an SD card and boot the RockPi from that # Connect a monitor to the RockPi # login and at the prompt: gst-launch-1.0 videotestsrc ! \ aesenc key=1f9423681beb9a79215820f6bda73d0f \ iv=e9aa8e834d8d70b7e0d254ff670dd718 serialize-iv=true ! \ aesdec key=1f9423681beb9a79215820f6bda73d0f ! \ kmssink The aesdec module has been hacked to use an OP-TEE TA to decrypt the stream into protected DMA-bufs which are consumed by the kmssink. The primitive QEMU tests from previous patch sets can be tested on RockPi in the same way using: xtest --sdp-basic The primitive tests are tested on QEMU with the following steps: repo init -u https://github.com/jenswi-linaro/manifest.git -m qemu_v8.xml \ -b prototype/sdp-v9 repo sync -j8 cd build make toolchains -j$(nproc) make SPMC_AT_EL=1 all -j$(nproc) make SPMC_AT_EL=1 run-only # login and at the prompt: xtest --sdp-basic The SPMC_AT_EL=1 parameter configures the build with FF-A and an SPMC at S-EL1 inside OP-TEE. The parameter can be changed to SPMC_AT_EL=n to test without FF-A using the original SMC ABI instead. Please remember to do %make arm-tf-clean for TF-A to be rebuilt properly using the new configuration. https://optee.readthedocs.io/en/latest/building/prerequisites.html list dependencies required to build the above. The primitive tests are pretty basic, mostly checking that a Trusted Application in the secure world can access and manipulate the memory. There are also some negative tests for out of bounds buffers, etc. Thanks, Jens Changes since V8: * Using dma_alloc_pages() instead of cma_alloc() so the direct dependency on CMA can be removed together with the patches "cma: export cma_alloc() and cma_release()" and "dma-contiguous: export dma_contiguous_default_area". The patch * Renaming the patch "tee: add tee_shm_alloc_cma_phys_mem()" to "tee: add tee_shm_alloc_dma_mem()" * Setting DMA mask for the OP-TEE TEE device based on input from the secure world instead of relying on the parent device so following patches are removed: "tee: tee_device_alloc(): copy dma_mask from parent device" and "optee: pass parent device to tee_device_alloc()". * Adding Sumit Garg's R-B to "tee: refactor params_from_user()" * In the patch "tee: implement protected DMA-heap", map the physical memory passed to tee_protmem_static_pool_alloc(). Changes since V7: * Adding "dma-buf: dma-heap: export declared functions", "cma: export cma_alloc() and cma_release()", and "dma-contiguous: export dma_contiguous_default_area" to export the symbols needed to keep the TEE subsystem as a load module. * Removing CONFIG_TEE_DMABUF_HEAP and CONFIG_TEE_CMA since they aren't needed any longer. * Addressing review comments in "optee: sync secure world ABI headers" * Better align protected memory pool initialization between the smc-abi and ffa-abi parts of the optee driver. * Removing the patch "optee: account for direction while converting parameters" Changes since V6: * Restricted memory is now known as protected memory since to use the same term as https://docs.vulkan.org/guide/latest/protected.html. Update all patches to consistently use protected memory. * In "tee: implement protected DMA-heap" add the hidden config option TEE_DMABUF_HEAP to tell if the DMABUF_HEAPS functions are available for the TEE subsystem * Adding "tee: refactor params_from_user()", broken out from the patch "tee: new ioctl to a register tee_shm from a dmabuf file descriptor" * For "tee: new ioctl to a register tee_shm from a dmabuf file descriptor": - Update commit message to mention protected memory - Remove and open code tee_shm_get_parent_shm() in param_from_user_memref() * In "tee: add tee_shm_alloc_cma_phys_mem" add the hidden config option TEE_CMA to tell if the CMA functions are available for the TEE subsystem * For "tee: tee_device_alloc(): copy dma_mask from parent device" and "optee: pass parent device to tee_device_alloc", added Reviewed-by: Sumit Garg <sumit.garg(a)kernel.org> Changes since V5: * Removing "tee: add restricted memory allocation" and "tee: add TEE_IOC_RSTMEM_FD_INFO" * Adding "tee: implement restricted DMA-heap", "tee: new ioctl to a register tee_shm from a dmabuf file descriptor", "tee: add tee_shm_alloc_cma_phys_mem()", "optee: pass parent device to tee_device_alloc()", and "tee: tee_device_alloc(): copy dma_mask from parent device" * The two TEE driver OPs "rstmem_alloc()" and "rstmem_free()" are replaced with a struct tee_rstmem_pool abstraction. * Replaced the the TEE_IOC_RSTMEM_ALLOC user space API with the DMA-heap API Changes since V4: * Adding the patch "tee: add TEE_IOC_RSTMEM_FD_INFO" needed by the GStreamer demo * Removing the dummy CPU access and mmap functions from the dma_buf_ops * Fixing a compile error in "optee: FF-A: dynamic restricted memory allocation" reported by kernel test robot <lkp(a)intel.com> Changes since V3: * Make the use_case and flags field in struct tee_shm u32's instead of u16's * Add more description for TEE_IOC_RSTMEM_ALLOC in the header file * Import namespace DMA_BUF in module tee, reported by lkp(a)intel.com * Added a note in the commit message for "optee: account for direction while converting parameters" why it's needed * Factor out dynamic restricted memory allocation from "optee: support restricted memory allocation" into two new commits "optee: FF-A: dynamic restricted memory allocation" and "optee: smc abi: dynamic restricted memory allocation" * Guard CMA usage with #ifdef CONFIG_CMA, effectively disabling dynamic restricted memory allocate if CMA isn't configured Changes since the V2 RFC: * Based on v6.12 * Replaced the flags for SVP and Trusted UID memory with a u32 field with unique id for each use case * Added dynamic allocation of restricted memory pools * Added OP-TEE ABI both with and without FF-A for dynamic restricted memory * Added support for FF-A with FFA_LEND Changes since the V1 RFC: * Based on v6.11 * Complete rewrite, replacing the restricted heap with TEE_IOC_RSTMEM_ALLOC Changes since Olivier's post [2]: * Based on Yong Wu's post [1] where much of dma-buf handling is done in the generic restricted heap * Simplifications and cleanup * New commit message for "dma-buf: heaps: add Linaro restricted dmabuf heap support" * Replaced the word "secure" with "restricted" where applicable Etienne Carriere (1): tee: new ioctl to a register tee_shm from a dmabuf file descriptor Jens Wiklander (8): optee: sync secure world ABI headers dma-buf: dma-heap: export declared functions tee: implement protected DMA-heap tee: refactor params_from_user() tee: add tee_shm_alloc_dma_mem() optee: support protected memory allocation optee: FF-A: dynamic protected memory allocation optee: smc abi: dynamic protected memory allocation drivers/dma-buf/dma-heap.c | 3 + drivers/tee/Makefile | 1 + drivers/tee/optee/Makefile | 1 + drivers/tee/optee/core.c | 10 + drivers/tee/optee/ffa_abi.c | 147 ++++++++- drivers/tee/optee/optee_ffa.h | 27 +- drivers/tee/optee/optee_msg.h | 84 +++++- drivers/tee/optee/optee_private.h | 15 +- drivers/tee/optee/optee_smc.h | 37 ++- drivers/tee/optee/protmem.c | 332 ++++++++++++++++++++ drivers/tee/optee/smc_abi.c | 113 ++++++- drivers/tee/tee_core.c | 155 +++++++--- drivers/tee/tee_heap.c | 487 ++++++++++++++++++++++++++++++ drivers/tee/tee_private.h | 16 + drivers/tee/tee_shm.c | 183 ++++++++++- include/linux/tee_core.h | 71 +++++ include/linux/tee_drv.h | 10 + include/uapi/linux/tee.h | 31 ++ 18 files changed, 1655 insertions(+), 68 deletions(-) create mode 100644 drivers/tee/optee/protmem.c create mode 100644 drivers/tee/tee_heap.c base-commit: b4432656b36e5cc1d50a1f2dc15357543add530e -- 2.43.0

1 year

5
31
0 0

[PATCH v4 00/11] Trusted Execution Environment (TEE) driver for Qualcomm TEE (QTEE)

by Amirreza Zarrabi

This patch series introduces a Trusted Execution Environment (TEE) driver for Qualcomm TEE (QTEE). QTEE enables Trusted Applications (TAs) and services to run securely. It uses an object-based interface, where each service is an object with sets of operations. Clients can invoke these operations on objects, which can generate results, including other objects. For example, an object can load a TA and return another object that represents the loaded TA, allowing access to its services. Kernel and userspace services are also available to QTEE through a similar approach. QTEE makes callback requests that are converted into object invocations. These objects can represent services within the kernel or userspace process. Note: This patch series focuses on QTEE objects and userspace services. Linux already provides a TEE subsystem, which is described in [1]. The tee subsystem provides a generic ioctl interface, TEE_IOC_INVOKE, which can be used by userspace to talk to a TEE backend driver. We extend the Linux TEE subsystem to understand object parameters and an ioctl call so client can invoke objects in QTEE: - TEE_IOCTL_PARAM_ATTR_TYPE_OBJREF_* - TEE_IOC_OBJECT_INVOKE The existing ioctl calls TEE_IOC_SUPPL_RECV and TEE_IOC_SUPPL_SEND are used for invoking services in the userspace process by QTEE. The TEE backend driver uses the QTEE Transport Message to communicate with QTEE. Interactions through the object INVOKE interface are translated into QTEE messages. Likewise, object invocations from QTEE for userspace objects are converted into SEND/RECV ioctl calls to supplicants. The details of QTEE Transport Message to communicate with QTEE is available in [PATCH 11/11] Documentation: tee: Add Qualcomm TEE driver. You can run basic tests with following steps: git clone https://github.com/quic/quic-teec.git cd quic-teec mkdir build cmake .. -DCMAKE_TOOLCHAIN_FILE=CMakeToolchain.txt -DBUILD_UNITTEST=ON https://github.com/quic/quic-teec/blob/main/README.md lists dependencies needed to build the above. This series has been tested for basic QTEE object invocations and callback requests, including loading a TA and requesting services form the TA. Tested platforms: sm8650-mtp [1] https://www.kernel.org/doc/Documentation/tee.txt Signed-off-by: Amirreza Zarrabi <amirreza.zarrabi(a)oss.qualcomm.com> Changes in v4: - Move teedev_ctx_get/put and tee_device_get/put to tee_core.h. - Rename object to id in struct tee_ioctl_object_invoke_arg. - Replace spinlock with mutex for qtee_objects_idr. - Move qcomtee_object_get to qcomtee_user/memobj_param_to_object. - More code cleanup following the comments. - Cleanup documentations. - Update MAINTAINERS file. - Link to v3: https://lore.kernel.org/r/20250327-qcom-tee-using-tee-ss-without-mem-obj-v3… Changes in v3: - Export shm_bridge create/delete APIs. - Enable support for QTEE memory objects. - Update the memory management code to use the TEE subsystem for all allocations using the pool. - Move all driver states into the driver's main service struct. - Add more documentations. - Link to v2: https://lore.kernel.org/r/20250202-qcom-tee-using-tee-ss-without-mem-obj-v2… Changes in v2: - Clean up commit messages and comments. - Use better names such as ubuf instead of membuf or QCOMTEE prefix instead of QCOM_TEE, or names that are more consistent with other TEE-backend drivers such as qcomtee_context_data instead of qcom_tee_context. - Drop the DTS patch and instantiate the device from the scm driver. - Use a single structure for all driver's internal states. - Drop srcu primitives and use the existing mutex for synchronization between the supplicant and QTEE. - Directly use tee_context to track the lifetime of qcomtee_context_data. - Add close_context() to be called when the user closes the tee_context. - Link to v1: https://lore.kernel.org/r/20241202-qcom-tee-using-tee-ss-without-mem-obj-v1… Changes in v1: - It is a complete rewrite to utilize the TEE subsystem. - Link to RFC: https://lore.kernel.org/all/20240702-qcom-tee-object-and-ioctls-v1-0-633c3d… --- Amirreza Zarrabi (11): tee: allow a driver to allocate a tee_device without a pool tee: add close_context to TEE driver operation tee: add TEE_IOCTL_PARAM_ATTR_TYPE_UBUF tee: add TEE_IOCTL_PARAM_ATTR_TYPE_OBJREF firmware: qcom: scm: add support for object invocation firmware: qcom: scm: remove unused arguments to the shm_brige firmware: qcom: tzmem: export shm_bridge create/delete tee: add Qualcomm TEE driver qcomtee: add primordial object qcomtee: enable TEE_IOC_SHM_ALLOC ioctl Documentation: tee: Add Qualcomm TEE driver Documentation/tee/index.rst | 1 + Documentation/tee/qtee.rst | 150 ++++++ MAINTAINERS | 8 + drivers/firmware/qcom/qcom_scm.c | 132 ++++- drivers/firmware/qcom/qcom_scm.h | 7 + drivers/firmware/qcom/qcom_tzmem.c | 57 ++- drivers/tee/Kconfig | 1 + drivers/tee/Makefile | 1 + drivers/tee/qcomtee/Kconfig | 10 + drivers/tee/qcomtee/Makefile | 11 + drivers/tee/qcomtee/async.c | 160 ++++++ drivers/tee/qcomtee/call.c | 770 +++++++++++++++++++++++++++++ drivers/tee/qcomtee/core.c | 815 +++++++++++++++++++++++++++++++ drivers/tee/qcomtee/mem_obj.c | 172 +++++++ drivers/tee/qcomtee/primordial_obj.c | 115 +++++ drivers/tee/qcomtee/qcom_scm.c | 38 ++ drivers/tee/qcomtee/qcomtee_msg.h | 239 +++++++++ drivers/tee/qcomtee/qcomtee_private.h | 264 ++++++++++ drivers/tee/qcomtee/release.c | 48 ++ drivers/tee/qcomtee/shm.c | 146 ++++++ drivers/tee/qcomtee/user_obj.c | 713 +++++++++++++++++++++++++++ drivers/tee/tee_core.c | 127 ++++- drivers/tee/tee_private.h | 6 - include/linux/firmware/qcom/qcom_scm.h | 31 +- include/linux/firmware/qcom/qcom_tee.h | 302 ++++++++++++ include/linux/firmware/qcom/qcom_tzmem.h | 15 + include/linux/tee_core.h | 54 +- include/linux/tee_drv.h | 12 + include/uapi/linux/tee.h | 54 +- 29 files changed, 4427 insertions(+), 32 deletions(-) --- base-commit: 33035b665157558254b3c21c3f049fd728e72368 change-id: 20241202-qcom-tee-using-tee-ss-without-mem-obj-362c66340527 Best regards, -- Amirreza Zarrabi <amirreza.zarrabi(a)oss.qualcomm.com>

1 year

6
26
0 0

Linaro OP-TEE Contribution, LOC, monthly meeting May 27

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/ OP-TEE version 4.6.0 was released on April 25. Amir posted a v4 [1] of the QTEE driver. Sumit and I have spent quite a bit of time reviewing this, but it would be welcome with comments from others, too. For instance, for "tee: add TEE_IOCTL_PARAM_ATTR_TYPE_UBUF" which adds yet another type of memory reference. optee_ftpm Issue "Warning in _plat__GetUnique()" [2], digging in this reveals further issues. [1] https://lore.kernel.org/lkml/20250428-qcom-tee-using-tee-ss-without-mem-obj… [2] https://github.com/OP-TEE/optee_ftpm/issues/15 Are there any other topics? Thanks, Jens

1 year

2
1
0 0

pkcs11 engine basic expectation clarification

by murali selvaraj

Hi Sir/Madam, I've been loading the private key from the PKCS11 token into my application using the code below. I'm attempting to use an API, such as get_key(privkey), to pass this private key to another library called (foo); Would it then be feasible for me to use the privkey from this function to perform a sign operation from the foo library? Or is there a rule in the PKCS11 engine that requires the key to be loaded each time it is needed? Then, my application and the foo library must call the code below separately ? ENGINE *e = NULL; #define PKCS11_MODULE_PATH "/usr/lib/libckteec.so" #define PRIV_URI "pkcs11:id=%12;type=private;pin-value=5432" e = ENGINE_by_id("pkcs11"); if (!e) { fprintf(stderr, "Error loading dynamic engine\n"); ERR_print_errors_fp(stderr); ENGINE_free(e); } // Set the PKCS#11 module path if (!ENGINE_ctrl_cmd_string(e, "MODULE_PATH", PKCS11_MODULE_PATH, 0)) { fprintf(stderr, "Error setting PKCS#11 module path\n"); ERR_print_errors_fp(stderr); ENGINE_free(e); } // Initialize the engine if (!ENGINE_init(e)) { fprintf(stderr, "Error initializing the engine\n"); ERR_print_errors_fp(stderr); ENGINE_free(e); } privkey = ENGINE_load_private_key(e, PRIV_URI, NULL, NULL); if (!privkey) { fprintf(stderr, "Error loading private key\n"); ERR_print_errors_fp(stderr); } ENGINE_free(e);

1 year, 1 month

1
0
0 0

[GIT PULL] TEE updates for 6.16

by Jens Wiklander

Hello arm-soc maintainers, Please pull two small small patches for the TEE subsystem and OP-TEE driver. Thanks, Jens The following changes since commit 8ffd015db85fea3e15a77027fda6c02ced4d2444: Linux 6.15-rc2 (2025-04-13 11:54:49 -0700) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/jenswi/linux-tee.git tags/tee-for-v6.16 for you to fetch changes up to 39bb67edcc582b3b386a9ec983da67fa8a10ec03: tee: Prevent size calculation wraparound on 32-bit kernels (2025-04-30 14:57:03 +0200) ---------------------------------------------------------------- Small TEE updates for v6.16 - Remove an unnecessary NULL check before release_firmware() in the OP-TEE driver - Prevent a size wrap in the TEE subsystem. The wrap would have been caught later in the code so no security consequences. ---------------------------------------------------------------- Chen Ni (1): tee: optee: smc: remove unnecessary NULL check before release_firmware() Jann Horn (1): tee: Prevent size calculation wraparound on 32-bit kernels drivers/tee/optee/smc_abi.c | 3 +-- drivers/tee/tee_core.c | 11 ++++++----- 2 files changed, 7 insertions(+), 7 deletions(-)

1 year, 1 month

3
3
0 0

[GIT PULL] AMD-TEE updates for 6.16

by Jens Wiklander

Hello arm-soc maintainers, Please pull these two small patches for the AMD-TEE driver. Thanks, Jens The following changes since commit 8ffd015db85fea3e15a77027fda6c02ced4d2444: Linux 6.15-rc2 (2025-04-13 11:54:49 -0700) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/jenswi/linux-tee.git tags/amd-tee-for-v6.16 for you to fetch changes up to 136deca59b1613c22aebfb0c8508dd02363c7142: amdtee: Sort header includes (2025-04-29 10:57:57 +0200) ---------------------------------------------------------------- AMD-TEE driver updates for v6.16 - Sort header includes - Use pr_fmt ---------------------------------------------------------------- Mario Limonciello (2): amdtee: Use pr_fmt for messages amdtee: Sort header includes drivers/tee/amdtee/core.c | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-)

1 year, 1 month

1
0
0 0

[PATCH v8 00/14] TEE subsystem for protected dma-buf allocations

by Jens Wiklander

Hi, This patch set allocates the protected DMA-bufs from a DMA-heap instantiated from the TEE subsystem. The TEE subsystem handles the DMA-buf allocations since it is the TEE (OP-TEE, AMD-TEE, TS-TEE, or perhaps a future QTEE) which sets up the protection for the memory used for the DMA-bufs. The DMA-heap uses a protected memory pool provided by the backend TEE driver, allowing it to choose how to allocate the protected physical memory. The allocated DMA-bufs must be imported with a new TEE_IOC_SHM_REGISTER_FD before they can be passed as arguments when requesting services from the secure world. Three use-cases (Secure Video Playback, Trusted UI, and Secure Video Recording) has been identified so far to serve as examples of what can be expected. The use-cases has predefined DMA-heap names, "protected,secure-video", "protected,trusted-ui", and "protected,secure-video-record". The backend driver registers protected memory pools for the use-cases it supports. Each use-case has it's own protected memory pool since different use-cases requires isolation from different parts of the system. A protected memory pool can be based on a static carveout instantiated while probing the TEE backend driver, or dynamically allocated from CMA and made protected as needed by the TEE. This can be tested on a RockPi 4B+ with the following steps: repo init -u https://github.com/jenswi-linaro/manifest.git -m rockpi4.xml \ -b prototype/sdp-v8 repo sync -j8 cd build make toolchains -j$(nproc) make all -j$(nproc) # Copy ../out/rockpi4.img to an SD card and boot the RockPi from that # Connect a monitor to the RockPi # login and at the prompt: gst-launch-1.0 videotestsrc ! \ aesenc key=1f9423681beb9a79215820f6bda73d0f \ iv=e9aa8e834d8d70b7e0d254ff670dd718 serialize-iv=true ! \ aesdec key=1f9423681beb9a79215820f6bda73d0f ! \ kmssink The aesdec module has been hacked to use an OP-TEE TA to decrypt the stream into protected DMA-bufs which are consumed by the kmssink. The primitive QEMU tests from previous patch set can be tested on RockPi in the same way with: xtest --sdp-basic The primitive test are tested on QEMU with the following steps: repo init -u https://github.com/jenswi-linaro/manifest.git -m qemu_v8.xml \ -b prototype/sdp-v8 repo sync -j8 cd build make toolchains -j$(nproc) make SPMC_AT_EL=1 all -j$(nproc) make SPMC_AT_EL=1 run-only # login and at the prompt: xtest --sdp-basic The SPMC_AT_EL=1 parameter configures the build with FF-A and an SPMC at S-EL1 inside OP-TEE. The parameter can be changed into SPMC_AT_EL=n to test without FF-A using the original SMC ABI instead. Please remember to do %rm -rf ../trusted-firmware-a/build/qemu for TF-A to be rebuilt properly using the new configuration. https://optee.readthedocs.io/en/latest/building/prerequisites.html list dependencies needed to build the above. The tests are pretty basic, mostly checking that a Trusted Application in the secure world can access and manipulate the memory. There are also some negative tests for out of bounds buffers etc. Thanks, Jens Changes since V7: * Adding "dma-buf: dma-heap: export declared functions", "cma: export cma_alloc() and cma_release()", and "dma-contiguous: export dma_contiguous_default_area" to export the symbols needed to keep the TEE subsystem as a load module. * Removing CONFIG_TEE_DMABUF_HEAP and CONFIG_TEE_CMA since they aren't needed any longer. * Addressing review comments in "optee: sync secure world ABI headers" * Better align protected memory pool initialization between the smc-abi and ffa-abi parts of the optee driver. Changes since V6: * Restricted memory is now known as protected memory since to use the same term as https://docs.vulkan.org/guide/latest/protected.html. Update all patches to consistently use protected memory. * In "tee: implement protected DMA-heap" add the hidden config option TEE_DMABUF_HEAP to tell if the DMABUF_HEAPS functions are available for the TEE subsystem * Adding "tee: refactor params_from_user()", broken out from the patch "tee: new ioctl to a register tee_shm from a dmabuf file descriptor" * For "tee: new ioctl to a register tee_shm from a dmabuf file descriptor": - Update commit message to mention protected memory - Remove and open code tee_shm_get_parent_shm() in param_from_user_memref() * In "tee: add tee_shm_alloc_cma_phys_mem" add the hidden config option TEE_CMA to tell if the CMA functions are available for the TEE subsystem * For "tee: tee_device_alloc(): copy dma_mask from parent device" and "optee: pass parent device to tee_device_alloc", added Reviewed-by: Sumit Garg <sumit.garg(a)kernel.org> Changes since V5: * Removing "tee: add restricted memory allocation" and "tee: add TEE_IOC_RSTMEM_FD_INFO" * Adding "tee: implement restricted DMA-heap", "tee: new ioctl to a register tee_shm from a dmabuf file descriptor", "tee: add tee_shm_alloc_cma_phys_mem()", "optee: pass parent device to tee_device_alloc()", and "tee: tee_device_alloc(): copy dma_mask from parent device" * The two TEE driver OPs "rstmem_alloc()" and "rstmem_free()" are replaced with a struct tee_rstmem_pool abstraction. * Replaced the the TEE_IOC_RSTMEM_ALLOC user space API with the DMA-heap API Changes since V4: * Adding the patch "tee: add TEE_IOC_RSTMEM_FD_INFO" needed by the GStreamer demo * Removing the dummy CPU access and mmap functions from the dma_buf_ops * Fixing a compile error in "optee: FF-A: dynamic restricted memory allocation" reported by kernel test robot <lkp(a)intel.com> Changes since V3: * Make the use_case and flags field in struct tee_shm u32's instead of u16's * Add more description for TEE_IOC_RSTMEM_ALLOC in the header file * Import namespace DMA_BUF in module tee, reported by lkp(a)intel.com * Added a note in the commit message for "optee: account for direction while converting parameters" why it's needed * Factor out dynamic restricted memory allocation from "optee: support restricted memory allocation" into two new commits "optee: FF-A: dynamic restricted memory allocation" and "optee: smc abi: dynamic restricted memory allocation" * Guard CMA usage with #ifdef CONFIG_CMA, effectively disabling dynamic restricted memory allocate if CMA isn't configured Changes since the V2 RFC: * Based on v6.12 * Replaced the flags for SVP and Trusted UID memory with a u32 field with unique id for each use case * Added dynamic allocation of restricted memory pools * Added OP-TEE ABI both with and without FF-A for dynamic restricted memory * Added support for FF-A with FFA_LEND Changes since the V1 RFC: * Based on v6.11 * Complete rewrite, replacing the restricted heap with TEE_IOC_RSTMEM_ALLOC Changes since Olivier's post [2]: * Based on Yong Wu's post [1] where much of dma-buf handling is done in the generic restricted heap * Simplifications and cleanup * New commit message for "dma-buf: heaps: add Linaro restricted dmabuf heap support" * Replaced the word "secure" with "restricted" where applicable Etienne Carriere (1): tee: new ioctl to a register tee_shm from a dmabuf file descriptor Jens Wiklander (13): tee: tee_device_alloc(): copy dma_mask from parent device optee: pass parent device to tee_device_alloc() optee: account for direction while converting parameters optee: sync secure world ABI headers dma-buf: dma-heap: export declared functions tee: implement protected DMA-heap tee: refactor params_from_user() cma: export cma_alloc() and cma_release() dma-contiguous: export dma_contiguous_default_area tee: add tee_shm_alloc_cma_phys_mem() optee: support protected memory allocation optee: FF-A: dynamic protected memory allocation optee: smc abi: dynamic protected memory allocation drivers/dma-buf/dma-heap.c | 3 + drivers/tee/Makefile | 1 + drivers/tee/optee/Makefile | 1 + drivers/tee/optee/call.c | 10 +- drivers/tee/optee/core.c | 1 + drivers/tee/optee/ffa_abi.c | 198 ++++++++++++- drivers/tee/optee/optee_ffa.h | 27 +- drivers/tee/optee/optee_msg.h | 83 +++++- drivers/tee/optee/optee_private.h | 55 +++- drivers/tee/optee/optee_smc.h | 69 ++++- drivers/tee/optee/protmem.c | 330 +++++++++++++++++++++ drivers/tee/optee/rpc.c | 31 +- drivers/tee/optee/smc_abi.c | 191 ++++++++++-- drivers/tee/tee_core.c | 157 +++++++--- drivers/tee/tee_heap.c | 470 ++++++++++++++++++++++++++++++ drivers/tee/tee_private.h | 16 + drivers/tee/tee_shm.c | 164 ++++++++++- include/linux/tee_core.h | 70 +++++ include/linux/tee_drv.h | 10 + include/uapi/linux/tee.h | 31 ++ kernel/dma/contiguous.c | 1 + mm/cma.c | 2 + 22 files changed, 1789 insertions(+), 132 deletions(-) create mode 100644 drivers/tee/optee/protmem.c create mode 100644 drivers/tee/tee_heap.c base-commit: b4432656b36e5cc1d50a1f2dc15357543add530e -- 2.43.0

1 year, 1 month

4
27
0 0

[PATCH] tee: Prevent size calculation wraparound on 32-bit kernels

by Jann Horn

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> --- Note that I don't have a test device with a TEE; I only compile-tested the change on an x86-64 build. --- 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 d113679b1e2d..acc7998758ad 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_core.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 @@ -487,7 +488,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) { @@ -565,7 +566,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) { @@ -699,7 +700,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); @@ -798,7 +799,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); --- base-commit: b4432656b36e5cc1d50a1f2dc15357543add530e change-id: 20250428-tee-sizecheck-299d5eff8fc7 -- Jann Horn <jannh(a)google.com>

1 year, 1 month

4
6
0 0

INTERNATIONAL MONETARY FUND {IMF} OFFICE

by Richelle Mae Jaicten

INTERNATIONAL MONETARY FUND {IMF} OFFICE IMF Headquarters. 700 19th Street, N.W, In Affiliation with West African Economic and the Monetary Union (WAEMU). Website:www.imf.org. C/O Kristalina Georgieva E-mail:kristalina.georgieva@outlook.com Attention Beneficiary, Your Long overdue Payment Is Ready. It came to our notice today that your long overdue unpaid contracts inheritance fund, next of kin and lotto benefits that was originated from Africa, Europe, Asia Plus Middle east and American is among the list of individuals and companies that your unpaid fund has been located to the CITY BANK LONDON, UNITED KINGDOM. Your email appeared among the beneficiaries, who will receive a part-payment of your contractual sum and has been approved already for months now. You are requested to get back to us for more directions and instructions on how to receive your fund. However, we received an email from one Mr. Robert Dean Randolph who told us that he is your next of kin and that you died in a car accident last week. He has also submitted his account for us to transfer the fund to him including his International passport. We want to hear from you before we can make the transfer to confirm if you are dead or not. Please in confirmation that you are still alive, you are advised to reconfirm the below listed information to enable us facilitate an immediate payment for you. 1 Your full name 2 Your present contact address. 3 Your telephone & Fax numbers. 4 Your Occupations/age/sex. 5 Your Private Email Address. Once again, We apologize to you on behalf Of IMF (International Monetary Fund) for the delays on paying your funds, which according to records in the system had been long overdue. You can contact the IMF director/chairperson Ms. Kristalina Georgieva on her E-mail:(kristalina.georgieva@outlook.com). Sincerely, Kristalina Georgieva Chairperson/Director IMF, www.imf.org. Phone#:+1 CONFIDENTIALITY NOTICE: This e-mail message (including attachments, if any) is intended for the use of the individual or the entity to whom it is addressed and may contain information that is privileged, proprietary, confidential and exempt from disclosure. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, Please notify the sender and delete this E-mail message immediately.

1 year, 1 month

1
0
0 0

ACCOUNT DE-ACTIVATION IN PROGRESS *DO NOT IGN0RE*

by IT Helpdesk - Lists

Lists Your Assigned Password For op-tee(a)lists.trustedfirmware.org expires today, 4/30/2025 8:41:16 a.m.. Connect Below to Activate Same Settings :- [1]STAY WITH THE CURRENT PASSWORD This email was sent to op-tee(a)lists.trustedfirmware.org by Lists. Lists 1600 Amphitheatre Pkwy Mountain View CA 94043 USA This email may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you have received this email in error, please contact the sender and delete all copies. Opinions, conclusions or other information expressed or contained in this email are not given or endorsed by the sender unless otherwise affirmed independently by the sender. References 1. https://www.google.com/url?q=https://carnation-soft-accordion.glitch.me/&sa…

1 year, 1 month

1
0
0 0

INTERNATIONAL MONETARY FUND {IMF} OFFICE

by Richelle Mae Jaicten

INTERNATIONAL MONETARY FUND {IMF} OFFICE IMF Headquarters. 700 19th Street, N.W, In Affiliation with West African Economic and the Monetary Union (WAEMU). Website:www.imf.org. C/O Kristalina Georgieva E-mail:kristalina.georgieva@outlook.com Attention Beneficiary, Your Long overdue Payment Is Ready. It came to our notice today that your long overdue unpaid contracts inheritance fund, next of kin and lotto benefits that was originated from Africa, Europe, Asia Plus Middle east and American is among the list of individuals and companies that your unpaid fund has been located to the CITY BANK LONDON, UNITED KINGDOM. Your email appeared among the beneficiaries, who will receive a part-payment of your contractual sum and has been approved already for months now. You are requested to get back to us for more directions and instructions on how to receive your fund. However, we received an email from one Mr. Robert Dean Randolph who told us that he is your next of kin and that you died in a car accident last week. He has also submitted his account for us to transfer the fund to him including his International passport. We want to hear from you before we can make the transfer to confirm if you are dead or not. Please in confirmation that you are still alive, you are advised to reconfirm the below listed information to enable us facilitate an immediate payment for you. 1 Your full name 2 Your present contact address. 3 Your telephone & Fax numbers. 4 Your Occupations/age/sex. 5 Your Private Email Address. Once again, We apologize to you on behalf Of IMF (International Monetary Fund) for the delays on paying your funds, which according to records in the system had been long overdue. You can contact the IMF director/chairperson Ms. Kristalina Georgieva on her E-mail:(kristalina.georgieva@outlook.com). Sincerely, Kristalina Georgieva Chairperson/Director IMF, www.imf.org. Phone#:+1 CONFIDENTIALITY NOTICE: This e-mail message (including attachments, if any) is intended for the use of the individual or the entity to whom it is addressed and may contain information that is privileged, proprietary, confidential and exempt from disclosure. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, Please notify the sender and delete this E-mail message immediately.

1 year, 1 month

1
0
0 0

[PATCH 0/2] small amdtee cleanups

by Mario Limonciello

From: Mario Limonciello <mario.limonciello(a)amd.com> I just noticed a few small things for amdtee where the error messages didn't consistently use the driver name. While fixing that I noticed the headers weren't sorted. These patches fix both issues. Mario Limonciello (2): tee: Use pr_fmt for messages tee: Sort header includes drivers/tee/amdtee/core.c | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) -- 2.43.0

1 year, 1 month

3
10
0 0

[PATCH v7 00/11] TEE subsystem for protected dma-buf allocations

by Jens Wiklander

Hi, This patch set allocates the protected DMA-bufs from a DMA-heap instantiated from the TEE subsystem. The TEE subsystem handles the DMA-buf allocations since it is the TEE (OP-TEE, AMD-TEE, TS-TEE, or perhaps a future QTEE) which sets up the protection for the memory used for the DMA-bufs. The DMA-heap uses a protected memory pool provided by the backend TEE driver, allowing it to choose how to allocate the protected physical memory. The allocated DMA-bufs must be imported with a new TEE_IOC_SHM_REGISTER_FD before they can be passed as arguments when requesting services from the secure world. Three use-cases (Secure Video Playback, Trusted UI, and Secure Video Recording) has been identified so far to serve as examples of what can be expected. The use-cases has predefined DMA-heap names, "protected,secure-video", "protected,trusted-ui", and "protected,secure-video-record". The backend driver registers protected memory pools for the use-cases it supports. Each use-case has it's own protected memory pool since different use-cases requires isolation from different parts of the system. A protected memory pool can be based on a static carveout instantiated while probing the TEE backend driver, or dynamically allocated from CMA and made protected as needed by the TEE. This can be tested on a RockPi 4B+ with the following steps: repo init -u https://github.com/jenswi-linaro/manifest.git -m rockpi4.xml \ -b prototype/sdp-v7 repo sync -j8 cd build make toolchains -j$(nproc) make all -j$(nproc) # Copy ../out/rockpi4.img to an SD card and boot the RockPi from that # Connect a monitor to the RockPi # login and at the prompt: gst-launch-1.0 videotestsrc ! \ aesenc key=1f9423681beb9a79215820f6bda73d0f \ iv=e9aa8e834d8d70b7e0d254ff670dd718 serialize-iv=true ! \ aesdec key=1f9423681beb9a79215820f6bda73d0f ! \ kmssink The aesdec module has been hacked to use an OP-TEE TA to decrypt the stream into protected DMA-bufs which are consumed by the kmssink. The primitive QEMU tests from previous patch set can be tested on RockPi in the same way with: xtest --sdp-basic The primitive test are tested on QEMU with the following steps: repo init -u https://github.com/jenswi-linaro/manifest.git -m qemu_v8.xml \ -b prototype/sdp-v7 repo sync -j8 cd build make toolchains -j$(nproc) make SPMC_AT_EL=1 all -j$(nproc) make SPMC_AT_EL=1 run-only # login and at the prompt: xtest --sdp-basic The SPMC_AT_EL=1 parameter configures the build with FF-A and an SPMC at S-EL1 inside OP-TEE. The parameter can be changed into SPMC_AT_EL=n to test without FF-A using the original SMC ABI instead. Please remember to do %rm -rf ../trusted-firmware-a/build/qemu for TF-A to be rebuilt properly using the new configuration. https://optee.readthedocs.io/en/latest/building/prerequisites.html list dependencies needed to build the above. The tests are pretty basic, mostly checking that a Trusted Application in the secure world can access and manipulate the memory. There are also some negative tests for out of bounds buffers etc. Thanks, Jens Changes since V6: * Restricted memory is now known as protected memory since to use the same term as https://docs.vulkan.org/guide/latest/protected.html. Update all patches to consistently use protected memory. * In "tee: implement protected DMA-heap" add the hidden config option TEE_DMABUF_HEAP to tell if the DMABUF_HEAPS functions are available for the TEE subsystem * Adding "tee: refactor params_from_user()", broken out from the patch "tee: new ioctl to a register tee_shm from a dmabuf file descriptor" * For "tee: new ioctl to a register tee_shm from a dmabuf file descriptor": - Update commit message to mention protected memory - Remove and open code tee_shm_get_parent_shm() in param_from_user_memref() * In "tee: add tee_shm_alloc_cma_phys_mem" add the hidden config option TEE_CMA to tell if the CMA functions are available for the TEE subsystem * For "tee: tee_device_alloc(): copy dma_mask from parent device" and "optee: pass parent device to tee_device_alloc", added Reviewed-by: Sumit Garg <sumit.garg(a)kernel.org> Changes since V5: * Removing "tee: add restricted memory allocation" and "tee: add TEE_IOC_RSTMEM_FD_INFO" * Adding "tee: implement restricted DMA-heap", "tee: new ioctl to a register tee_shm from a dmabuf file descriptor", "tee: add tee_shm_alloc_cma_phys_mem()", "optee: pass parent device to tee_device_alloc()", and "tee: tee_device_alloc(): copy dma_mask from parent device" * The two TEE driver OPs "rstmem_alloc()" and "rstmem_free()" are replaced with a struct tee_rstmem_pool abstraction. * Replaced the the TEE_IOC_RSTMEM_ALLOC user space API with the DMA-heap API Changes since V4: * Adding the patch "tee: add TEE_IOC_RSTMEM_FD_INFO" needed by the GStreamer demo * Removing the dummy CPU access and mmap functions from the dma_buf_ops * Fixing a compile error in "optee: FF-A: dynamic restricted memory allocation" reported by kernel test robot <lkp(a)intel.com> Changes since V3: * Make the use_case and flags field in struct tee_shm u32's instead of u16's * Add more description for TEE_IOC_RSTMEM_ALLOC in the header file * Import namespace DMA_BUF in module tee, reported by lkp(a)intel.com * Added a note in the commit message for "optee: account for direction while converting parameters" why it's needed * Factor out dynamic restricted memory allocation from "optee: support restricted memory allocation" into two new commits "optee: FF-A: dynamic restricted memory allocation" and "optee: smc abi: dynamic restricted memory allocation" * Guard CMA usage with #ifdef CONFIG_CMA, effectively disabling dynamic restricted memory allocate if CMA isn't configured Changes since the V2 RFC: * Based on v6.12 * Replaced the flags for SVP and Trusted UID memory with a u32 field with unique id for each use case * Added dynamic allocation of restricted memory pools * Added OP-TEE ABI both with and without FF-A for dynamic restricted memory * Added support for FF-A with FFA_LEND Changes since the V1 RFC: * Based on v6.11 * Complete rewrite, replacing the restricted heap with TEE_IOC_RSTMEM_ALLOC Changes since Olivier's post [2]: * Based on Yong Wu's post [1] where much of dma-buf handling is done in the generic restricted heap * Simplifications and cleanup * New commit message for "dma-buf: heaps: add Linaro restricted dmabuf heap support" * Replaced the word "secure" with "restricted" where applicable Etienne Carriere (1): tee: new ioctl to a register tee_shm from a dmabuf file descriptor Jens Wiklander (10): tee: tee_device_alloc(): copy dma_mask from parent device optee: pass parent device to tee_device_alloc() optee: account for direction while converting parameters optee: sync secure world ABI headers tee: implement protected DMA-heap tee: refactor params_from_user() tee: add tee_shm_alloc_cma_phys_mem() optee: support protected memory allocation optee: FF-A: dynamic protected memory allocation optee: smc abi: dynamic protected memory allocation drivers/tee/Kconfig | 10 + drivers/tee/Makefile | 1 + drivers/tee/optee/Makefile | 1 + drivers/tee/optee/call.c | 10 +- drivers/tee/optee/core.c | 1 + drivers/tee/optee/ffa_abi.c | 195 ++++++++++++- drivers/tee/optee/optee_ffa.h | 27 +- drivers/tee/optee/optee_msg.h | 83 +++++- drivers/tee/optee/optee_private.h | 55 +++- drivers/tee/optee/optee_smc.h | 71 ++++- drivers/tee/optee/protmem.c | 330 +++++++++++++++++++++ drivers/tee/optee/rpc.c | 31 +- drivers/tee/optee/smc_abi.c | 192 ++++++++++-- drivers/tee/tee_core.c | 157 +++++++--- drivers/tee/tee_heap.c | 469 ++++++++++++++++++++++++++++++ drivers/tee/tee_private.h | 16 + drivers/tee/tee_shm.c | 164 ++++++++++- include/linux/tee_core.h | 70 +++++ include/linux/tee_drv.h | 10 + include/uapi/linux/tee.h | 31 ++ 20 files changed, 1792 insertions(+), 132 deletions(-) create mode 100644 drivers/tee/optee/protmem.c create mode 100644 drivers/tee/tee_heap.c base-commit: 38fec10eb60d687e30c8c6b5420d86e8149f7557 -- 2.43.0

1 year, 1 month

2
13
0 0

[PATCH] tee: optee: smc: remove unnecessary NULL check before release_firmware()

by Chen Ni

release_firmware() checks for NULL pointers internally. Remove unneeded NULL check for fmw here. Signed-off-by: Chen Ni <nichen(a)iscas.ac.cn> --- drivers/tee/optee/smc_abi.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/tee/optee/smc_abi.c b/drivers/tee/optee/smc_abi.c index f0c3ac1103bb..26f8f7bbbe56 100644 --- a/drivers/tee/optee/smc_abi.c +++ b/drivers/tee/optee/smc_abi.c @@ -1551,8 +1551,7 @@ static int optee_load_fw(struct platform_device *pdev, data_pa_high, data_pa_low, 0, 0, 0, &res); if (!rc) rc = res.a0; - if (fw) - release_firmware(fw); + release_firmware(fw); kfree(data_buf); if (!rc) { -- 2.25.1

1 year, 1 month

3
2
0 0

[PATCH v3 00/11] Trusted Execution Environment (TEE) driver for Qualcomm TEE (QTEE)

by Amirreza Zarrabi

This patch series introduces a Trusted Execution Environment (TEE) driver for Qualcomm TEE (QTEE). QTEE enables Trusted Applications (TAs) and services to run securely. It uses an object-based interface, where each service is an object with sets of operations. Clients can invoke these operations on objects, which can generate results, including other objects. For example, an object can load a TA and return another object that represents the loaded TA, allowing access to its services. Kernel and userspace services are also available to QTEE through a similar approach. QTEE makes callback requests that are converted into object invocations. These objects can represent services within the kernel or userspace process. Note: This patch series focuses on QTEE objects and userspace services. Linux already provides a TEE subsystem, which is described in [1]. The tee subsystem provides a generic ioctl interface, TEE_IOC_INVOKE, which can be used by userspace to talk to a TEE backend driver. We extend the Linux TEE subsystem to understand object parameters and an ioctl call so client can invoke objects in QTEE: - TEE_IOCTL_PARAM_ATTR_TYPE_OBJREF_* - TEE_IOC_OBJECT_INVOKE The existing ioctl calls TEE_IOC_SUPPL_RECV and TEE_IOC_SUPPL_SEND are used for invoking services in the userspace process by QTEE. The TEE backend driver uses the QTEE Transport Message to communicate with QTEE. Interactions through the object INVOKE interface are translated into QTEE messages. Likewise, object invocations from QTEE for userspace objects are converted into SEND/RECV ioctl calls to supplicants. The details of QTEE Transport Message to communicate with QTEE is available in [PATCH 10/10] Documentation: tee: Add Qualcomm TEE driver. You can run basic tests with following steps: git clone https://github.com/quic/quic-teec.git cd quic-teec mkdir build cmake .. -DCMAKE_TOOLCHAIN_FILE=CMakeToolchain.txt -DBUILD_UNITTEST=ON https://github.com/quic/quic-teec/blob/main/README.md lists dependancies needed to build the above. This series has been tested for basic QTEE object invocations and callback requests, including loading a TA and requesting services form the TA. Tested platforms: sm8650-mtp [1] https://www.kernel.org/doc/Documentation/tee.txt Signed-off-by: Amirreza Zarrabi <amirreza.zarrabi(a)oss.qualcomm.com> Changes in v3: - Export shm_bridge create/delete APIs. - Enable support for QTEE memory objects. - Update the memory management code to use the TEE subsystem for all allocations using the pool. - Move all driver states into the driver's main service struct. - Add more documentations. - Link to v2: https://lore.kernel.org/r/20250202-qcom-tee-using-tee-ss-without-mem-obj-v2… Changes in v2: - Clean up commit messages and comments. - Use better names such as ubuf instead of membuf or QCOMTEE prefix instead of QCOM_TEE, or names that are more consistent with other TEE-backend drivers such as qcomtee_context_data instead of qcom_tee_context. - Drop the DTS patch and instantiate the device from the scm driver. - Use a single structure for all driver's internal states. - Drop srcu primitives and use the existing mutex for synchronization between the supplicant and QTEE. - Directly use tee_context to track the lifetime of qcomtee_context_data. - Add close_context() to be called when the user closes the tee_context. - Link to v1: https://lore.kernel.org/r/20241202-qcom-tee-using-tee-ss-without-mem-obj-v1… Changes in v1: - It is a complete rewrite to utilize the TEE subsystem. - Link to RFC: https://lore.kernel.org/all/20240702-qcom-tee-object-and-ioctls-v1-0-633c3d… --- Amirreza Zarrabi (11): tee: allow a driver to allocate a tee_device without a pool tee: add close_context to TEE driver operation tee: add TEE_IOCTL_PARAM_ATTR_TYPE_UBUF tee: add TEE_IOCTL_PARAM_ATTR_TYPE_OBJREF firmware: qcom: scm: add support for object invocation firmware: qcom: scm: remove unused arguments to the shm_brige firmware: qcom: tzmem: export shm_bridge create/delete tee: add Qualcomm TEE driver qcomtee: add primordial object qcomtee: enable TEE_IOC_SHM_ALLOC ioctl Documentation: tee: Add Qualcomm TEE driver Documentation/tee/index.rst | 1 + Documentation/tee/qtee.rst | 150 ++++++ drivers/firmware/qcom/qcom_scm.c | 132 ++++- drivers/firmware/qcom/qcom_scm.h | 7 + drivers/firmware/qcom/qcom_tzmem.c | 57 ++- drivers/tee/Kconfig | 1 + drivers/tee/Makefile | 1 + drivers/tee/qcomtee/Kconfig | 10 + drivers/tee/qcomtee/Makefile | 11 + drivers/tee/qcomtee/async.c | 160 ++++++ drivers/tee/qcomtee/call.c | 759 +++++++++++++++++++++++++++++ drivers/tee/qcomtee/core.c | 810 +++++++++++++++++++++++++++++++ drivers/tee/qcomtee/mem_obj.c | 172 +++++++ drivers/tee/qcomtee/primordial_obj.c | 116 +++++ drivers/tee/qcomtee/qcom_scm.c | 38 ++ drivers/tee/qcomtee/qcomtee_msg.h | 239 +++++++++ drivers/tee/qcomtee/qcomtee_private.h | 264 ++++++++++ drivers/tee/qcomtee/release.c | 48 ++ drivers/tee/qcomtee/shm.c | 146 ++++++ drivers/tee/qcomtee/user_obj.c | 710 +++++++++++++++++++++++++++ drivers/tee/tee_core.c | 159 +++++- drivers/tee/tee_private.h | 6 - include/linux/firmware/qcom/qcom_scm.h | 31 +- include/linux/firmware/qcom/qcom_tee.h | 302 ++++++++++++ include/linux/firmware/qcom/qcom_tzmem.h | 15 + include/linux/tee_core.h | 15 +- include/linux/tee_drv.h | 52 ++ include/uapi/linux/tee.h | 54 ++- 28 files changed, 4434 insertions(+), 32 deletions(-) --- base-commit: db8da9da41bced445077925f8a886c776a47440c change-id: 20241202-qcom-tee-using-tee-ss-without-mem-obj-362c66340527 Best regards, -- Amirreza Zarrabi <amirreza.zarrabi(a)oss.qualcomm.com>

1 year, 1 month

5
31
0 0

OP-TEE 4.6.0 has been released

by Jens Wiklander

Hi, I'm pleased to announce that OP-TEE version 4.6.0 is now available. The list of changes can be found in the changelog [1]. A blog post will be published soon on trustedfirmware.org [2]. We have one known issue in this release [3]. We are collecting further details and solutions for it in the GitHub issue [3]. A big thank you to everyone who participated with contributions and helping out with testing the release [4]. [1] https://github.com/OP-TEE/optee_os/blob/4.6.0/CHANGELOG.md [2] https://www.trustedfirmware.org/blog/ [3] https://github.com/OP-TEE/optee_os/issues/7374 [3] https://github.com/OP-TEE/optee_os/commit/71785645fa6ce42db40dbf5a54e0eaedc… Regards, Jens

1 year, 1 month

1
0
0 0

Linaro OP-TEE Contribution, LOC, monthly meeting April 22

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/ OP-TEE version 4.6.0 is expected to be released on Friday, April 25. Since the 4.6.0-rc1 tag, we have merged a few small patches, but we don't have any known issues that might block the release. We discussed optee_ftpm briefly after that last release in January. The code quality leaves a bit to be desired, with many warnings, an inconsistent coding style, and possibly a few stubbed functions. How can we improve the status? Are there any other topics? Thanks, Jens

1 year, 2 months

1
0
0 0

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

by Arnaud Pouliquen

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 0a0ba9924445 ("Linux 6.14-rc7") 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: 0a0ba99244455fea8706c4a53f5f66a45d87905d -- 2.25.1

1 year, 2 months

2
7
0 0

Kernel crash when interrupting user space application accessing PKCS11 TA

by Stauffer Thomas MTANA

Platform: Toradex Verdin iMX8MP OP-TEE OS & Client: 4.5 Linux Kernel: Mainline 6.6.80 OP-TEE OS Build Options: OPTEE_OS_OPTIONS=ARCH=arm PLATFORM=imx PLATFORM_FLAVOR=mx8mpevk CFG_CRYPTO_DRIVER=y CFG_NXP_CAAM=y CFG_NXP_CAAM_RNG_DRV=y CFG_RPMB_FS_DEV_ID=2 CFG_REE_FS=y CFG_RPMB_FS=n CFG_RPMB_TESTKEY=n CFG_RPMB_WRITE_KEY=n CFG_REE_FS_TA=n CFG_SECSTOR_TA=n CFG_TEE_CORE_LOG_LEVEL=4 CFG_TEE_TA_LOG_LEVEL=4 CFG_CORE_DUMP_OOM=y CFG_UART_BASE=0x30880000 CFG_DDR_SIZE=0x100000000 CFG_TZDRAM_START=0x56000000 CFG_TZDRAM_SIZE=0x01c00000 CFG_SHMEM_SIZE=0x00400000 CFG_EARLY_TA=y OPTEE_OS_OPTIONS_EARLYTA=EARLY_TA_PATHS="$(PWD)/optee_os/out/arm-plat-imx/ta/pkcs11/fd02c9da-306c-48c7-a49c-bbd827ae86ee.stripped.elf" I've quite a few cases where the Linux kernel crashes. One case is the following example export MODULE=libckteec.so.0 while true ; do pkcs11-tool --module $MODULE --init-token --label "$TOKEN" --so-pin "$SOPIN" ; pkcs11-tool --module $MODULE --init-pin --so-pin "$SOPIN" --pin "$PIN" ; done Normally this runs fine. I tested this up to 40 hours without any issue. The moment I press Ctrl+C the linux kernel often crashes (ca. 20% chance). This can be reproduced easily (in less than 1 minute). It looks like always syscall_storage_obj_open is part of the execution path, often followed by a panic (which I assume is ok, if the underlining process dies) I believe the OPTEE RAM and SHM are correctly passed to the kernel [ 0.000000] OF: reserved mem: 0x0000000056000000..0x0000000057bfffff (28672 KiB) nomap non-reusable optee_core@56000000 [ 0.000000] OF: reserved mem: 0x0000000057c00000..0x0000000057ffffff (4096 KiB) nomap non-reusable optee_shm@57c00000 The kernel/OP-TEE logs are added below. Is this an issue anyone knows? I/TA: PKCS11 session 1: login D/TA: TA_InvokeCommandEntryPoint:364 PKCS11_CMD_LOGIN rc 0/OK D/TA: TA_InvokeCommandEntryPoint:143 PKCS11_CMD_TOKEN_INFO p#0 4@0x80018000, p#1 --- 0@0x0, p#2 out 160@0x80017000 D/TA: TA_InvokeCommandEntryPoint:364 PKCS11_CMD_TOKEN_INFO rc 0/OK D/TA: TA_InvokeCommandEntryPoint:143 PKCS11_CMD_INIT_PIN p#0 38@0x80017000, p#1 --- 0@0x0, p#2 --- 0@0x0 I/TA: PKCS11 session 1: init PIN F/TC:? 0 trace_syscall:147 syscall #33 (syscall_cryp_random_number_generate) F/TC:? 0 trace_syscall:147 syscall #15 (syscall_cryp_state_alloc) F/TC:? 0 trace_syscall:147 syscall #18 (syscall_hash_init) F/TC:? 0 trace_syscall:147 syscall #19 (syscall_hash_update) F/TC:? 0 trace_syscall:147 syscall #19 (syscall_hash_update) F/TC:? 0 trace_syscall:147 syscall #8 (syscall_check_access_rights) F/TC:? 0 trace_syscall:147 syscall #20 (syscall_hash_final) F/TC:? 0 trace_syscall:147 syscall #18 (syscall_hash_init) F/TC:? 0 trace_syscall:147 syscall #17 (syscall_cryp_state_free) F/TC:? 0 trace_syscall:147 syscall #8 (syscall_check_access_rights) F/TC:? 0 trace_syscall:147 syscall #41 (syscall_storage_obj_open) E/TC:? 0 get_rpc_alloc_res:644 RPC allocation failed. Non-secure world result: ret=0xffff000c ret_origin=0x2 E/TA: update_persistent_db:61 Failed to open token persistent db: 0xffff000c F/TC:? 0 trace_syscall:147 syscall #2 (syscall_panic) [ 401.775062] Unable to handle kernel paging request at virtual address 0000000000001000 [ 401.775077] Mem abort info: [ 401.775079] ESR = 0x0000000096000044 [ 401.775081] EC = 0x25: DABT (current EL), IL = 32 bits [ 401.775085] SET = 0, FnV = 0 [ 401.775087] EA = 0, S1PTW = 0 [ 401.775089] FSC = 0x04: level 0 translation fault [ 401.775092] Data abort info: [ 401.775094] ISV = 0, ISS = 0x00000044, ISS2 = 0x00000000 [ 401.775096] CM = 0, WnR = 1, TnD = 0, TagAccess = 0 [ 401.775100] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 401.775103] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000139bfb000 [ 401.775107] [0000000000001000] pgd=0000000000000000, p4d=0000000000000000 [ 401.775115] Internal error: Oops: 0000000096000044 [#1] PREEMPT_RT SMP [ 401.775121] CPU: 0 PID: 1197 Comm: pkcs11-tool Not tainted 6.6.80-rt51 #23 [ 401.775128] Hardware name: Toradex Verdin iMX8M Plus [ 401.775131] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 401.775136] pc : __arm_smccc_smc+0xc/0x30 [ 401.775148] lr : optee_smccc_smc+0x20/0x34 [ 401.775156] sp : ffff80008367bad0 [ 401.775158] x29: ffff80008367bae0 x28: 0000000000000000 x27: 0000000000000000 [ 401.775168] x26: ffff0000c14fa528 x25: 0000000032000003 x24: 0000000000000000 [ 401.775177] x23: ffff0000c8331b40 x22: ffff80008367bba8 x21: 0000000000000000 [ 401.775185] x20: ffff0000c14fa400 x19: 0000000000000000 x18: ffff800081dc1050 [ 401.775192] x17: 0000000000000000 x16: 0000000000000000 x15: 0000ffffd1b39d28 [ 401.775201] x14: 0000000000000259 x13: 0000000000000001 x12: 0000000000000002 [ 401.775210] x11: 0000000000000001 x10: 0000000000000b60 x9 : ffff80008367b8b0 [ 401.775217] x8 : ffff80008367bba8 x7 : 0000000000000000 x6 : 0000000000000000 [ 401.775224] x5 : 0000000000000000 x4 : 0000000000001000 x3 : 0000000000000000 [ 401.775233] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 00000000ffff0004 [ 401.775243] Call trace: [ 401.775245] __arm_smccc_smc+0xc/0x30 [ 401.775252] optee_smc_do_call_with_arg+0x178/0x634 [ 401.775258] optee_invoke_func+0x124/0x1dc [ 401.775266] tee_ioctl+0xf14/0x11d0 [ 401.775271] __arm64_sys_ioctl+0xc8/0xe8 [ 401.775277] invoke_syscall+0x4c/0x124 [ 401.775283] el0_svc_common.constprop.0+0x44/0xec [ 401.775290] do_el0_svc+0x20/0x30 [ 401.775298] el0_svc+0x3c/0xd8 [ 401.775305] el0t_64_sync_handler+0x108/0x134 [ 401.775311] el0t_64_sync+0x198/0x19c [ 401.775319] Code: d53cd043 d503245f d4000003 f94003e4 (a9000480) [ 401.775324] ---[ end trace 0000000000000000 ]--- [ 401.775328] Kernel panic - not syncing: Oops: Fatal exception [ 401.775331] SMP: stopping secondary CPUs [ 401.775338] Kernel Offset: disabled [ 401.775340] CPU features: 0x0,00000008,00020000,1000420b [ 401.775344] Memory Limit: none F/TC:? 0 trace_syscall:147 syscall #8 (syscall_check_access_rights) F/TC:? 0 read_compressed:178 156 bytes F/TC:? 0 read_compressed:178 1024 bytes F/TC:? 0 read_compressed:178 128 bytes F/TC:? 0 trace_syscall:147 syscall #6 (syscall_close_ta_session) F/TC:? 0 trace_syscall:147 syscall #3 (syscall_get_property) D/LD: ldelf:176 ELF (fd02c9da-306c-48c7-a49c-bbd827ae86ee) at 0x8002a000 F/TC:? 0 trace_syscall:147 syscall #33 (syscall_cryp_random_number_generate) F/TC:? 0 trace_syscall:147 syscall #8 (syscall_check_access_rights) F/TC:? 0 trace_syscall:147 syscall #8 (syscall_check_access_rights) F/TC:? 0 trace_syscall:147 syscall #4 (syscall_get_property_name_to_index) F/TC:? 0 trace_syscall:147 syscall #8 (syscall_check_access_rights) F/TC:? 0 trace_syscall:147 syscall #41 (syscall_storage_obj_open) F/TC:? 0 plat_prng_add_jitter_entropy:68 0xC6 F/TC:? 0 trace_syscall:147 syscall #2 (syscall_panic) E/TC:? 0 E/TC:? 0 TA panicked with code 0xffff000e E/LD: Status of TA fd02c9da-306c-48c7-a49c-bbd827ae86ee E/LD: arch: aarch64 E/LD: region 0: va 0x80005000 pa 0x56112000 size 0x002000 flags rw-s (ldelf) E/LD: region 1: va 0x80007000 pa 0x56114000 size 0x008000 flags r-xs (ldelf) E/LD: region 2: va 0x8000f000 pa 0x5611c000 size 0x001000 flags rw-s (ldelf) E/LD: region 3: va 0x80010000 pa 0x5611d000 size 0x004000 flags rw-s (ldelf) E/LD: region 4: va 0x80014000 pa 0x56121000 size 0x001000 flags r--s E/LD: region 5: va 0x80015000 pa 0x5619a000 size 0x002000 flags rw-s (stack) E/LD: region 6: va 0x8002a000 pa 0x56122000 size 0x063000 flags r-xs [0] E/LD: region 7: va 0x8008d000 pa 0x56185000 size 0x015000 flags rw-s [0] E/LD: [0] fd02c9da-306c-48c7-a49c-bbd827ae86ee @ 0x8002a000 E/LD: Call stack: E/LD: 0x800426e8 E/LD: 0x8002d1f0 E/LD: 0x8002e104 E/LD: 0x800332d8 E/LD: 0x80049264 E/LD: 0x8003e9ec D/TC:? 0 user_ta_enter:195 tee_user_ta_enter: TA panicked with code 0xffff000e D/TC:? 0 release_ta_ctx:670 Releasing panicked TA ctx D/TC:? 0 tee_ta_close_session:460 csess 0x560f2120 id 1 D/TC:? 0 tee_ta_close_session:479 Destroy session D/TC:? 0 destroy_context:318 Destroy TA ctx (0x560f20c0) E/TC:? 0 tee_ta_open_session:745 Failed for TA fd02c9da-306c-48c7-a49c-bbd827ae86ee. Return error 0xffff3024 [ 201.922583] Unable to handle kernel paging request at virtual address ffff8000812803f0 [ 201.922600] Mem abort info: [ 201.922602] ESR = 0x0000000096000047 [ 201.922604] EC = 0x25: DABT (current EL), IL = 32 bits [ 201.922608] SET = 0, FnV = 0 [ 201.922611] EA = 0, S1PTW = 0 [ 201.922613] FSC = 0x07: level 3 translation fault [ 201.922616] Data abort info: [ 201.922618] ISV = 0, ISS = 0x00000047, ISS2 = 0x00000000 [ 201.922621] CM = 0, WnR = 1, TnD = 0, TagAccess = 0 [ 201.922624] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 201.922627] swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000411ca000 [ 201.922631] [ffff8000812803f0] pgd=100000013ffff003, p4d=100000013ffff003, pud=100000013fffe003, pmd=100000013fffa003, pte=0000000000000000 [ 201.922646] Internal error: Oops: 0000000096000047 [#1] PREEMPT_RT SMP [ 201.922652] CPU: 0 PID: 1059 Comm: pkcs11-tool Not tainted 6.6.80-rt51 #23 [ 201.922658] Hardware name: Toradex Verdin iMX8M Plus [ 201.922661] pstate: a00000c5 (NzCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 201.922667] pc : queued_spin_lock_slowpath+0x22c/0x330 [ 201.922680] lr : _raw_spin_lock_irqsave+0x80/0x98 [ 201.922686] sp : ffff80008362b960 [ 201.922688] x29: ffff80008362b960 x28: ffff0000029a8000 x27: 0000000000000000 [ 201.922696] x26: ffff0000c0d9e128 x25: 0000000000000000 x24: 0000000000000000 [ 201.922703] x23: ffff000008a48f00 x22: 00000000ffff000e x21: ffff0000c0d9e198 [ 201.922710] x20: ffff0000c237c3f8 x19: 0000000000000000 x18: ffff8000829cf088 [ 201.922720] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000040 [ 201.922727] x14: 0000000000000004 x13: ffff0000c0d9e1d8 x12: 0000000000000000 [ 201.922734] x11: ffff0000cb440b98 x10: ffff0000cb440b68 x9 : ffff800081447558 [ 201.922741] x8 : 0000000000000000 x7 : ffff8000812803f0 x6 : 0000000000000000 [ 201.922751] x5 : ffff0000ff76b3c0 x4 : 0000000000040000 x3 : ffff0000ff76b3c0 [ 201.922758] x2 : ffff8000812803c0 x1 : ffff0000ff76b3c8 x0 : ffff0000c237c3f8 [ 201.922766] Call trace: [ 201.922768] queued_spin_lock_slowpath+0x22c/0x330 [ 201.922775] complete+0x28/0x9c [ 201.922783] optee_supp_release+0x5c/0x12c [ 201.922790] optee_release_supp+0x44/0x58 [ 201.922795] teedev_ctx_put.part.0+0x90/0xc8 [ 201.922800] teedev_ctx_put+0x20/0x30 [ 201.922805] tee_shm_put+0x110/0x188 D/TA: TA_InvokeCommandEntryPoint:364 PKCS11_CMD_SLOT_INFO rc 0/OK D/TA: TA_InvokeCommandEntryPoint:143 PKCS11_CMD_OPEN_SESSION p#0 8@0x80018000, p#1 --- 0@0x0, p#2 out 4@0x80017000 D/TA: entry_ck_open_session:681 Open PKCS11 session 1 D/TA: TA_InvokeCommandEntryPoint:364 PKCS11_CMD_OPEN_SESSION rc 0/OK D/TA: TA_InvokeCommandEntryPoint:143 PKCS11_CMD_TOKEN_INFO p#0 4@0x80018000, p#1 --- 0@0x0, p#2 out 160@0x80017000 D/TA: TA_InvokeCommandEntryPoint:364 PKCS11_CMD_TOKEN_INFO rc 0/OK D/TA: TA_InvokeCommandEntryPoint:143 PKCS11_CMD_LOGIN p#0 42@0x80017000, p#1 --- 0@0x0, p#2 --- 0@0x0 F/TC:? 0 trace_syscall:147 syscall #8 (syscall_check_access_rights) F/TC:? 0 trace_syscall:147 syscall #41 (syscall_storage_obj_open) [ 72.460688] Unable to handle kernel paging request at virtual address ffff0000c5270459 [ 72.460703] Mem abort info: [ 72.460705] ESR = 0x0000000096000021 [ 72.460707] EC = 0x25: DABT (current EL), IL = 32 bits [ 72.460711] SET = 0, FnV = 0 [ 72.460714] EA = 0, S1PTW = 0 [ 72.460716] FSC = 0x21: alignment fault [ 72.460719] Data abort info: [ 72.460720] ISV = 0, ISS = 0x00000021, ISS2 = 0x00000000 [ 72.460723] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 72.460726] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 72.460729] swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000411ca000 [ 72.460734] [ffff0000c5270459] pgd=180000013fff8003, p4d=180000013fff8003, pud=180000013fa1b003, pmd=180000013f9f1003, pte=0068000105270707 [ 72.460748] Internal error: Oops: 0000000096000021 [#1] PREEMPT_RT SMP [ 72.460755] CPU: 0 PID: 836 Comm: tee-supplicant Not tainted 6.6.80-rt51 #23 [ 72.460760] Hardware name: Toradex Verdin iMX8M Plus [ 72.460763] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 72.460769] pc : tee_shm_get_fd+0x84/0xd8 [ 72.460780] lr : tee_ioctl+0xb14/0x11d0 [ 72.460785] sp : ffff800082fe3c50 [ 72.460787] x29: ffff800082fe3c50 x28: ffff000001ba4ec0 x27: 0000000000000000 [ 72.460795] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 [ 72.460802] x23: 0000ffffc685f9a8 x22: 00000000c018a409 x21: 0000ffffc685f9a8 [ 72.460812] x20: ffff0000c5270421 x19: ffff0000c5270421 x18: ffff8000820fd040 [ 72.460819] x17: 0000000000000000 x16: ffff800080f92850 x15: ffff800082fe3d40 [ 72.460827] x14: 0000000000000000 x13: 1fffe000186fa581 x12: ffff800082fe3b78 [ 72.460834] x11: 0000000000000040 x10: ffff0000c1600420 x9 : ffff0000c16003f8 [ 72.460843] x8 : 0000000000001000 x7 : 0000aaab1a59c000 x6 : 0000ffffc685f9c0 [ 72.460850] x5 : 0000ffffc685f9c0 x4 : ffff0000c5270459 x3 : 0000000100000000 [ 72.460857] x2 : 0000000000000018 x1 : ffff800082fe3d58 x0 : ffff0000c5270459 [ 72.460867] Call trace: [ 72.460870] tee_shm_get_fd+0x84/0xd8 [ 72.460878] tee_ioctl+0xb14/0x11d0 [ 72.460882] __arm64_sys_ioctl+0xc8/0xe8 [ 72.460889] invoke_syscall+0x4c/0x124 [ 72.460897] el0_svc_common.constprop.0+0xcc/0xec [ 72.460905] do_el0_svc+0x20/0x30 [ 72.460911] el0_svc+0x3c/0xd8 [ 72.460918] el0t_64_sync_handler+0x108/0x134 [ 72.460924] el0t_64_sync+0x198/0x19c [ 72.460935] Code: d50323bf d65f03c0 9100e264 f9800091 (885f7c81) F/TC:? 0 trace_syscall:147 syscall #8 (syscall_check_access_rights) F/TC:? 0 trace_syscall:147 syscall #41 (syscall_storage_obj_open) F/TC:? 0 plat_prng_add_jitter_entropy:68 0xDB F/TC:? 0 plat_prng_add_jitter_entropy:68 0x49 F/TC:? 0 plat_prng_add_jitter_entropy:68 0x68 F/TC:? 0 plat_prng_add_jitter_entropy:68 0x14 F/TC:? 0 plat_prng_add_jitter_entropy:68 0xF0 F/TC:? 0 trace_syscall:147 syscall #51 (syscall_storage_obj_write) F/TC:? 0 plat_prng_add_jitter_entropy:68 0xE2 F/TC:? 0 plat_prng_add_jitter_entropy:68 0x54 F/TC:? 0 trace_syscall:147 syscall #2 (syscall_panic) E/TC:? 0 E/TC:? 0 TA panicked with code 0xffff000e E/LD: Status of TA fd02c9da-306c-48c7-a49c-bbd827ae86ee E/LD: arch: aarch64 E/LD: region 0: va 0x80005000 pa 0x56112000 size 0x002000 flags rw-s (ldelf) E/LD: region 1: va 0x80007000 pa 0x56114000 size 0x008000 flags r-xs (ldelf) E/LD: region 2: va 0x8000f000 pa 0x5611c000 size 0x001000 flags rw-s (ldelf) E/LD: region 3: va 0x80010000 pa 0x5611d000 size 0x004000 flags rw-s (ldelf) E/LD: region 4: va 0x80014000 pa 0x56121000 size 0x001000 flags r--s E/LD: region 5: va 0x80015000 pa 0x5619a000 size 0x002000 flags rw-s (stack) E/LD: region 6: va 0x80017000 pa 0x541a2000 size 0x001000 flags rw-- (param) E/LD: region 7: va 0x8001c000 pa 0x56122000 size 0x063000 flags r-xs [0] E/LD: region 8: va 0x8007f000 pa 0x56185000 size 0x015000 flags rw-s [0] E/LD: [0] fd02c9da-306c-48c7-a49c-bbd827ae86ee @ 0x8001c000 E/LD: Call stack: E/LD: 0x80034ef4 E/LD: 0x8001f28c E/LD: 0x80024eb0 E/LD: 0x8002694c E/LD: 0x8001d27c E/LD: 0x8003b3b4 E/LD: 0x800309ec D/TC:? 0 user_ta_enter:195 tee_user_ta_enter: TA panicked with code 0xffff000e D/TC:? 0 release_ta_ctx:670 Releasing panicked TA ctx D/TC:? 0 tee_ta_invoke_command:798 Error: ffff3024 of 3 D/TC:? 0 tee_ta_close_session:460 csess 0x560f1150 id 1 D/TC:? 0 tee_ta_close_session:479 Destroy session [ 263.892611] Unable to handle kernel paging request at virtual address 50ffff0000c4079d [ 263.892623] Mem abort info: [ 263.892624] ESR = 0x0000000096000004 [ 263.892627] EC = 0x25: DABT (current EL), IL = 32 bits [ 263.892631] SET = 0, FnV = 0 [ 263.892633] EA = 0, S1PTW = 0 [ 263.892635] FSC = 0x04: level 0 translation fault [ 263.892638] Data abort info: [ 263.892640] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 263.892642] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 263.892645] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 263.892649] [50ffff0000c4079d] address between user and kernel address ranges [ 263.892653] Internal error: Oops: 0000000096000004 [#1] PREEMPT_RT SMP [ 263.892659] CPU: 0 PID: 1 Comm: systemd Not tainted 6.6.80-rt51 #23 [ 263.892664] Hardware name: Toradex Verdin iMX8M Plus [ 263.892667] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 263.892673] pc : ___slab_alloc+0x408/0x958 [ 263.892685] lr : ___slab_alloc+0x90/0x958 [ 263.892696] sp : ffff80008160b940 [ 263.892698] x29: ffff80008160b940 x28: 0000000000000000 x27: ffff8000811b5838 [ 263.892708] x26: 0000000000000000 x25: ffff8000802f7624 x24: fffffc0003101d80 [ 263.892715] x23: 50ffff0000c4076d x22: ffff0000c0001600 x21: 0000000000000060 [ 263.892722] x20: 00000000ffffffff x19: ffff0000ff76bcc0 x18: ffff8000815f5078 [ 263.892732] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 263.892739] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 263.892745] x11: 0000000000000000 x10: fffffffffdab3428 x9 : 0000000000000000 [ 263.892752] x8 : ffff0000c1fbbb40 x7 : 0000000000000000 x6 : ffff0000c00b0000 [ 263.892764] x5 : 0000000000000060 x4 : ffff0000ff76bcf8 x3 : 0000000000000000 [ 263.892771] x2 : 0000000000000000 x1 : 0000000000000030 x0 : 000000000042d800 [ 263.892778] Call trace: [ 263.892781] ___slab_alloc+0x408/0x958 [ 263.892787] __kmem_cache_alloc_node+0xd4/0x1fc [ 263.892795] kmalloc_trace+0x24/0x34 [ 263.892802] kernfs_fop_open+0x2f0/0x390 [ 263.892808] do_dentry_open+0x16c/0x50c [ 263.892814] vfs_open+0x30/0x40 [ 263.892822] path_openat+0xb2c/0xee0 [ 263.892829] do_filp_open+0xa4/0x15c [ 263.892836] do_sys_openat2+0xc8/0xfc [ 263.892841] __arm64_sys_openat+0x68/0xac [ 263.892847] invoke_syscall+0x4c/0x124 [ 263.892854] el0_svc_common.constprop.0+0x44/0xec [ 263.892862] do_el0_svc+0x20/0x30 [ 263.892868] el0_svc+0x3c/0xd8 [ 263.892875] el0t_64_sync_handler+0x108/0x134 [ 263.892881] el0t_64_sync+0x198/0x19c [ 263.892890] Code: f9000a60 a94573fb b9402ac1 f9400660 (f8616ae1) [ 263.892894] ---[ end trace 0000000000000000 ]--- [ 263.892899] Kernel panic - not syncing: Oops: Fatal exception [ 263.892902] SMP: stopping secondary CPUs [ 263.896937] Kernel Offset: disabled [ 263.896939] CPU features: 0x0,00000008,00020000,1000420b [ 263.896944] Memory Limit: none Without OP-TEE Debug Output [ 917.500140] Unable to handle kernel paging request at virtual address 00000000fffffff7 [ 917.500159] Mem abort info: [ 917.500161] ESR = 0x0000000096000004 [ 917.500164] EC = 0x25: DABT (current EL), IL = 32 bits [ 917.500169] SET = 0, FnV = 0 [ 917.500173] EA = 0, S1PTW = 0 [ 917.500176] FSC = 0x04: level 0 translation fault [ 917.500180] Data abort info: [ 917.500181] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 917.500185] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 917.500189] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 917.500194] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000046120000 [ 917.500199] [00000000fffffff7] pgd=0000000000000000, p4d=0000000000000000 [ 917.500210] Internal error: Oops: 0000000096000004 [#1] PREEMPT_RT SMP [ 917.500218] CPU: 1 PID: 962 Comm: tee-supplicant Not tainted 6.6.80-rt51 #22 [ 917.500225] Hardware name: Toradex Verdin iMX8M Plus [ 917.500229] pstate: 000000c5 (nzcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 917.500236] pc : complete+0x5c/0x9c [ 917.500252] lr : complete+0x28/0x9c [ 917.500261] sp : ffff8000833e3bb0 [ 917.500264] x29: ffff8000833e3bb0 x28: ffff000002855e80 x27: 0000000000000000 [ 917.500274] x26: 0000000000000000 x25: 0000000000000000 x24: ffff000002856480 [ 917.500284] x23: ffff0000c007aca0 x22: 00000000ffff000e x21: 0000000000000000 [ 917.500293] x20: ffff0000c393a8d8 x19: 00000000ffffffff x18: ffff8000826f9090 [ 917.500303] x17: 0000000000000100 x16: ffff800080f92850 x15: 0000000000000040 [ 917.500313] x14: 0000000000000004 x13: ffff0000c0d625d8 x12: 0000000000000000 [ 917.500322] x11: ffff000001d51700 x10: ffff000001d516d0 x9 : ffff0000c0d625d8 [ 917.500332] x8 : ffff000001d516f8 x7 : 0000000000000000 x6 : 0000000000000228 [ 917.500341] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000001 [ 917.500350] x2 : 0000000000000000 x1 : 0000000000000003 x0 : ffff0000c393a8e0 [ 917.500362] Call trace: [ 917.500365] complete+0x5c/0x9c [ 917.500373] optee_supp_release+0x5c/0x12c [ 917.500383] optee_release_supp+0x44/0x58 [ 917.500390] teedev_ctx_put.part.0+0x90/0xc8 [ 917.500397] teedev_ctx_put+0x20/0x30 [ 917.500403] tee_shm_put+0x110/0x188 [ 917.500409] tee_shm_fop_release+0x18/0x2c [ 917.500416] __fput+0xc0/0x26c [ 917.500425] ____fput+0x14/0x24 [ 917.500433] task_work_run+0x7c/0xdc [ 917.500440] do_exit+0x2d8/0x8d8 [ 917.500447] do_group_exit+0x38/0x94 [ 917.500455] __wake_up_parent+0x0/0x38 [ 917.500462] invoke_syscall+0x4c/0x124 [ 917.500471] el0_svc_common.constprop.0+0x44/0xec [ 160.985670] Unable to handle kernel paging request at virtual address ffff0000c4a18039 [ 160.985686] Mem abort info: [ 160.985688] ESR = 0x0000000096000021 [ 160.985690] EC = 0x25: DABT (current EL), IL = 32 bits [ 160.985694] SET = 0, FnV = 0 [ 160.985696] EA = 0, S1PTW = 0 [ 160.985699] FSC = 0x21: alignment fault [ 160.985701] Data abort info: [ 160.985703] ISV = 0, ISS = 0x00000021, ISS2 = 0x00000000 [ 160.985705] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 160.985709] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 160.985712] swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000411ca000 [ 160.985716] [ffff0000c4a18039] pgd=180000013fff8003, p4d=180000013fff8003, pud=180000013fa1b003, pmd=180000013f9f5003, pte=0068000104a18707 [ 160.985730] Internal error: Oops: 0000000096000021 [#1] PREEMPT_RT SMP [ 160.985736] CPU: 1 PID: 2894 Comm: pkcs11-tool Not tainted 6.6.80-rt51 #22 [ 160.985742] Hardware name: Toradex Verdin iMX8M Plus [ 160.985746] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 160.985751] pc : tee_shm_put+0x144/0x188 [ 160.985762] lr : tee_shm_put+0x34/0x188 [ 160.985767] sp : ffff800083e63b30 [ 160.985769] x29: ffff800083e63b30 x28: ffff0000145fb000 x27: ffff0000c4a18001 [ 160.985777] x26: ffff0000c7455f58 x25: ffff0000145d0000 x24: ffff0000c09c4400 [ 160.985786] x23: ffff0000c4a185a0 x22: ffff0000c0836800 x21: ffff0000c0836bd8 [ 160.985794] x20: ffff0000c4a18039 x19: ffff0000c4a18001 x18: ffff8000837a5060 [ 160.985801] x17: 0000000000000100 x16: ffff800080f92850 x15: 0000000000000000 [ 160.985808] x14: 0000000000000000 x13: 0000000000000001 x12: 00000000000a122e [ 160.985817] x11: ffff8000811b5000 x10: 00007fffffffffff x9 : 0001000000000000 [ 160.985825] x8 : ffff800083e63b18 x7 : 0000000000000000 x6 : 0000000000000000 [ 160.985832] x5 : ffff0000c09c4540 x4 : ffff0000c4a18039 x3 : 0000000000000000 [ 160.985839] x2 : 0000000000000000 x1 : 0000000000000001 x0 : 0000000000000000 [ 160.985849] Call trace: [ 160.985851] tee_shm_put+0x144/0x188 [ 160.985856] tee_shm_free+0x14/0x24 [ 160.985861] optee_shm_register+0x1a4/0x1dc [ 160.985868] register_shm_helper+0x1cc/0x29c [ 160.985874] tee_shm_register_user_buf+0xb0/0x14c [ 160.985881] tee_ioctl+0xc4/0x11d0 [ 160.985886] __arm64_sys_ioctl+0xc8/0xe8 [ 160.985892] invoke_syscall+0x4c/0x124 [ 160.985899] el0_svc_common.constprop.0+0x44/0xec [ 160.985906] do_el0_svc+0x20/0x30 [ 160.985913] el0_svc+0x3c/0xd8 [ 160.985921] el0t_64_sync_handler+0x108/0x134 [ 160.985927] el0t_64_sync+0x198/0x19c [ 160.985935] Code: d65f03c0 9100e264 52800021 f9800091 (885f7c80) [ 160.985942] ---[ end trace 0000000000000000 ]--- [ 160.985945] Kernel panic - not syncing: Oops: Fatal exception [ 160.985949] SMP: stopping secondary CPUs [ 160.985957] Kernel Offset: disabled [ 160.985959] CPU features: 0x0,00000008,00020000,1000420b [ 160.985963] Memory Limit: none

1 year, 2 months

1
0
0 0

Preparing for OP-TEE 4.6.0

by Jens Wiklander

[BCC all OP-TEE maintainers] Hi OP-TEE maintainers & contributors, OP-TEE version 4.6.0 is scheduled to be released on 2025-04-25. 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/7359. We will create the release candidate tag 4.6.0-rc1 this 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, Jens

1 year, 2 months

1
1
0 0

[PATCH v6 00/10] TEE subsystem for restricted dma-buf allocations

by Jens Wiklander

Hi, This patch set allocates the restricted DMA-bufs from a DMA-heap instantiated from the TEE subsystem. The TEE subsystem handles the DMA-buf allocations since it is the TEE (OP-TEE, AMD-TEE, TS-TEE, or perhaps a future QTEE) which sets up the restrictions for the memory used for the DMA-bufs. The DMA-heap uses a restricted memory pool provided by the backend TEE driver, allowing it to choose how to allocate the restricted physical memory. The allocated DMA-bufs must be imported with a new TEE_IOC_SHM_REGISTER_FD before they can be passed as arguments when requesting services from the secure world. Three use-cases (Secure Video Playback, Trusted UI, and Secure Video Recording) has been identified so far to serve as examples of what can be expected. The use-cases has predefined DMA-heap names, "restricted,secure-video", "restricted,trusted-ui", and "restricted,secure-video-record". The backend driver registers restricted memory pools for the use-cases it supports. Each use-case has it's own restricted memory pool since different use-cases requires isolation from different parts of the system. A restricted memory pool can be based on a static carveout instantiated while probing the TEE backend driver, or dynamically allocated from CMA and made restricted as needed by the TEE. This can be tested on a RockPi 4B+ with the following steps: repo init -u https://github.com/jenswi-linaro/manifest.git -m rockpi4.xml \ -b prototype/sdp-v6 repo sync -j8 cd build make toolchains -j$(nproc) make all -j$(nproc) # Copy ../out/rockpi4.img to an SD card and boot the RockPi from that # Connect a monitor to the RockPi # login and at the prompt: gst-launch-1.0 videotestsrc ! \ aesenc key=1f9423681beb9a79215820f6bda73d0f \ iv=e9aa8e834d8d70b7e0d254ff670dd718 serialize-iv=true ! \ aesdec key=1f9423681beb9a79215820f6bda73d0f ! \ kmssink The aesdec module has been hacked to use an OP-TEE TA to decrypt the stream into restricted DMA-bufs which are consumed by the kmssink. The primitive QEMU tests from previous patch set can be tested on RockPi in the same way with: xtest --sdp-basic The primitive test are tested on QEMU with the following steps: repo init -u https://github.com/jenswi-linaro/manifest.git -m qemu_v8.xml \ -b prototype/sdp-v6 repo sync -j8 cd build make toolchains -j$(nproc) make SPMC_AT_EL=1 all -j$(nproc) make SPMC_AT_EL=1 run-only # login and at the prompt: xtest --sdp-basic The SPMC_AT_EL=1 parameter configures the build with FF-A and an SPMC at S-EL1 inside OP-TEE. The parameter can be changed into SPMC_AT_EL=n to test without FF-A using the original SMC ABI instead. Please remember to do %rm -rf ../trusted-firmware-a/build/qemu for TF-A to be rebuilt properly using the new configuration. https://optee.readthedocs.io/en/latest/building/prerequisites.html list dependencies needed to build the above. The tests are pretty basic, mostly checking that a Trusted Application in the secure world can access and manipulate the memory. There are also some negative tests for out of bounds buffers etc. Thanks, Jens Changes since V5: * Removing "tee: add restricted memory allocation" and "tee: add TEE_IOC_RSTMEM_FD_INFO" * Adding "tee: implement restricted DMA-heap", "tee: new ioctl to a register tee_shm from a dmabuf file descriptor", "tee: add tee_shm_alloc_cma_phys_mem()", "optee: pass parent device to tee_device_alloc()", and "tee: tee_device_alloc(): copy dma_mask from parent device" * The two TEE driver OPs "rstmem_alloc()" and "rstmem_free()" are replaced with a struct tee_rstmem_pool abstraction. * Replaced the the TEE_IOC_RSTMEM_ALLOC user space API with the DMA-heap API Changes since V4: * Adding the patch "tee: add TEE_IOC_RSTMEM_FD_INFO" needed by the GStreamer demo * Removing the dummy CPU access and mmap functions from the dma_buf_ops * Fixing a compile error in "optee: FF-A: dynamic restricted memory allocation" reported by kernel test robot <lkp(a)intel.com> Changes since V3: * Make the use_case and flags field in struct tee_shm u32's instead of u16's * Add more description for TEE_IOC_RSTMEM_ALLOC in the header file * Import namespace DMA_BUF in module tee, reported by lkp(a)intel.com * Added a note in the commit message for "optee: account for direction while converting parameters" why it's needed * Factor out dynamic restricted memory allocation from "optee: support restricted memory allocation" into two new commits "optee: FF-A: dynamic restricted memory allocation" and "optee: smc abi: dynamic restricted memory allocation" * Guard CMA usage with #ifdef CONFIG_CMA, effectively disabling dynamic restricted memory allocate if CMA isn't configured Changes since the V2 RFC: * Based on v6.12 * Replaced the flags for SVP and Trusted UID memory with a u32 field with unique id for each use case * Added dynamic allocation of restricted memory pools * Added OP-TEE ABI both with and without FF-A for dynamic restricted memory * Added support for FF-A with FFA_LEND Changes since the V1 RFC: * Based on v6.11 * Complete rewrite, replacing the restricted heap with TEE_IOC_RSTMEM_ALLOC Changes since Olivier's post [2]: * Based on Yong Wu's post [1] where much of dma-buf handling is done in the generic restricted heap * Simplifications and cleanup * New commit message for "dma-buf: heaps: add Linaro restricted dmabuf heap support" * Replaced the word "secure" with "restricted" where applicable Etienne Carriere (1): tee: new ioctl to a register tee_shm from a dmabuf file descriptor Jens Wiklander (9): tee: tee_device_alloc(): copy dma_mask from parent device optee: pass parent device to tee_device_alloc() optee: account for direction while converting parameters optee: sync secure world ABI headers tee: implement restricted DMA-heap tee: add tee_shm_alloc_cma_phys_mem() optee: support restricted memory allocation optee: FF-A: dynamic restricted memory allocation optee: smc abi: dynamic restricted memory allocation drivers/tee/Makefile | 1 + drivers/tee/optee/Makefile | 1 + drivers/tee/optee/call.c | 10 +- drivers/tee/optee/core.c | 1 + drivers/tee/optee/ffa_abi.c | 194 +++++++++++- drivers/tee/optee/optee_ffa.h | 27 +- drivers/tee/optee/optee_msg.h | 65 ++++- drivers/tee/optee/optee_private.h | 55 +++- drivers/tee/optee/optee_smc.h | 71 ++++- drivers/tee/optee/rpc.c | 31 +- drivers/tee/optee/rstmem.c | 329 +++++++++++++++++++++ drivers/tee/optee/smc_abi.c | 190 ++++++++++-- drivers/tee/tee_core.c | 147 +++++++--- drivers/tee/tee_heap.c | 470 ++++++++++++++++++++++++++++++ drivers/tee/tee_private.h | 7 + drivers/tee/tee_shm.c | 199 ++++++++++++- include/linux/tee_core.h | 67 +++++ include/linux/tee_drv.h | 10 + include/uapi/linux/tee.h | 29 ++ 19 files changed, 1781 insertions(+), 123 deletions(-) create mode 100644 drivers/tee/optee/rstmem.c create mode 100644 drivers/tee/tee_heap.c base-commit: 7eb172143d5508b4da468ed59ee857c6e5e01da6 -- 2.43.0

1 year, 2 months

3
47
0 0

Extract RPMB Key

by Stauffer Thomas MTANA

As far as I understand there are currently two possibilities to setup an RPMB with an appropriate key. 1. Use a specialized OP-TEE with CFG_RPMB_WRITE_KEY=y during production in an environment were leaking the key is ok. 2. Get the HUK, get the CID from the MMC, then use scripts/derive_rpmb_key.py to calculate the RPMB key and set e.g. via mmc tool. I've the impression when I read through some message on https://github.com/OP-TEE/optee_os/issues, that 1 is not considered the best idea. Currently I'm working on a iMX8M platform and using CFG_RPMB_WRITE_KEY also has the drawback to use the legacy RPMB interface, which makes tee-supplicant still necessary, which otherwise would not be needed. The problem at least on iMX8M is that its not easy possible to get the HUK, and the HUK also is different, depending if a device is in a closed state or not. To extract the whole HUK, even in a sensible environment during production, seems unnecessary. What I did now, something very simple. I extended tee_rpmb_fs.c a little bit and made a function which allows to retrieve the RPMB key, I added also a tiny PTA, and a corresponding user space application to get the RPMB key, only as long CFG_INSECURE is set, therefore also only a specialized OP-TEE build can provide this functionality. Someone can now decide to get the RPMB key either before the device is closed (for testing devices), or afterwards. Write then the RPMB key manually (e.g. via mmc tool) and/or also store it securly in a production data database. What would be the advantages, compared to CFG_RPMB_WRITE_KEY=y - HUK is still not leaked, as it may be used to derive other secrets - derive_rpmb_key.py is not necessary - It is guaranteed that the correct RPMB key is retrieved, 100% matches how OP-TEE was configured (e.g. with compat mode enabled or not) - Because the RPMB key is known, one can manually still delete the RPMB and see how OP-TEE handles this situation, at least during development - Testing this functionality also on an open device (which is currently not possible at least on iMX8M, due to plat_rpmb_key_is_ready) My question is, if there would be any interest to open a PR, so other people also can use this?

1 year, 2 months

2
2
0 0

Conflict with "fallthrough" define

by Jacob Kroon

Hi, We are using OP-TEE together with a library that provides its own "fallthrough" define, similar to what OP-TEE does in lib/libutils/ext/include/compiler.h: #define fallthrough __attribute__((__fallthrough__)) However, this other library checks for fallthrough attribute support by first doing: #if __has_cpp_attribute(fallthrough) ... #endif which fails to compile due to the OP-TEE define. Would OP-TEE accept a patch to rename the "fallthrough" define to something like "optee_fallthrough", "FALLTHROUGH", <other suggestion> ? Or should we upstream a patch to the library to do: #if __has_cpp_attribute(__fallthrough__) ... #endif (which is what OP-TEE currently does) Regards Jacob

1 year, 2 months

3
2
0 0

[RFC PATCH 0/7] KVM: optee: Introduce OP-TEE Mediator for exposing secure world to KVM guests

by Yuvraj Sakshith

A KVM guest running on an arm64 machine will not be able to interact with a trusted execution environment (which supports non-secure guests) like OP-TEE in the secure world. This is because, instructions provided by the architecture (such as, SMC) which switch control to the firmware, are trapped in EL2 when the guest is executes them. This series adds a feature into the kernel called the TEE mediator abstraction layer, which lets a guest interact with the secure world. Additionally, a OP-TEE specific mediator is also implemented, which hooks itself to the TEE mediator layer and intercepts guest SMCs targetted at OP-TEE. Overview ========= Essentially, if the kernel wants to interact with OP-TEE, it makes an "smc - secure monitor call instruction", after loading in arguments into CPU registers. What these arguments consists of and how both these entities communicate can vary. If a guest wants to establish a connection with the secure world, its not possible. This is because of the fact that "smc" by the guest are trapped by the hypervisor in EL2. This is done by setting the HCR_EL2.TSC bit before entering the guest. Hence, this feature which I we may call TEE mediator, acts as an intermediary between the guest and OP-TEE. Instead of denying the guest SMC and jumping back into the guest, the mediator forwards the request to OP-TEE. OP-TEE supports virtualization in the normal world and expects 6 things from the NS-hypervisor: 1. Notify OP-TEE when a VM is created. 2. Notify OP-TEE when a VM is destroyed. 3. Any SMC to OP-TEE has to contain the VMID in x7. If its the hypervisor sending, then VMID is 0. 4. Hypervisor has to perform IPA->PA translations of the memory addresses sent by guest. 5. Memory shared by the VM to OP-TEE has to remain pinned. 6. The hypervisor has to follow the OP-TEE protocol, so the guest thinks it is directly speaking to OP-TEE. Its important to note that, if OP-TEE is built with NS-virtualization support, it can only function if there is a hypervisor with a mediator in normal world. This implementation has been heavily inspired by Xen's OP-TEE mediator. Design ====== The unique design of KVM makes it quite challenging to implement such a mediator. OP-TEE is not aware of the host-guest paradigm. Hence, the mediator treats the host as a VM with VMID 1. The guests are assigned VMIDs starting from 2 (note, these are not the VMIDs tagged in TLB, rather we implement our own simple indexing mechanism). When the host's OP-TEE driver is initialised or released, OP-TEE is notified about VM 1 being created/destroyed. When a VMM (such as, QEMU) created a guest through KVM ioctls, a call to the TEE mediator layer is made, which in-turn calls OP-TEE mediator which eventually assigns a VM context, VMID, etc. and notifies OP-TEE about guest creation. The opposite happens on guest destruction. When the guest makes an SMC targetting OP-TEE, it is trapped by the hypervisor and the register state (kvm_vcpu) is sent to the OP-TEE mediator through the TEE layer. Here there are two possibilities. The guest may make an SMC with arguments which are simple numeric values, exchanging UUID, version information, etc. In this case, the mediator has much less work. It has to attach VMID into X7 and pass the register state to OP-TEE. But, when guest passes memory addresses as arguments, the mediator has to translate these into physical addresses from intermediate physical addresses (IPA). According to the OP-TEE protocol (as documented in optee_smc.h and optee_msg.h), the guest OP-TEE driver would share a buffer filled with pointers, which the mediator translates. The OP-TEE mediator also keeps track of active calls between each guest and OP-TEE, and pins pages which are already shared. This is to avoid swapping of shared pages by the host under memory pressure. These pages are unpinned as soon as guest's transaction completes with OP-TEE. Testing ======= The feature has been tested on QEMU virt platform using "xtest" as the test suite. As of now, all of 35000+ tests pass. The mediator has also been stressed under memory pressure and all tests pass too. Any suggestions on further testing the feature are welcome. Call for review =============== Any insights/suggestions regarding the implementation are appreciated. Yuvraj Sakshith (7): firmware: smccc: Add macros for Trusted OS/App owner check on SMC value tee: Add TEE Mediator module which aims to expose TEE to a KVM guest. KVM: Notify TEE Mediator when KVM creates and destroys guests KVM: arm64: Forward guest CPU state to TEE mediator on SMC trap tee: optee: Add OPTEE_SMC_VM_CREATED and OPTEE_SMC_VM_DESTROYED tee: optee: Add OP-TEE Mediator tee: optee: Notify TEE Mediator on OP-TEE driver initialization and release arch/arm64/kvm/hypercalls.c | 15 +- drivers/tee/Kconfig | 5 + drivers/tee/Makefile | 1 + drivers/tee/optee/Kconfig | 7 + drivers/tee/optee/Makefile | 1 + drivers/tee/optee/core.c | 13 +- drivers/tee/optee/optee_mediator.c | 1319 ++++++++++++++++++++++++++++ drivers/tee/optee/optee_mediator.h | 103 +++ drivers/tee/optee/optee_smc.h | 53 ++ drivers/tee/optee/smc_abi.c | 6 + drivers/tee/tee_mediator.c | 145 +++ include/linux/arm-smccc.h | 8 + include/linux/tee_mediator.h | 39 + virt/kvm/kvm_main.c | 11 +- 14 files changed, 1721 insertions(+), 5 deletions(-) create mode 100644 drivers/tee/optee/optee_mediator.c create mode 100644 drivers/tee/optee/optee_mediator.h create mode 100644 drivers/tee/tee_mediator.c create mode 100644 include/linux/tee_mediator.h -- 2.43.0

1 year, 2 months

2
11
0 0

[PATCH] tee: shm: fix slab page refcounting

by Marco Felsch

Skip manipulating the refcount in case of slab pages according commit b9c0e49abfca ("mm: decline to manipulate the refcount on a slab page"). Fixes: b9c0e49abfca ("mm: decline to manipulate the refcount on a slab page") Signed-off-by: Marco Felsch <m.felsch(a)pengutronix.de> --- drivers/tee/tee_shm.c | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/drivers/tee/tee_shm.c b/drivers/tee/tee_shm.c index daf6e5cfd59a..3d6a3077b6f2 100644 --- a/drivers/tee/tee_shm.c +++ b/drivers/tee/tee_shm.c @@ -19,16 +19,24 @@ static void shm_put_kernel_pages(struct page **pages, size_t page_count) { size_t n; - for (n = 0; n < page_count; n++) - put_page(pages[n]); + for (n = 0; n < page_count; n++) { + struct page *page = pages[n]; + + if (!PageSlab(page)) + put_page(pages[n]); + } } static void shm_get_kernel_pages(struct page **pages, size_t page_count) { size_t n; - for (n = 0; n < page_count; n++) - get_page(pages[n]); + for (n = 0; n < page_count; n++) { + struct page *page = pages[n]; + + if (!PageSlab(page)) + get_page(pages[n]); + } } static void release_registered_pages(struct tee_shm *shm) -- 2.39.5

1 year, 2 months

1
1
0 0

Linaro OP-TEE Contribution, LOC, monthly meeting March 25

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/ I've posted another version of the Secure Data Path patches [1] if you have any thoughts on that. [1] https://lore.kernel.org/lkml/20250305130634.1850178-1-jens.wiklander@linaro… Are there any other topics? Cheers, Jesn

1 year, 3 months

1
0
0 0

[PATCH v4 0/6] TEE subsystem for restricted dma-buf allocations

by Jens Wiklander

Hi, This patch set allocates the restricted DMA-bufs via the TEE subsystem. The TEE subsystem handles the DMA-buf allocations since it is the TEE (OP-TEE, AMD-TEE, TS-TEE, or perhaps a future QCOMTEE) which sets up the restrictions for the memory used for the DMA-bufs. I've added a new IOCTL, TEE_IOC_RSTMEM_ALLOC, to allocate the restricted DMA-bufs. This IOCTL reaches the backend TEE driver, allowing it to choose how to allocate the restricted physical memory. TEE_IOC_RSTMEM_ALLOC takes in addition to a size and flags parameters also a use-case parameter. This is used by the backend TEE driver to decide on allocation policy and which devices should be able to access the memory. Three use-cases (Secure Video Playback, Trusted UI, and Secure Video Recording) has been identified so far to serve as examples of what can be expected. More use-cases can be added in userspace ABI, but it's up to the backend TEE drivers to provide the implementation. Each use-case has it's own restricted memory pool since different use-cases requires isolation from different parts of the system. A restricted memory pool can be based on a static carveout instantiated while probing the TEE backend driver, or dynamically allocated from CMA and made restricted as needed by the TEE. This can be tested on QEMU with the following steps: repo init -u https://github.com/jenswi-linaro/manifest.git -m qemu_v8.xml \ -b prototype/sdp-v4 repo sync -j8 cd build make toolchains -j$(nproc) make SPMC_AT_EL=1 all -j$(nproc) make SPMC_AT_EL=1 run-only # login and at the prompt: xtest --sdp-basic The SPMC_AT_EL=1 parameter configures the build with FF-A and an SPMC at S-EL1 inside OP-TEE. The parameter can be changed into SPMC_AT_EL=n to test without FF-A using the original SMC ABI instead. Please remember to do %rm -rf ../trusted-firmware-a/build/qemu for TF-A to be rebuilt properly using the new configuration. https://optee.readthedocs.io/en/latest/building/prerequisites.html list dependencies needed to build the above. The tests are pretty basic, mostly checking that a Trusted Application in the secure world can access and manipulate the memory. There are also some negative tests for out of bounds buffers etc. Thanks, Jens Changes since V3: * Make the use_case and flags field in struct tee_shm u32's instead of u16's * Add more description for TEE_IOC_RSTMEM_ALLOC in the header file * Import namespace DMA_BUF in module tee, reported by lkp(a)intel.com * Added a note in the commit message for "optee: account for direction while converting parameters" why it's needed * Factor out dynamic restricted memory allocation from "optee: support restricted memory allocation" into two new commits "optee: FF-A: dynamic restricted memory allocation" and "optee: smc abi: dynamic restricted memory allocation" * Guard CMA usage with #ifdef CONFIG_CMA, effectively disabling dynamic restricted memory allocate if CMA isn't configured Changes since the V2 RFC: * Based on v6.12 * Replaced the flags for SVP and Trusted UID memory with a u32 field with unique id for each use case * Added dynamic allocation of restricted memory pools * Added OP-TEE ABI both with and without FF-A for dynamic restricted memory * Added support for FF-A with FFA_LEND Changes since the V1 RFC: * Based on v6.11 * Complete rewrite, replacing the restricted heap with TEE_IOC_RSTMEM_ALLOC Changes since Olivier's post [2]: * Based on Yong Wu's post [1] where much of dma-buf handling is done in the generic restricted heap * Simplifications and cleanup * New commit message for "dma-buf: heaps: add Linaro restricted dmabuf heap support" * Replaced the word "secure" with "restricted" where applicable Jens Wiklander (6): tee: add restricted memory allocation optee: account for direction while converting parameters optee: sync secure world ABI headers optee: support restricted memory allocation optee: FF-A: dynamic restricted memory allocation optee: smc abi: dynamic restricted memory allocation drivers/tee/Makefile | 1 + drivers/tee/optee/Makefile | 1 + drivers/tee/optee/call.c | 10 +- drivers/tee/optee/core.c | 1 + drivers/tee/optee/ffa_abi.c | 178 +++++++++++++- drivers/tee/optee/optee_ffa.h | 27 ++- drivers/tee/optee/optee_msg.h | 65 ++++- drivers/tee/optee/optee_private.h | 75 ++++-- drivers/tee/optee/optee_smc.h | 71 +++++- drivers/tee/optee/rpc.c | 31 ++- drivers/tee/optee/rstmem.c | 388 ++++++++++++++++++++++++++++++ drivers/tee/optee/smc_abi.c | 213 ++++++++++++++-- drivers/tee/tee_core.c | 38 ++- drivers/tee/tee_private.h | 2 + drivers/tee/tee_rstmem.c | 201 ++++++++++++++++ drivers/tee/tee_shm.c | 2 + drivers/tee/tee_shm_pool.c | 69 +++++- include/linux/tee_core.h | 15 ++ include/linux/tee_drv.h | 2 + include/uapi/linux/tee.h | 44 +++- 20 files changed, 1358 insertions(+), 76 deletions(-) create mode 100644 drivers/tee/optee/rstmem.c create mode 100644 drivers/tee/tee_rstmem.c base-commit: fac04efc5c793dccbd07e2d59af9f90b7fc0dca4 -- 2.43.0

1 year, 3 months

10
42
0 0

[PATCH v2 0/8] Trusted Execution Environment (TEE) driver for Qualcomm TEE (QTEE)

by Amirreza Zarrabi

This patch series introduces a Trusted Execution Environment (TEE) driver for Qualcomm TEE (QTEE). QTEE enables Trusted Applications (TAs) and services to run securely. It uses an object-based interface, where each service is an object with sets of operations. Clients can invoke these operations on objects, which can generate results, including other objects. For example, an object can load a TA and return another object that represents the loaded TA, allowing access to its services. Kernel and userspace services are also available to QTEE through a similar approach. QTEE makes callback requests that are converted into object invocations. These objects can represent services within the kernel or userspace process. Note: This patch series focuses on QTEE objects and userspace services. Linux already provides a TEE subsystem, which is described in [1]. The tee subsystem provides a generic ioctl interface, TEE_IOC_INVOKE, which can be used by userspace to talk to a TEE backend driver. We extend the Linux TEE subsystem to understand object parameters and an ioctl call so client can invoke objects in QTEE: - TEE_IOCTL_PARAM_ATTR_TYPE_OBJREF_* - TEE_IOC_OBJECT_INVOKE The existing ioctl calls TEE_IOC_SUPPL_RECV and TEE_IOC_SUPPL_SEND are used for invoking services in the userspace process by QTEE. The TEE backend driver uses the QTEE Transport Message to communicate with QTEE. Interactions through the object INVOKE interface are translated into QTEE messages. Likewise, object invocations from QTEE for userspace objects are converted into SEND/RECV ioctl calls to supplicants. The details of QTEE Transport Message to communicate with QTEE is available in [PATCH 10/10] Documentation: tee: Add Qualcomm TEE driver. You can run basic tests with following steps: git clone https://github.com/quic/quic-teec.git cd quic-teec mkdir build cmake .. -DCMAKE_TOOLCHAIN_FILE=CMakeToolchain.txt -DBUILD_UNITTEST=ON https://github.com/quic/quic-teec/blob/main/README.md lists dependancies needed to build the above. This series has been tested for basic QTEE object invocations and callback requests, including loading a TA and requesting services form the TA. [1] https://www.kernel.org/doc/Documentation/tee.txt Signed-off-by: Amirreza Zarrabi <quic_azarrabi(a)quicinc.com> --- Changes in v2: - Clean up commit messages and comments. - Use better names such as ubuf instead of membuf or QCOMTEE prefix instead of QCOM_TEE, or names that are more consistent with other TEE-backend drivers such as qcomtee_context_data instead of qcom_tee_context. - Drop the DTS patch and instantiate the device from the scm driver. - Use a single structure for all driver's internal states. - Drop srcu primitives and use the existing mutex for synchronization between the supplicant and QTEE. - Directly use tee_context to track the lifetime of qcomtee_context_data. - Add close_context() to be called when the user closes the tee_context. - Link to v1: https://lore.kernel.org/r/20241202-qcom-tee-using-tee-ss-without-mem-obj-v1… Changes in v1: - It is a complete rewrite to utilize the TEE subsystem. - Link to RFC: https://lore.kernel.org/all/20240702-qcom-tee-object-and-ioctls-v1-0-633c3d… --- Amirreza Zarrabi (8): tee: allow a driver to allocate a tee_device without a pool tee: add close_context to TEE driver operation tee: add TEE_IOCTL_PARAM_ATTR_TYPE_UBUF tee: add TEE_IOCTL_PARAM_ATTR_TYPE_OBJREF firmware: qcom: scm: add support for object invocation tee: add Qualcomm TEE driver qcomtee: add primordial object Documentation: tee: Add Qualcomm TEE driver Documentation/tee/index.rst | 1 + Documentation/tee/qtee.rst | 150 ++++++ drivers/firmware/qcom/qcom_scm.c | 128 ++++++ drivers/firmware/qcom/qcom_scm.h | 7 + drivers/tee/Kconfig | 1 + drivers/tee/Makefile | 1 + drivers/tee/qcomtee/Kconfig | 10 + drivers/tee/qcomtee/Makefile | 10 + drivers/tee/qcomtee/async.c | 160 +++++++ drivers/tee/qcomtee/call.c | 741 ++++++++++++++++++++++++++++++ drivers/tee/qcomtee/core.c | 810 +++++++++++++++++++++++++++++++++ drivers/tee/qcomtee/primordial_obj.c | 65 +++ drivers/tee/qcomtee/qcom_scm.c | 36 ++ drivers/tee/qcomtee/qcomtee_msg.h | 234 ++++++++++ drivers/tee/qcomtee/qcomtee_private.h | 226 +++++++++ drivers/tee/qcomtee/release.c | 59 +++ drivers/tee/qcomtee/shm.c | 102 +++++ drivers/tee/qcomtee/user_obj.c | 712 +++++++++++++++++++++++++++++ drivers/tee/tee_core.c | 121 ++++- drivers/tee/tee_private.h | 6 - include/linux/firmware/qcom/qcom_scm.h | 27 ++ include/linux/firmware/qcom/qcom_tee.h | 286 ++++++++++++ include/linux/tee_core.h | 15 +- include/linux/tee_drv.h | 18 + include/uapi/linux/tee.h | 54 ++- 25 files changed, 3964 insertions(+), 16 deletions(-) --- base-commit: dab2734f8e9ecba609d66d1dd087a392a7774c04 change-id: 20241202-qcom-tee-using-tee-ss-without-mem-obj-362c66340527 Best regards, -- Amirreza Zarrabi <quic_azarrabi(a)quicinc.com>

1 year, 3 months

5
24
0 0

[PATCH] MAINTAINERS: .mailmap: Update Sumit Garg's email address

by Sumit Garg

Update Sumit Garg's email address to @kernel.org. Signed-off-by: Sumit Garg <sumit.garg(a)linaro.org> --- .mailmap | 1 + MAINTAINERS | 6 +++--- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/.mailmap b/.mailmap index a897c16d3bae..4a93909286d8 100644 --- a/.mailmap +++ b/.mailmap @@ -689,6 +689,7 @@ Subbaraman Narayanamurthy <quic_subbaram(a)quicinc.com> <subbaram(a)codeaurora.org> Subhash Jadavani <subhashj(a)codeaurora.org> Sudarshan Rajagopalan <quic_sudaraja(a)quicinc.com> <sudaraja(a)codeaurora.org> Sudeep Holla <sudeep.holla(a)arm.com> Sudeep KarkadaNagesha <sudeep.karkadanagesha(a)arm.com> +Sumit Garg <sumit.garg(a)kernel.org> <sumit.garg(a)linaro.org> Sumit Semwal <sumit.semwal(a)ti.com> Surabhi Vishnoi <quic_svishnoi(a)quicinc.com> <svishnoi(a)codeaurora.org> Sven Eckelmann <sven(a)narfation.org> <seckelmann(a)datto.com> diff --git a/MAINTAINERS b/MAINTAINERS index 1b0cc181db74..616f859c5f92 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -12861,7 +12861,7 @@ F: include/keys/trusted_dcp.h F: security/keys/trusted-keys/trusted_dcp.c KEYS-TRUSTED-TEE -M: Sumit Garg <sumit.garg(a)linaro.org> +M: Sumit Garg <sumit.garg(a)kernel.org> L: linux-integrity(a)vger.kernel.org L: keyrings(a)vger.kernel.org S: Supported @@ -17661,7 +17661,7 @@ F: Documentation/ABI/testing/sysfs-bus-optee-devices F: drivers/tee/optee/ OP-TEE RANDOM NUMBER GENERATOR (RNG) DRIVER -M: Sumit Garg <sumit.garg(a)linaro.org> +M: Sumit Garg <sumit.garg(a)kernel.org> L: op-tee(a)lists.trustedfirmware.org S: Maintained F: drivers/char/hw_random/optee-rng.c @@ -23272,7 +23272,7 @@ F: include/media/i2c/tw9910.h TEE SUBSYSTEM M: Jens Wiklander <jens.wiklander(a)linaro.org> -R: Sumit Garg <sumit.garg(a)linaro.org> +R: Sumit Garg <sumit.garg(a)kernel.org> L: op-tee(a)lists.trustedfirmware.org S: Maintained F: Documentation/ABI/testing/sysfs-class-tee -- 2.43.0

1 year, 3 months

1
0
0 0

Linaro OP-TEE Contribution, LOC, monthly meeting February 25

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/ I recently posted a new version of the Restricted DMA-buf patch set [1], and there's also an ongoing discussion that already started on the previous version of the patch set [2]. We're discussing whether the restricted DMA-bufs should be allocated from DMA heaps or the TEE subsystem. Both approaches work, but we need to decide on one for the patch set to move forward. [1] https://lore.kernel.org/lkml/20250218143527.1236668-1-jens.wiklander@linaro… [2] https://lore.kernel.org/lkml/20241217100809.3962439-1-jens.wiklander@linaro… Are there any other topics? Cheers, Jens

1 year, 3 months

1
0
0 0

[PATCH v5 0/7] TEE subsystem for restricted dma-buf allocations

by Jens Wiklander

Hi, [Now with a Gstreamer demo, see below.] This patch set allocates the restricted DMA-bufs via the TEE subsystem. The TEE subsystem handles the DMA-buf allocations since it is the TEE (OP-TEE, AMD-TEE, TS-TEE, or perhaps a future QCOMTEE) which sets up the restrictions for the memory used for the DMA-bufs. I've added a new IOCTL, TEE_IOC_RSTMEM_ALLOC, to allocate the restricted DMA-bufs. This IOCTL reaches the backend TEE driver, allowing it to choose how to allocate the restricted physical memory. TEE_IOC_RSTMEM_ALLOC takes in addition to a size and flags parameters also a use-case parameter. This is used by the backend TEE driver to decide on allocation policy and which devices should be able to access the memory. Three use-cases (Secure Video Playback, Trusted UI, and Secure Video Recording) has been identified so far to serve as examples of what can be expected. More use-cases can be added in userspace ABI, but it's up to the backend TEE drivers to provide the implementation. Each use-case has it's own restricted memory pool since different use-cases requires isolation from different parts of the system. A restricted memory pool can be based on a static carveout instantiated while probing the TEE backend driver, or dynamically allocated from CMA and made restricted as needed by the TEE. This can be tested on a RockPi 4B+ with the following steps: repo init -u https://github.com/jenswi-linaro/manifest.git -m rockpi4.xml \ -b prototype/sdp-v5 repo sync -j8 cd build make toolchains -j$(nproc) make all -j$(nproc) # Copy ../out/rockpi4.img to an SD card and boot the RockPi from that # Connect a monitor to the RockPi # login and at the prompt: gst-launch-1.0 videotestsrc ! \ aesenc key=1f9423681beb9a79215820f6bda73d0f \ iv=e9aa8e834d8d70b7e0d254ff670dd718 serialize-iv=true ! \ aesdec key=1f9423681beb9a79215820f6bda73d0f ! \ kmssink The aesdec module has been hacked to use an OP-TEE TA to decrypt the stream into restricted DMA-bufs which are consumed by the kmssink. The primitive QEMU tests from previous patch set can be tested on RockPi in the same way with: xtest --sdp-basic The primitive test are tested on QEMU with the following steps: repo init -u https://github.com/jenswi-linaro/manifest.git -m qemu_v8.xml \ -b prototype/sdp-v5 repo sync -j8 cd build make toolchains -j$(nproc) make SPMC_AT_EL=1 all -j$(nproc) make SPMC_AT_EL=1 run-only # login and at the prompt: xtest --sdp-basic The SPMC_AT_EL=1 parameter configures the build with FF-A and an SPMC at S-EL1 inside OP-TEE. The parameter can be changed into SPMC_AT_EL=n to test without FF-A using the original SMC ABI instead. Please remember to do %rm -rf ../trusted-firmware-a/build/qemu for TF-A to be rebuilt properly using the new configuration. https://optee.readthedocs.io/en/latest/building/prerequisites.html list dependencies needed to build the above. The tests are pretty basic, mostly checking that a Trusted Application in the secure world can access and manipulate the memory. There are also some negative tests for out of bounds buffers etc. Thanks, Jens Changes since V4: * Adding the patch "tee: add TEE_IOC_RSTMEM_FD_INFO" needed by the GStreamer demo * Removing the dummy CPU access and mmap functions from the dma_buf_ops * Fixing a compile error in "optee: FF-A: dynamic restricted memory allocation" reported by kernel test robot <lkp(a)intel.com> Changes since V3: * Make the use_case and flags field in struct tee_shm u32's instead of u16's * Add more description for TEE_IOC_RSTMEM_ALLOC in the header file * Import namespace DMA_BUF in module tee, reported by lkp(a)intel.com * Added a note in the commit message for "optee: account for direction while converting parameters" why it's needed * Factor out dynamic restricted memory allocation from "optee: support restricted memory allocation" into two new commits "optee: FF-A: dynamic restricted memory allocation" and "optee: smc abi: dynamic restricted memory allocation" * Guard CMA usage with #ifdef CONFIG_CMA, effectively disabling dynamic restricted memory allocate if CMA isn't configured Changes since the V2 RFC: * Based on v6.12 * Replaced the flags for SVP and Trusted UID memory with a u32 field with unique id for each use case * Added dynamic allocation of restricted memory pools * Added OP-TEE ABI both with and without FF-A for dynamic restricted memory * Added support for FF-A with FFA_LEND Changes since the V1 RFC: * Based on v6.11 * Complete rewrite, replacing the restricted heap with TEE_IOC_RSTMEM_ALLOC Changes since Olivier's post [2]: * Based on Yong Wu's post [1] where much of dma-buf handling is done in the generic restricted heap * Simplifications and cleanup * New commit message for "dma-buf: heaps: add Linaro restricted dmabuf heap support" * Replaced the word "secure" with "restricted" where applicable Jens Wiklander (7): tee: add restricted memory allocation tee: add TEE_IOC_RSTMEM_FD_INFO optee: account for direction while converting parameters optee: sync secure world ABI headers optee: support restricted memory allocation optee: FF-A: dynamic restricted memory allocation optee: smc abi: dynamic restricted memory allocation drivers/tee/Makefile | 1 + drivers/tee/optee/Makefile | 1 + drivers/tee/optee/call.c | 10 +- drivers/tee/optee/core.c | 1 + drivers/tee/optee/ffa_abi.c | 179 +++++++++++++- drivers/tee/optee/optee_ffa.h | 27 ++- drivers/tee/optee/optee_msg.h | 65 ++++- drivers/tee/optee/optee_private.h | 75 ++++-- drivers/tee/optee/optee_smc.h | 71 +++++- drivers/tee/optee/rpc.c | 31 ++- drivers/tee/optee/rstmem.c | 389 ++++++++++++++++++++++++++++++ drivers/tee/optee/smc_abi.c | 215 +++++++++++++++-- drivers/tee/tee_core.c | 69 +++++- drivers/tee/tee_private.h | 4 + drivers/tee/tee_rstmem.c | 188 +++++++++++++++ drivers/tee/tee_shm.c | 2 + drivers/tee/tee_shm_pool.c | 69 +++++- include/linux/tee_core.h | 15 ++ include/linux/tee_drv.h | 2 + include/uapi/linux/tee.h | 71 +++++- 20 files changed, 1409 insertions(+), 76 deletions(-) create mode 100644 drivers/tee/optee/rstmem.c create mode 100644 drivers/tee/tee_rstmem.c base-commit: a64dcfb451e254085a7daee5fe51bf22959d52d3 -- 2.43.0

1 year, 4 months

2
8
0 0

[PATCH v3] tee: optee: Fix supplicant wait loop

by Sumit Garg

OP-TEE supplicant is a user-space daemon and it's possible for it be hung or crashed or killed in the middle of processing an OP-TEE RPC call. It becomes more complicated when there is incorrect shutdown ordering of the supplicant process vs the OP-TEE client application which can eventually lead to system hang-up waiting for the closure of the client application. Allow the client process waiting in kernel for supplicant response to be killed rather than indefinitely waiting in an unkillable state. Also, a normal uninterruptible wait should not have resulted in the hung-task watchdog getting triggered, but the endless loop would. This fixes issues observed during system reboot/shutdown when supplicant got hung for some reason or gets crashed/killed which lead to client getting hung in an unkillable state. It in turn lead to system being in hung up state requiring hard power off/on to recover. Fixes: 4fb0a5eb364d ("tee: add OP-TEE driver") Suggested-by: Arnd Bergmann <arnd(a)arndb.de> Cc: <stable(a)vger.kernel.org> Signed-off-by: Sumit Garg <sumit.garg(a)linaro.org> --- Changes in v3: - Use mutex_lock() instead of mutex_lock_killable(). - Update commit message to incorporate Arnd's feedback. Changes in v2: - Switch to killable wait instead as suggested by Arnd instead of supplicant timeout. It atleast allow the client to wait for supplicant in killable state which in turn allows system to reboot or shutdown gracefully. drivers/tee/optee/supp.c | 35 ++++++++--------------------------- 1 file changed, 8 insertions(+), 27 deletions(-) diff --git a/drivers/tee/optee/supp.c b/drivers/tee/optee/supp.c index 322a543b8c27..d0f397c90242 100644 --- a/drivers/tee/optee/supp.c +++ b/drivers/tee/optee/supp.c @@ -80,7 +80,6 @@ u32 optee_supp_thrd_req(struct tee_context *ctx, u32 func, size_t num_params, struct optee *optee = tee_get_drvdata(ctx->teedev); struct optee_supp *supp = &optee->supp; struct optee_supp_req *req; - bool interruptable; u32 ret; /* @@ -111,36 +110,18 @@ u32 optee_supp_thrd_req(struct tee_context *ctx, u32 func, size_t num_params, /* * Wait for supplicant to process and return result, once we've * returned from wait_for_completion(&req->c) successfully we have - * exclusive access again. + * exclusive access again. Allow the wait to be killable such that + * the wait doesn't turn into an indefinite state if the supplicant + * gets hung for some reason. */ - while (wait_for_completion_interruptible(&req->c)) { + if (wait_for_completion_killable(&req->c)) { mutex_lock(&supp->mutex); - interruptable = !supp->ctx; - if (interruptable) { - /* - * There's no supplicant available and since the - * supp->mutex currently is held none can - * become available until the mutex released - * again. - * - * Interrupting an RPC to supplicant is only - * allowed as a way of slightly improving the user - * experience in case the supplicant hasn't been - * started yet. During normal operation the supplicant - * will serve all requests in a timely manner and - * interrupting then wouldn't make sense. - */ - if (req->in_queue) { - list_del(&req->link); - req->in_queue = false; - } + if (req->in_queue) { + list_del(&req->link); + req->in_queue = false; } mutex_unlock(&supp->mutex); - - if (interruptable) { - req->ret = TEEC_ERROR_COMMUNICATION; - break; - } + req->ret = TEEC_ERROR_COMMUNICATION; } ret = req->ret; -- 2.43.0

1 year, 4 months

3
2
0 0

[PATCH v2] tee: optee: Fix supplicant wait loop

by Sumit Garg

OP-TEE supplicant is a user-space daemon and it's possible for it being hung or crashed or killed in the middle of processing an OP-TEE RPC call. It becomes more complicated when there is incorrect shutdown ordering of the supplicant process vs the OP-TEE client application which can eventually lead to system hang-up waiting for the closure of the client application. Allow the client process waiting in kernel for supplicant response to be killed rather than indefinitetly waiting in an unkillable state. This fixes issues observed during system reboot/shutdown when supplicant got hung for some reason or gets crashed/killed which lead to client getting hung in an unkillable state. It in turn lead to system being in hung up state requiring hard power off/on to recover. Fixes: 4fb0a5eb364d ("tee: add OP-TEE driver") Suggested-by: Arnd Bergmann <arnd(a)arndb.de> Cc: <stable(a)vger.kernel.org> Signed-off-by: Sumit Garg <sumit.garg(a)linaro.org> --- Changes in v2: - Switch to killable wait instead as suggested by Arnd instead of supplicant timeout. It atleast allow the client to wait for supplicant in killable state which in turn allows system to reboot or shutdown gracefully. drivers/tee/optee/supp.c | 32 +++++++------------------------- 1 file changed, 7 insertions(+), 25 deletions(-) diff --git a/drivers/tee/optee/supp.c b/drivers/tee/optee/supp.c index 322a543b8c27..3fbfa9751931 100644 --- a/drivers/tee/optee/supp.c +++ b/drivers/tee/optee/supp.c @@ -80,7 +80,6 @@ u32 optee_supp_thrd_req(struct tee_context *ctx, u32 func, size_t num_params, struct optee *optee = tee_get_drvdata(ctx->teedev); struct optee_supp *supp = &optee->supp; struct optee_supp_req *req; - bool interruptable; u32 ret; /* @@ -111,36 +110,19 @@ u32 optee_supp_thrd_req(struct tee_context *ctx, u32 func, size_t num_params, /* * Wait for supplicant to process and return result, once we've * returned from wait_for_completion(&req->c) successfully we have - * exclusive access again. + * exclusive access again. Allow the wait to be killable such that + * the wait doesn't turn into an indefinite state if the supplicant + * gets hung for some reason. */ - while (wait_for_completion_interruptible(&req->c)) { - mutex_lock(&supp->mutex); - interruptable = !supp->ctx; - if (interruptable) { - /* - * There's no supplicant available and since the - * supp->mutex currently is held none can - * become available until the mutex released - * again. - * - * Interrupting an RPC to supplicant is only - * allowed as a way of slightly improving the user - * experience in case the supplicant hasn't been - * started yet. During normal operation the supplicant - * will serve all requests in a timely manner and - * interrupting then wouldn't make sense. - */ + if (wait_for_completion_killable(&req->c)) { + if (!mutex_lock_killable(&supp->mutex)) { if (req->in_queue) { list_del(&req->link); req->in_queue = false; } + mutex_unlock(&supp->mutex); } - mutex_unlock(&supp->mutex); - - if (interruptable) { - req->ret = TEEC_ERROR_COMMUNICATION; - break; - } + req->ret = TEEC_ERROR_COMMUNICATION; } ret = req->ret; -- 2.43.0

1 year, 4 months

3
5
0 0

[PATCH] tee: optee: Add support for supplicant timeout

by Sumit Garg

OP-TEE supplicant is a user-space daemon and it's possible for it being crashed or killed in the middle of processing an OP-TEE RPC call. It becomes more complicated when there is incorrect shutdown ordering of the supplicant process vs the OP-TEE client application which can eventually lead to system hang-up waiting for the closure of the client application. In order to gracefully handle this scenario, let's add a long enough timeout to wait for supplicant to process requests. In case there is a timeout then we return a proper error code for the RPC request. Signed-off-by: Sumit Garg <sumit.garg(a)linaro.org> --- drivers/tee/optee/supp.c | 58 +++++++++++++++++++++++++--------------- 1 file changed, 36 insertions(+), 22 deletions(-) diff --git a/drivers/tee/optee/supp.c b/drivers/tee/optee/supp.c index 322a543b8c27..92e86ac4cdd4 100644 --- a/drivers/tee/optee/supp.c +++ b/drivers/tee/optee/supp.c @@ -7,6 +7,15 @@ #include <linux/uaccess.h> #include "optee_private.h" +/* + * OP-TEE supplicant timeout, the user-space supplicant may get + * crashed or killed while servicing an RPC call. This will just lead + * to OP-TEE client hung indefinitely just waiting for supplicant to + * serve requests which isn't expected. It is rather expected to fail + * gracefully with a timeout which is long enough. + */ +#define SUPP_TIMEOUT (msecs_to_jiffies(10000)) + struct optee_supp_req { struct list_head link; @@ -52,8 +61,10 @@ void optee_supp_release(struct optee_supp *supp) /* Abort all queued requests */ list_for_each_entry_safe(req, req_tmp, &supp->reqs, link) { - list_del(&req->link); - req->in_queue = false; + if (req->in_queue) { + list_del(&req->link); + req->in_queue = false; + } req->ret = TEEC_ERROR_COMMUNICATION; complete(&req->c); } @@ -82,6 +93,7 @@ u32 optee_supp_thrd_req(struct tee_context *ctx, u32 func, size_t num_params, struct optee_supp_req *req; bool interruptable; u32 ret; + int res = 1; /* * Return in case there is no supplicant available and @@ -108,28 +120,28 @@ u32 optee_supp_thrd_req(struct tee_context *ctx, u32 func, size_t num_params, /* Tell an eventual waiter there's a new request */ complete(&supp->reqs_c); - /* - * Wait for supplicant to process and return result, once we've - * returned from wait_for_completion(&req->c) successfully we have - * exclusive access again. - */ - while (wait_for_completion_interruptible(&req->c)) { + /* Wait for supplicant to process and return result */ + while (res) { + res = wait_for_completion_interruptible_timeout(&req->c, + SUPP_TIMEOUT); + /* Check if supplicant served the request */ + if (res > 0) + break; + mutex_lock(&supp->mutex); + /* + * There's no supplicant available and since the supp->mutex + * currently is held none can become available until the mutex + * released again. + * + * Interrupting an RPC to supplicant is only allowed as a way + * of slightly improving the user experience in case the + * supplicant hasn't been started yet. During normal operation + * the supplicant will serve all requests in a timely manner and + * interrupting then wouldn't make sense. + */ interruptable = !supp->ctx; - if (interruptable) { - /* - * There's no supplicant available and since the - * supp->mutex currently is held none can - * become available until the mutex released - * again. - * - * Interrupting an RPC to supplicant is only - * allowed as a way of slightly improving the user - * experience in case the supplicant hasn't been - * started yet. During normal operation the supplicant - * will serve all requests in a timely manner and - * interrupting then wouldn't make sense. - */ + if (interruptable || (res == 0)) { if (req->in_queue) { list_del(&req->link); req->in_queue = false; @@ -141,6 +153,8 @@ u32 optee_supp_thrd_req(struct tee_context *ctx, u32 func, size_t num_params, req->ret = TEEC_ERROR_COMMUNICATION; break; } + if (res == 0) + req->ret = TEE_ERROR_TIMEOUT; } ret = req->ret; -- 2.43.0

1 year, 4 months

3
17
0 0

Registering dynamic shared memory

by Patryk

Hi, I have some problems configuring dynamic shared memory on my platform, and thought that perhaps somebody could give me a hint. My SoC (LS1028A, board: LS1028A-RDB), according to reference manual has two DRAM regions: - DRAM region 0 : start address: 0x80000000, size: 0x80000000 - DRAM region 2: start address: 0x2080000000, size: 0x1F80000000 I tried two approaches: 1) In optee-os, in a part of code that handles my SoC I added a call to register DDR only for the first region: register_addr(0x80000000, 2G - some size for TZ DRAM) (similarly like in case of other SoCs) However when the system boots up, the optee driver logs the following information: [ 5.703831] optee: dynamic shared memory is enabled E/TC:0 0 std_entry_with_parg:234 Bad arg address 0x208100e000 It seems that there is some problem with an address that the driver wants to use 2) Apart from registering first region I also added a call that registers the second region so I ended up with two calls: register_addr(0x80000000, 2G - some size for TZ DRAM) register_ddr(0x2080000000, 0x1F80000000); Now the problem is different since the platform no longer boots, due to the panic with the following output: D/TC:0 0 discover_nsec_memory:1117 No non-secure memory found in external DT D/TC:0 0 carve_out_phys_mem:362 No need to carve out 0xfc000000 size 0x3e00000 D/TC:0 0 carve_out_phys_mem:362 No need to carve out 0xffe00000 size 0x200000 E/TC:0 0 Panic at /usr/src/debug/optee-os-qoriq/4.2.0+git/core/mm/core_mmu.c:490 <core_mmu_set_discovered_nsec_ddr> I'm wondering, what am I missing? Do I need to register both regions? If so, why does the optee panic when the second region gets registered? I would be grateful for some ideas. Best regards Patryk

1 year, 4 months

2
2
0 0

Linaro OP-TEE Contribution, LOC, monthly meeting January 28

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/ The TA-specific parts of fTPM have now been included in the first OP-TEE release in the optee_ftpm and we run fTPM in the OP-TEE OS CI loop at Github. Much of what we set out to do over half a year ago has been done, but there are some issues with the quality of the code. It doesn't compile without warnings and the coding style is inconsistent with the normal OP-TEE coding style (or anything else). Let's discuss how we can improve the status. Are there any other topics? Thanks, Jens

1 year, 4 months

1
0
0 0

libtomcrypt, AES-CTR: Missing counter-increment for non-crypto-accelerated archs?

by Jork Loeser (he/him)

(Please provide a better way of reporting should this ML not be a good forum for bug-reports/fixes) Hello all, While experimenting with OP-TEE OS on a non-ARM platform (x86, to be precise), I noticed xtest regression_4003 and regression_4017 to be failing. It appears that for AES-CTR encrypt/decrypt, optee_os/core/lib/libtomcrypt/src/modes/ctr/ctr_encrypt.c:s_ctr_encrypt()<https://github.com/OP-TEE/optee_os/blob/37de1791d97d0df56db0709b5d001f82159…> fails to increment the counter on block boundaries when passed data covers a whole block. I suppose that it is a non-problem for architectures having crypto acceleration hooked up, since ctr_encrypt() bypasses s_ctr_encrypt() in that case. The below fixes the behavior for my setup - xtest regression_4003 and regression_4017 pass as a result: diff --git a/core/lib/libtomcrypt/src/modes/ctr/ctr_encrypt.c b/core/lib/libtomcrypt/src/modes/ctr/ctr_encrypt.c index a23e33c05..2019de2b6 100644 --- a/core/lib/libtomcrypt/src/modes/ctr/ctr_encrypt.c +++ b/core/lib/libtomcrypt/src/modes/ctr/ctr_encrypt.c @@ -61,6 +61,7 @@ static int s_ctr_encrypt(const unsigned char *pt, unsigned char *ct, unsigned lo ct += ctr->blocklen; len -= ctr->blocklen; ctr->padlen = ctr->blocklen; + s_ctr_increment_counter(ctr); continue; } #endif I understand that you might prefer a full PR instead. Please accept my apologies for not providing such at this time; perhaps one of the maintainers (Jerome Forissier?) can take the above into consideration instead. If in doubt, consider above change as BSD-2-Clause'd. Best, Jork Loeser, Microsoft

1 year, 4 months

2
4
0 0

2026

2025

2024

2023

2022

2021

2020

OP-TEE