- OP-TEE - lists.trustedfirmware.org

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

by Jens Wiklander

Hi, Tomorrow, Tuesday, February 27 it's time for another LOC monthly meeting. For time and connection details see the calendar at https://www.trustedfirmware.org/meetings/ Moving the RPMB part of tee-supplicant processing into the kernel is making progress. The last patchset [1] got some constructive feedback and I'm preparing a new version based on that. [1] https://lore.kernel.org/lkml/20240131174347.510961-1-jens.wiklander@linaro.… Any other topics? Thanks, Jens

2 years, 2 months

1
0
0 0

[PATCH 0/3] TEE driver for Trusted Services

by Balint Dobszay

This series introduces a TEE driver for Trusted Services [1]. Trusted Services is a TrustedFirmware.org project that provides a framework for developing and deploying device Root of Trust services in FF-A [2] Secure Partitions. The project hosts the reference implementation of Arm Platform Security Architecture [3] for Arm A-profile devices. The FF-A Secure Partitions are accessible through the FF-A driver in Linux. However, the FF-A driver doesn't have a user space interface so user space clients currently cannot access Trusted Services. The goal of this TEE driver is to bridge this gap and make Trusted Services functionality accessible from user space. Changelog: RFC[4] -> v1: - Add patch for moving pool_op helper functions to the TEE subsystem, as suggested by Jens - Address comments from Sumit, add patch for documentation [1] https://www.trustedfirmware.org/projects/trusted-services/ [2] https://developer.arm.com/documentation/den0077/ [3] https://www.arm.com/architecture/security-features/platform-security [4] https://lore.kernel.org/linux-arm-kernel/20230927152145.111777-1-balint.dob… Balint Dobszay (3): tee: optee: Move pool_op helper functions tee: tstee: Add Trusted Services TEE driver Documentation: tee: Add TS-TEE driver Documentation/tee/index.rst | 1 + Documentation/tee/ts-tee.rst | 70 +++++ drivers/tee/Kconfig | 1 + drivers/tee/Makefile | 1 + drivers/tee/optee/core.c | 64 ---- drivers/tee/optee/ffa_abi.c | 6 +- drivers/tee/optee/optee_private.h | 12 - drivers/tee/optee/smc_abi.c | 10 +- drivers/tee/tee_shm.c | 65 ++++ drivers/tee/tstee/Kconfig | 11 + drivers/tee/tstee/Makefile | 3 + drivers/tee/tstee/core.c | 501 ++++++++++++++++++++++++++++++ drivers/tee/tstee/tstee_private.h | 92 ++++++ include/linux/tee_drv.h | 11 + include/uapi/linux/tee.h | 1 + 15 files changed, 765 insertions(+), 84 deletions(-) create mode 100644 Documentation/tee/ts-tee.rst create mode 100644 drivers/tee/tstee/Kconfig create mode 100644 drivers/tee/tstee/Makefile create mode 100644 drivers/tee/tstee/core.c create mode 100644 drivers/tee/tstee/tstee_private.h -- 2.34.1

2 years, 2 months

5
12
0 0

Calling OPTEE_SMC_CALL_GET_OS_UUID from driver code

by Marc Gonzalez

Hello, The driver code I'm working on hard-codes #define TEE_SMC_FAST_CALL_VAL(func_num) \ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, ARM_SMCCC_SMC_32, \ ARM_SMCCC_OWNER_TRUSTED_OS, (func_num)) #define TEE_SMC_FUNCID_CALLS_UID 0xFF01 #define TEE_SMC_CALLS_UID \ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, ARM_SMCCC_SMC_32, \ ARM_SMCCC_OWNER_TRUSTED_OS_END, \ TEE_SMC_FUNCID_CALLS_UID) arm_smccc_smc(TEE_SMC_CALLS_UID, 0, 0, 0/*is_swap*/, 0, 0, 0, 0, &res); dev_err(dev, "TEE UID %x %x %x %x\n", res.a0, res.a1, res.a2, res.a3); but it seems I would be required to somehow use OPTEE_SMC_CALL_GET_OS_UUID But it's not exported, and no code seems to use it...? $ git grep OPTEE_SMC_CALL_GET_OS_UUID Documentation/tee/op-tee.rst:- OPTEE_SMC_CALL_GET_OS_UUID returns the particular OP-TEE implementation, used drivers/tee/optee/optee_smc.h:#define OPTEE_SMC_CALL_GET_OS_UUID \ How do I make calls to OP-TEE from driver code? Regards, Marc Gonzalez

2 years, 3 months

2
3
0 0

Re: TEE on RPI4

by murali selvaraj

On Sun, Feb 18, 2024 at 12:24 PM murali selvaraj < muraliselvaraj2020(a)gmail.com> wrote: > Hi Team, > > We would like to know the support of OP-TEE support for RPI4. > If we have the support, can you please share the details. > > Thankx > Murali.S >

2 years, 3 months

2
1
0 0

[PATCH] tee: make tee_bus_type const

by Ricardo B. Marliere

Since commit d492cc2573a0 ("driver core: device.h: make struct bus_type a const *"), the driver core can properly handle constant struct bus_type, move the tee_bus_type variable to be a constant structure as well, placing it into read-only memory which can not be modified at runtime. Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Suggested-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Ricardo B. Marliere <ricardo(a)marliere.net> --- drivers/tee/tee_core.c | 2 +- include/linux/tee_drv.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/tee/tee_core.c b/drivers/tee/tee_core.c index 792d6fae4354..e59c20d74b36 100644 --- a/drivers/tee/tee_core.c +++ b/drivers/tee/tee_core.c @@ -1226,7 +1226,7 @@ static int tee_client_device_uevent(const struct device *dev, return add_uevent_var(env, "MODALIAS=tee:%pUb", dev_id); } -struct bus_type tee_bus_type = { +const struct bus_type tee_bus_type = { .name = "tee", .match = tee_client_device_match, .uevent = tee_client_device_uevent, diff --git a/include/linux/tee_drv.h b/include/linux/tee_drv.h index 911ddf92dcee..71632e3c5f18 100644 --- a/include/linux/tee_drv.h +++ b/include/linux/tee_drv.h @@ -482,7 +482,7 @@ static inline bool tee_param_is_memref(struct tee_param *param) } } -extern struct bus_type tee_bus_type; +extern const struct bus_type tee_bus_type; /** * struct tee_client_device - tee based device --- base-commit: 716f4aaa7b48a55c73d632d0657b35342b1fefd7 change-id: 20240213-bus_cleanup-tee-c25729bbcd7f Best regards, -- Ricardo B. Marliere <ricardo(a)marliere.net>

2 years, 3 months

4
3
0 0

[PATCH v2 0/3] Replay Protected Memory Block (RPMB) subsystem

by Jens Wiklander

Hi, It's been a while since Shyam posted the last version [1] of this patch set. I've pinged Shyam, but so far I've had no reply so I'm trying to make another attempt with the RPMB subsystem. If Shyam has other changes in mind than what I'm adding here I hope we'll find a way to cover that too. I'm calling it version two of the patchset since I'm trying to address all feedback on the previous version even if I'm starting a new thread. This patch set introduces a new RPMB subsystem, based on patches from [1], [2], and [3]. The RPMB subsystem aims at providing access to RPMB partitions to other kernel drivers, in particular the OP-TEE driver. A new user space ABI isn't needed, we can instead continue using the already present ABI when writing the RPMB key during production. I've added and removed things to keep only what is needed by the OP-TEE driver. Since the posting of [3], there has been major changes in the MMC subsystem so "mmc: block: register RPMB partition with the RPMB subsystem" is in practice completely rewritten. With this OP-TEE can access RPMB during early boot instead of having to wait for user space to become available as in the current design [4]. This will benefit the efi variables [5] since we wont rely on userspace as well as some TPM issues [6] that were solved. The OP-TEE driver finds the correct RPMB device to interact with by iterating over available devices until one is found with a programmed authentication matching the one OP-TEE is using. This enables coexisting users of other RPMBs since the owner can be determined by who knows the authentication key. I've put myself as a maintainer for the RPMB subsystem as I have an interest in the OP-TEE driver to keep this in good shape. However, if you'd rather see someone else taking the maintainership that's fine too. I'll help keep the subsystem updated regardless. [1] https://lore.kernel.org/lkml/20230722014037.42647-1-shyamsaini@linux.micros… [2] https://lore.kernel.org/lkml/20220405093759.1126835-2-alex.bennee@linaro.or… [3] https://lore.kernel.org/linux-mmc/1478548394-8184-2-git-send-email-tomas.wi… [4] https://optee.readthedocs.io/en/latest/architecture/secure_storage.html#rpm… [5] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… [6] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… Thanks, Jens Changes since Shyam's RFC: * Removed the remaining leftover rpmb_cdev_*() function calls * Refactored the struct rpmb_ops with all the previous ops replaced, in some sense closer to [3] with the route_frames() op * Added rpmb_route_frames() * Added struct rpmb_frame, enum rpmb_op_result, and enum rpmb_type from [3] * Removed all functions not needed in the OP-TEE use case * Added "mmc: block: register RPMB partition with the RPMB subsystem", based on the commit with the same name in [3] * Added "optee: probe RPMB device using RPMB subsystem" for integration with OP-TEE * Moved the RPMB driver into drivers/misc/rpmb-core.c * Added my name to MODULE_AUTHOR() in rpmb-core.c * Added an rpmb_mutex to serialize access to the IDA * Removed the target parameter from all rpmb_*() functions since it's currently unused Jens Wiklander (3): rpmb: add Replay Protected Memory Block (RPMB) subsystem mmc: block: register RPMB partition with the RPMB subsystem optee: probe RPMB device using RPMB subsystem MAINTAINERS | 7 + drivers/misc/Kconfig | 9 ++ drivers/misc/Makefile | 1 + drivers/misc/rpmb-core.c | 247 ++++++++++++++++++++++++++++++ drivers/mmc/core/block.c | 177 +++++++++++++++++++++ drivers/tee/optee/core.c | 1 + drivers/tee/optee/ffa_abi.c | 2 + drivers/tee/optee/optee_private.h | 6 + drivers/tee/optee/optee_rpc_cmd.h | 33 ++++ drivers/tee/optee/rpc.c | 221 ++++++++++++++++++++++++++ drivers/tee/optee/smc_abi.c | 2 + include/linux/rpmb.h | 184 ++++++++++++++++++++++ 12 files changed, 890 insertions(+) create mode 100644 drivers/misc/rpmb-core.c create mode 100644 include/linux/rpmb.h base-commit: 41bccc98fb7931d63d03f326a746ac4d429c1dd3 -- 2.34.1

2 years, 3 months

7
21
0 0

[PATCH v2 0/4] Introduction of a remoteproc tee to load signed firmware

by Arnaud Pouliquen

Updates from the previous version [1] - fix issues reported by kernel test robot, - address Rob Herring comment on bindings. [1] https://lore.kernel.org/linux-arm-kernel/20240115135249.296822-1-arnaud.pou… 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 (4): remoteproc: Add TEE support 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 | 52 ++- drivers/remoteproc/Kconfig | 9 + drivers/remoteproc/Makefile | 1 + drivers/remoteproc/stm32_rproc.c | 233 +++++++++-- drivers/remoteproc/tee_remoteproc.c | 393 ++++++++++++++++++ include/linux/tee_remoteproc.h | 99 +++++ 6 files changed, 740 insertions(+), 47 deletions(-) create mode 100644 drivers/remoteproc/tee_remoteproc.c create mode 100644 include/linux/tee_remoteproc.h base-commit: 0dd3ee31125508cd67f7e7172247f05b7fd1753a -- 2.25.1

2 years, 3 months

5
25
0 0

Why UBSAN is marked as using a lot of memory?

by Igor Zhbanov

Hello, In the configuration makefile mk/config.mk there are following lines: # Enable support for detected undefined behavior in C # Uses a lot of memory, can't be enabled by default CFG_CORE_SANITIZE_UNDEFINED ?= n I've read the sources of the conditionally compiled ubsan.c and, IIUC, how UBSAN is working (mostly by adding simple checks), I don't understand, why UBSAN is marked as using a lot of memory. Is this comment still valid? Thank you.

2 years, 3 months

3
5
0 0

Re: [TF-A] Re: Handling of normal world interrupts with BL31 PSCI handler

by Olivier Deprez

Hi, Cc the OP-TEE mailing list, as I sense this might be more of an OP-TEE (/ OPTEED) design question than TF-A generic. I agree with Manish/Achin the best way to eliminate the return by NS interrupt while OP-TEE kernel runs handling a PSCI request is to mask interrupts globally in the GIC e.g. from within opteed_system_reset? Additional questions: On https://github.com/ARM-software/arm-trusted-firmware/blob/master/lib/psci/p… The PSCI layer calls into OP-TEE SPD and then resumes OP-TEE to handle the PSCI call in a platform defined manner. As suggested here https://github.com/ARM-software/arm-trusted-firmware/blob/master/services/s… , it looks this invocation is not supposed to return into TF-A? Did you redefine the weak psci_system_reset function within OP-TEE for your platform? Is this function designed to end up in a loop and never returns to TF-A? As a side question, is this an issue that the TF-A's PSCI platform hook is possibly never called https://github.com/ARM-software/arm-trusted-firmware/blob/master/lib/psci/p… ? Regards, Olivier. ________________________________ From: Neely, Brian via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 13 November 2023 19:01 To: Manish Pandey2 <Manish.Pandey2(a)arm.com>; tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org>; Ethridge, Caleb <Caleb.Ethridge(a)analog.com> Subject: [TF-A] Re: Handling of normal world interrupts with BL31 PSCI handler Hi Manish, Just following up on your comment below. Are you planning to provide guidance as to which PSCI calls should have NS interrupts masked? Are these changes that should go in the mainline TF-A repo, or do you believe they are specific to our use case? Thanks, Brian From: Manish Pandey2 via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: Friday, November 10, 2023 11:31 AM To: tf-a(a)lists.trustedfirmware.org; Ethridge, Caleb <Caleb.Ethridge(a)analog.com> Subject: [TF-A] Re: Handling of normal world interrupts with BL31 PSCI handler [External] Hi Caleb, The quick answer to your query is to mask the NS interrupts in BL31 (option a), You should not remove the callback to OPTEE as it may need to do its own state maintained before system RESET. There are other scenarios in PSCI (e.g. CPU power down) path which need to consider disabling NS interrupts before invoking Secure world hooks, will provide further analysis on those later. Thanks Manish Pandey ________________________________ From: Caleb Ethridge via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Sent: 10 November 2023 15:12 To: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Subject: [TF-A] Handling of normal world interrupts with BL31 PSCI handler Hello, If normal world interrupts are received while invoking TF-A's PSCI reset handler, we have observed that the reset can be aborted. In TF-A's PSCI reset handler, a call out to OP-TEE is made before performing the platform-specific reset: https://github.com/ARM-software/arm-trusted-firmware/blob/master/lib/psci/p…<https://urldefense.com/v3/__https:/github.com/ARM-software/arm-trusted-firm…> https://github.com/ARM-software/arm-trusted-firmware/blob/master/services/s…<https://urldefense.com/v3/__https:/github.com/ARM-software/arm-trusted-firm…> When OP-TEE is entered, it is possible to receive foreign (normal world) interrupts, which invokes the procedure described here: https://optee.readthedocs.io/en/3.16.0/architecture/core.html#deliver-non-s…<https://urldefense.com/v3/__https:/optee.readthedocs.io/en/3.16.0/architect…> When the SMC call is aborted as described above, this results in the reboot failing. Linux does not retry the PSCI reset (https://github.com/torvalds/linux/blob/master/drivers/firmware/psci/psci.c#…<https://urldefense.com/v3/__https:/github.com/torvalds/linux/blob/master/dr…>). This makes sense because it is not expecting the SMC call to fail (it expected to make an uninterruptable SMC call into the secure monitor, not a call into OP-TEE). If OP-TEE itself is setup to handle PSCI reset calls, it also handles them in (uninterruptable) SMC context: https://github.com/OP-TEE/optee_os/blob/master/core/arch/arm/sm/psci.c#L140<https://urldefense.com/v3/__https:/github.com/OP-TEE/optee_os/blob/master/c…> https://github.com/OP-TEE/optee_os/blob/master/core/arch/arm/sm/sm_a32.S#L96<https://urldefense.com/v3/__https:/github.com/OP-TEE/optee_os/blob/master/c…> Based on this, we see two possible solutions: a) Masking the non-secure interrupts in BL31 while we are doing a reset b) Removing the call to OPTEE in the reset handler so that we never leave the SMC context Which option do you suggest? Or are we missing an important detail here? Thanks, Caleb -- TF-A mailing list -- tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> To unsubscribe send an email to tf-a-leave(a)lists.trustedfirmware.org<mailto:tf-a-leave@lists.trustedfirmware.org>

2 years, 3 months

4
5
0 0

[PATCH] optee: support wq_sleep_timeout

by gavin.liu

From: Gavin Liu <gavin.liu(a)mediatek.com> Add wq_sleep_timeout to support self waking when timeout for secure driver usage. Signed-off-by: Gavin Liu <gavin.liu(a)mediatek.com> --- drivers/tee/optee/notif.c | 9 +++++++-- drivers/tee/optee/optee_private.h | 2 +- drivers/tee/optee/rpc.c | 10 ++++++++-- 3 files changed, 16 insertions(+), 5 deletions(-) diff --git a/drivers/tee/optee/notif.c b/drivers/tee/optee/notif.c index 05212842b0a5..d5e5c0645609 100644 --- a/drivers/tee/optee/notif.c +++ b/drivers/tee/optee/notif.c @@ -29,7 +29,7 @@ static bool have_key(struct optee *optee, u_int key) return false; } -int optee_notif_wait(struct optee *optee, u_int key) +int optee_notif_wait(struct optee *optee, u_int key, u32 timeout) { unsigned long flags; struct notif_entry *entry; @@ -70,7 +70,12 @@ int optee_notif_wait(struct optee *optee, u_int key) * Unlock temporarily and wait for completion. */ spin_unlock_irqrestore(&optee->notif.lock, flags); - wait_for_completion(&entry->c); + if (timeout != 0) { + if (!wait_for_completion_timeout(&entry->c, timeout)) + rc = -ETIMEDOUT; + } else { + wait_for_completion(&entry->c); + } spin_lock_irqsave(&optee->notif.lock, flags); list_del(&entry->link); diff --git a/drivers/tee/optee/optee_private.h b/drivers/tee/optee/optee_private.h index 7a5243c78b55..da990c4016ec 100644 --- a/drivers/tee/optee/optee_private.h +++ b/drivers/tee/optee/optee_private.h @@ -252,7 +252,7 @@ struct optee_call_ctx { int optee_notif_init(struct optee *optee, u_int max_key); void optee_notif_uninit(struct optee *optee); -int optee_notif_wait(struct optee *optee, u_int key); +int optee_notif_wait(struct optee *optee, u_int key, u32 timeout); int optee_notif_send(struct optee *optee, u_int key); u32 optee_supp_thrd_req(struct tee_context *ctx, u32 func, size_t num_params, diff --git a/drivers/tee/optee/rpc.c b/drivers/tee/optee/rpc.c index e69bc6380683..14e6246aaf05 100644 --- a/drivers/tee/optee/rpc.c +++ b/drivers/tee/optee/rpc.c @@ -130,6 +130,8 @@ static void handle_rpc_func_cmd_i2c_transfer(struct tee_context *ctx, static void handle_rpc_func_cmd_wq(struct optee *optee, struct optee_msg_arg *arg) { + int rc = 0; + if (arg->num_params != 1) goto bad; @@ -139,7 +141,8 @@ static void handle_rpc_func_cmd_wq(struct optee *optee, switch (arg->params[0].u.value.a) { case OPTEE_RPC_NOTIFICATION_WAIT: - if (optee_notif_wait(optee, arg->params[0].u.value.b)) + rc = optee_notif_wait(optee, arg->params[0].u.value.b, arg->params[0].u.value.c); + if (rc) goto bad; break; case OPTEE_RPC_NOTIFICATION_SEND: @@ -153,7 +156,10 @@ static void handle_rpc_func_cmd_wq(struct optee *optee, arg->ret = TEEC_SUCCESS; return; bad: - arg->ret = TEEC_ERROR_BAD_PARAMETERS; + if (rc == -ETIMEDOUT) + arg->ret = TEEC_ERROR_BUSY; + else + arg->ret = TEEC_ERROR_BAD_PARAMETERS; } static void handle_rpc_func_cmd_wait(struct optee_msg_arg *arg) -- 2.18.0

2 years, 3 months

3
2
0 0

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

by Jens Wiklander

Hi, Tomorrow, Tuesday, January 25 it's time for another LOC monthly meeting. For time and connection details see the calendar at https://www.trustedfirmware.org/meetings/ - OP-TEE 4.1.0 has been released - There's an ongoing effort to move tee-supplicant processing into the kernel to avoid user space dependency during boot Any other topics? Thanks, Jens

2 years, 4 months

1
0
0 0

تمت إضافتك إلى 🔔 🔔 الدار العربيه للتنميه الاداريه 2024 🔔 🔔

by Google Groups

مرحبًا يا op-tee(a)lists.trustedfirmware.xn--org-nwe تمت إضافتك من قِبل marwa.hr.ahad44(a)gmail.com إلى المجموعة 🔔 🔔 الدار العربيه للتنميه الاداريه 2024 🔔 🔔. https://groups.google.com/d/forum/rehan212 تتيح لك "مجموعات Google" إنشاء منتديات على الإنترنت ومجموعات مستندة إلى البريد الإلكتروني والمشاركة فيها مع الاستمتاع بتجربة منتدى غنية. ويمكنك أيضًا استخدام المجموعة لمشاركة المستندات والصور والتقاويم والدعوات وغيرها من الموارد. إذا كنت لا ترغب في أن تكون عضوًا في هذه المجموعة أو تعتقد أنها قد تتضمن محتوى غير مرغوب فيه: * يمكنك إلغاء الاشتراك في هذه المجموعة على https://groups.google.com/d/forum/rehan212/unsubscribe/AHZ7KVNf4gqL9LBbrqyF… أو عن طريق إرسال رسالة إلكترونية إلى rehan212+unsubscribe(a)googlegroups.com * يمكنك الإبلاغ عن الإساءة في هذه المجموعة على https://groups.google.com/d/abuse/AJmrmCunE4xS9a4JyD6Q8ohLuifBFq1lHYcv31NJL… * يمكنك اختيار عدم تلقّي أي إشعارات بشأن جميع أنشطة "مجموعات Google" المستقبلية على https://groups.google.com/d/optout زيارة مركز مساعدة "مجموعات Google" في https://support.google.com/groups/answer/46601?hl=ar.

2 years, 4 months

1
0
0 0

OP-TEE 4.1.0 has been released

by Jens Wiklander

Hi, I'm pleased to announce that OP-TEE version 4.1.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]. A big thank you to everyone who participated with contributions and helping out with testing the release [3]. [1] https://github.com/OP-TEE/optee_os/blob/master/CHANGELOG.md [2] https://www.trustedfirmware.org/blog/ [3] https://github.com/OP-TEE/optee_os/commit/18b424c23aa5a798dfe2e4d20b4bde391… Regards, Jens

2 years, 4 months

1
0
0 0

Why are there to stripped.elf for optee_test_lib and optee_test_lib_dl TAs?

by Jan Claußen

I am currently offline-signing Trusted Applications and and I have realized that there are no stripped.elf files for the above TAs. Why is that and how can I offline-sign them?

2 years, 4 months

1
1
0 0

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

by Arnaud Pouliquen

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 (4): remoteproc: Add TEE support 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 | 53 ++- drivers/remoteproc/Kconfig | 10 + drivers/remoteproc/Makefile | 1 + drivers/remoteproc/stm32_rproc.c | 233 +++++++++-- drivers/remoteproc/tee_remoteproc.c | 393 ++++++++++++++++++ include/linux/tee_remoteproc.h | 99 +++++ 6 files changed, 742 insertions(+), 47 deletions(-) create mode 100644 drivers/remoteproc/tee_remoteproc.c create mode 100644 include/linux/tee_remoteproc.h -- 2.25.1

2 years, 4 months

4
11
0 0

HSM offline signing of TAs

by Jan Claußen

I have recently commited some changes to the OP-TEE docs regarding the offline signing of TAs. I have now revisited my work after the holidays and the signing process is now failing with ERROR:sign_encrypt.py:Verification failed, ignoring given signature. although I am sure not to have changed anything. There is no TA being producd anymore. I am currently not sure if I made a mistake and did not see this, although I think I should have realized that no TAs are produced successfully. I am currently a bit pressed for time and was hoping that someone could assist me with the signing process. In the previous version there was a header prepended to the file that is to be signed echo "0000: 3031300D 06096086 48016503 04020105 000420" | \ xxd -c 19 -r > /tmp/sighdr cat /tmp/sighdr $(base64 --decode digestfile) > /tmp/hashtosign This script did not work and I omitted it. Can someone tell me why this was needed in the first place or how I could fix this step? I tried fixing the step as follows echo "0000: 3031300D 06096086 48016503 04020105 000420" | \ xxd -c 19 -r > /tmp/sighdr base64 --decode digestfile > /tmp/digestfile cat /tmp/sighdr /tmp/digestfile > /tmp/hashtosign but the pkcs11-tool then complains that the signature is too long. Any help appreciated! --- Jan

2 years, 4 months

1
1
0 0

Preparing for OP-TEE 4.1.0

by Jens Wiklander

[BCC all OP-TEE maintainers] Hi OP-TEE maintainers & contributors, OP-TEE v4.1.0 is scheduled to be released on 2024-01-19. 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/6574. As usual, we will create a release candidate tag one week before the release date for final testing. In addition to that you can find some additional information related to releases here: https://optee.readthedocs.io/en/latest/general/releases.html Thanks, Jens

2 years, 4 months

1
2
0 0

Secure interrupt while sending direct response

by Jens Wiklander

Hi all, I'm testing FF-A notifications with OP-TEE and Hafnium. I'm using interrupts from the secure uart as a trigger to set a notification for the normal world. Sometimes when testing I run into: VERBOSE: Secure virtual interrupt not yet serviced by SP 8001. FFA_MSG_SEND_DIRECT_RESP interrupted Hafnium then returns an FFA_ERROR (code -5) as a response to the FFA_MSG_SEND_DIRECT_RESP OP-TEE was just exiting with. After some digging in the code I find a comment at the top of plat_ffa_is_direct_response_interrupted() https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/arch/aarch64/p… /* * A secure interrupt might trigger while the target SP is currently * running to send a direct response. SPMC would then inject virtual * interrupt to vCPU of target SP and resume it. * However, it is possible that the S-EL1 SP could have its interrupts * masked and hence might not handle the virtual interrupt before * sending direct response message. In such a scenario, SPMC must * return an error with code FFA_INTERRUPTED to inform the S-EL1 SP of * a pending interrupt and allow it to be handled before sending the * direct response. */ The specification doesn't mention this as a valid error code for FFA_MSG_SEND_DIRECT_RESP. Is this something we can expect to be added to the specification or at least something OP-TEE has to be prepared to handle regardless? As far as I can tell there's no way of guaranteeing that Hafnium will not return this error for FFA_MSG_SEND_DIRECT_RESP. Even if we were able to execute the smc instruction with secure interrupts unmasked, what if the interrupt is raised just after the smc instruction has been trapped in Hafnium? It is a bit inconvenient as it means saving the registers passed to the smc instruction to be able to restart the smc instruction with the same arguments. It seems we may need to redesign the exit procedure. It would be nice with an example of how an S-EL1 SP is supposed to exit with FFA_MSG_SEND_DIRECT_RESP. Thoughts? Thanks, Jens

2 years, 5 months

3
7
0 0

[GIT PULL] Improved TEE shared buffer support for v6.8

by Jens Wiklander

Hello arm-soc maintainers, Please pull this patch to add vmalloc support for shared buffer registration with the secure world. Thanks, Jens The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86: Linux 6.7-rc1 (2023-11-12 16:19:07 -0800) are available in the Git repository at: https://git.linaro.org/people/jens.wiklander/linux-tee.git tags/tee-iov-iter-for-v6.8 for you to fetch changes up to 7bdee41575919773818e525ea19e54eb817770af: tee: Use iov_iter to better support shared buffer registration (2023-12-13 07:23:22 +0100) ---------------------------------------------------------------- TEE: improve shared buffer registration compatibility ---------------------------------------------------------------- Arnaud Pouliquen (1): tee: Use iov_iter to better support shared buffer registration drivers/tee/tee_shm.c | 78 +++++++++++++++++++++++++++------------------------ 1 file changed, 42 insertions(+), 36 deletions(-)

2 years, 5 months

1
0
0 0

[GIT PULL] OP-TEE cleanup for v6.8

by Jens Wiklander

Hello arm-soc maintainers, Please pull these two small patches for the OP-TEE driver that remove a redundant custom workqueue and add a description of an argument of a optee_handle_rpc(). Note that this pull request is made on top of optee-supplicant-fix-for-v6.7 7269cba53d90 ("tee: optee: Fix supplicant based device enumeration") which was merged into v6.7-rc5, but in turn was based on top of v6.6. I did it like this because the Tested-bys where provided in this context. Thanks, Jens The following changes since commit 7269cba53d906cf257c139d3b3a53ad272176bca: tee: optee: Fix supplicant based device enumeration (2023-11-03 09:27:20 +0100) are available in the Git repository at: https://git.linaro.org/people/jens.wiklander/linux-tee.git tags/optee-cleanup-for-v6.8 for you to fetch changes up to b19773a1c6c02f5efc35e9f506aeddd2c7d2ac29: optee: add missing description of RPC argument reference (2023-12-11 15:02:12 +0100) ---------------------------------------------------------------- OP-TEE cleanup - Remove a redundant custom workqueue in the OP-TEE driver. - Fix a missing description of an argument to optee_handle_rpc(). ---------------------------------------------------------------- Etienne Carriere (1): optee: add missing description of RPC argument reference Sumit Garg (1): tee: optee: Remove redundant custom workqueue drivers/tee/optee/core.c | 13 ++----------- drivers/tee/optee/optee_private.h | 2 -- drivers/tee/optee/smc_abi.c | 1 + 3 files changed, 3 insertions(+), 13 deletions(-)

2 years, 5 months

1
0
0 0

[PATCH v5] tee: Use iov_iter to better support shared buffer registration

by Arnaud Pouliquen

Currently it's not possible to register kernel buffers with TEE which are allocated via vmalloc. Use iov_iter and associated helper functions to manage the page registration for all type of memories. Suggested-by: Christoph Hellwig <hch(a)infradead.org> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen(a)foss.st.com> --- Update from V4 to V5: - replace import_ubuf() by iov_iter_ubuf(), - fix comment in register_shm_helper() function. Update from V3 to V4: - improve commit message, - use import_ubuf() instead of iov_iter_init(), - move shm_get_kernel_pages in register_shm_helper, - put back untagged_addr in register_shm_helper(), - move the comment related to pin pages from shm_get_kernel_pages() to register_shm_helper(). Update from V2 to V3: - break lines longer than 80 columns. Update from V1 to V2: - replace ITER_SOURCE by ITER_DEST flag in tee_shm_register_user_buf(), - replace IS_ERR_OR NULL(shm) by IS_ERR(shm) in tee_shm_register_user_buf(). V1: The support of buffer registration allocated with vmalloc is no more available since c83900393aa1 ("tee: Remove vmalloc page support"). This patch is an alternative to a revert and resulted from a discussion with Christopher Hellwig [1]. This patch has been tested using xtest tool in optee qemu environment [2] and using the series related to the remoteproc tee that should be proposed soon [3]. References: [1] https://lore.kernel.org/linux-arm-kernel/18a8528d-7d9d-6ed0-0045-5ee47dd39f… [2] https://optee.readthedocs.io/en/latest/building/devices/qemu.html#build-ins… [3] https://lore.kernel.org/linux-arm-kernel/18a8528d-7d9d-6ed0-0045-5ee47dd39f… --- drivers/tee/tee_shm.c | 78 +++++++++++++++++++++++-------------------- 1 file changed, 42 insertions(+), 36 deletions(-) diff --git a/drivers/tee/tee_shm.c b/drivers/tee/tee_shm.c index 673cf0359494..731d9028b67f 100644 --- a/drivers/tee/tee_shm.c +++ b/drivers/tee/tee_shm.c @@ -22,23 +22,12 @@ static void shm_put_kernel_pages(struct page **pages, size_t page_count) put_page(pages[n]); } -static int shm_get_kernel_pages(unsigned long start, size_t page_count, - struct page **pages) +static void shm_get_kernel_pages(struct page **pages, size_t page_count) { - struct page *page; size_t n; - if (WARN_ON_ONCE(is_vmalloc_addr((void *)start) || - is_kmap_addr((void *)start))) - return -EINVAL; - - page = virt_to_page((void *)start); - for (n = 0; n < page_count; n++) { - pages[n] = page + n; + for (n = 0; n < page_count; n++) get_page(pages[n]); - } - - return page_count; } static void release_registered_pages(struct tee_shm *shm) @@ -214,13 +203,14 @@ struct tee_shm *tee_shm_alloc_priv_buf(struct tee_context *ctx, size_t size) EXPORT_SYMBOL_GPL(tee_shm_alloc_priv_buf); static struct tee_shm * -register_shm_helper(struct tee_context *ctx, unsigned long addr, - size_t length, u32 flags, int id) +register_shm_helper(struct tee_context *ctx, struct iov_iter *iter, u32 flags, + int id) { struct tee_device *teedev = ctx->teedev; struct tee_shm *shm; - unsigned long start; - size_t num_pages; + unsigned long start, addr; + size_t num_pages, off; + ssize_t len; void *ret; int rc; @@ -245,31 +235,38 @@ register_shm_helper(struct tee_context *ctx, unsigned long addr, shm->flags = flags; shm->ctx = ctx; shm->id = id; - addr = untagged_addr(addr); + addr = untagged_addr((unsigned long)iter_iov_addr(iter)); start = rounddown(addr, PAGE_SIZE); - shm->offset = addr - start; - shm->size = length; - num_pages = (roundup(addr + length, PAGE_SIZE) - start) / PAGE_SIZE; + num_pages = iov_iter_npages(iter, INT_MAX); + if (!num_pages) { + ret = ERR_PTR(-ENOMEM); + goto err_ctx_put; + } + shm->pages = kcalloc(num_pages, sizeof(*shm->pages), GFP_KERNEL); if (!shm->pages) { ret = ERR_PTR(-ENOMEM); goto err_free_shm; } - if (flags & TEE_SHM_USER_MAPPED) - rc = pin_user_pages_fast(start, num_pages, FOLL_WRITE, - shm->pages); - else - rc = shm_get_kernel_pages(start, num_pages, shm->pages); - if (rc > 0) - shm->num_pages = rc; - if (rc != num_pages) { - if (rc >= 0) - rc = -ENOMEM; - ret = ERR_PTR(rc); - goto err_put_shm_pages; + len = iov_iter_extract_pages(iter, &shm->pages, LONG_MAX, num_pages, 0, + &off); + if (unlikely(len <= 0)) { + ret = len ? ERR_PTR(len) : ERR_PTR(-ENOMEM); + goto err_free_shm_pages; } + /* + * iov_iter_extract_kvec_pages does not get reference on the pages, + * get a reference on them. + */ + if (iov_iter_is_kvec(iter)) + shm_get_kernel_pages(shm->pages, num_pages); + + shm->offset = off; + shm->size = len; + shm->num_pages = num_pages; + rc = teedev->desc->ops->shm_register(ctx, shm, shm->pages, shm->num_pages, start); if (rc) { @@ -279,10 +276,11 @@ register_shm_helper(struct tee_context *ctx, unsigned long addr, return shm; err_put_shm_pages: - if (flags & TEE_SHM_USER_MAPPED) + if (!iov_iter_is_kvec(iter)) unpin_user_pages(shm->pages, shm->num_pages); else shm_put_kernel_pages(shm->pages, shm->num_pages); +err_free_shm_pages: kfree(shm->pages); err_free_shm: kfree(shm); @@ -307,6 +305,7 @@ struct tee_shm *tee_shm_register_user_buf(struct tee_context *ctx, u32 flags = TEE_SHM_USER_MAPPED | TEE_SHM_DYNAMIC; struct tee_device *teedev = ctx->teedev; struct tee_shm *shm; + struct iov_iter iter; void *ret; int id; @@ -319,7 +318,8 @@ struct tee_shm *tee_shm_register_user_buf(struct tee_context *ctx, if (id < 0) return ERR_PTR(id); - shm = register_shm_helper(ctx, addr, length, flags, id); + iov_iter_ubuf(&iter, ITER_DEST, (void __user *)addr, length); + shm = register_shm_helper(ctx, &iter, flags, id); if (IS_ERR(shm)) { mutex_lock(&teedev->mutex); idr_remove(&teedev->idr, id); @@ -352,8 +352,14 @@ struct tee_shm *tee_shm_register_kernel_buf(struct tee_context *ctx, void *addr, size_t length) { u32 flags = TEE_SHM_DYNAMIC; + struct kvec kvec; + struct iov_iter iter; + + kvec.iov_base = addr; + kvec.iov_len = length; + iov_iter_kvec(&iter, ITER_DEST, &kvec, 1, length); - return register_shm_helper(ctx, (unsigned long)addr, length, flags, -1); + return register_shm_helper(ctx, &iter, flags, -1); } EXPORT_SYMBOL_GPL(tee_shm_register_kernel_buf); -- 2.25.1

2 years, 5 months

3
2
0 0

[PATCH v9 0/6] introduce tee-based EFI Runtime Variable Service

by Masahisa Kojima

This series introduces the tee based EFI Runtime Variable Service. The eMMC device is typically owned by the non-secure world(linux in this case). There is an existing solution utilizing eMMC RPMB partition for EFI Variables, it is implemented by interacting with OP-TEE, StandaloneMM(as EFI Variable Service Pseudo TA), eMMC driver and tee-supplicant. The last piece is the tee-based variable access driver to interact with OP-TEE and StandaloneMM. Changelog: v8 -> v9 - patch #6 "tee: optee: restore efivars ops when tee-supplicant stops" is newly added - remove !EFI_VARS_PSTORE Kconfig dependency, we have added a non-blocking set_variable and it just returns EFI_UNSUPPORTED. - remove obvious comments v7 -> v8 Only patch #3 "efi: Add tee-based EFI variable driver" is updated. - fix typos - refactor error handling, direct return if applicable - use devm_add_action_or_reset() for closing of tee context/session - remove obvious comment v6 -> v7 Patch #1-#4 are not updated. Patch #5 is added into this series, original patch is here: https://lore.kernel.org/all/20230609094532.562934-1-ilias.apalodimas@linaro… There are two issues in the v6 series and v7 series addresses those. 1) efivar ops is not restored when the tee-supplicant daemon terminates. -> As the following patch says, user must remove the device before terminating tee-supplicant daemon. https://lore.kernel.org/all/20230728134832.326467-1-sumit.garg@linaro.org/ 2) cause panic when someone remounts the efivarfs as RW even if SetVariable is not supported -> The fifth patch addresses this issue. "[PATCH v7 5/5] efivarfs: force RO when remounting if SetVariable is not supported" v5 -> v6 - new patch #4 is added in this series, #1-#3 patches are unchanged. automatically update super block flag when the efivarops support SetVariable runtime service, so that user does not need to manually remount the efivarfs as RW. v4 -> v5 - rebase to efi-next based on v6.4-rc1 - set generic_ops.query_variable_info, it works as expected as follows. $ df -h /sys/firmware/efi/efivars/ Filesystem Size Used Avail Use% Mounted on efivarfs 16K 1.3K 15K 8% /sys/firmware/efi/efivars v3 -> v4: - replace the reference from EDK2 to PI Specification - remove EDK2 source code reference comments - prepare nonblocking variant of set_variable, it just returns EFI_UNSUPPORTED - remove redundant buffer size check - argument name change in mm_communicate - function interface changes in setup_mm_hdr to remove (void **) cast v2 -> v3: - add CONFIG_EFI dependency to TEE_STMM_EFI - add missing return code check for tee_client_invoke_func() - directly call efivars_register/unregister from tee_stmm_efi.c rfc v1 -> v2: - split patch into three patches, one for drivers/tee, one for include/linux/efi.h, and one for the driver/firmware/efi/stmm - context/session management into probe() and remove() same as other tee client driver - StMM variable driver is moved from driver/tee/optee to driver/firmware/efi - use "tee" prefix instead of "optee" in driver/firmware/efi/stmm/tee_stmm_efi.c, this file does not contain op-tee specific code, abstracted by tee layer and StMM variable driver will work on other tee implementation. - PTA_STMM_CMD_COMMUNICATE -> PTA_STMM_CMD_COMMUNICATE - implement query_variable_store() but currently not used - no use of TEEC_SUCCESS, it is defined in driver/tee/optee/optee_private.h. Other tee client drivers use 0 instead of using TEEC_SUCCESS - remove TEEC_ERROR_EXCESS_DATA status, it is referred just to output error message Ilias Apalodimas (1): efivarfs: force RO when remounting if SetVariable is not supported Masahisa Kojima (5): efi: expose efivar generic ops register function efi: Add EFI_ACCESS_DENIED status code efi: Add tee-based EFI variable driver efivarfs: automatically update super block flag tee: optee: restore efivars ops when tee-supplicant stops drivers/firmware/efi/Kconfig | 15 + drivers/firmware/efi/Makefile | 1 + drivers/firmware/efi/efi.c | 18 + drivers/firmware/efi/stmm/mm_communication.h | 236 +++++++ drivers/firmware/efi/stmm/tee_stmm_efi.c | 617 +++++++++++++++++++ drivers/firmware/efi/vars.c | 8 + drivers/tee/optee/supp.c | 4 + fs/efivarfs/super.c | 45 ++ include/linux/efi.h | 13 + 9 files changed, 957 insertions(+) create mode 100644 drivers/firmware/efi/stmm/mm_communication.h create mode 100644 drivers/firmware/efi/stmm/tee_stmm_efi.c base-commit: b691118f2c44d16b84fc65b8147b33620eb18cac -- 2.30.2

2 years, 5 months

4
17
0 0

[GIT PULL] OP-TEE kernel private shared memory optimizations for 6.8

by Jens Wiklander

Hello arm-soc maintainers, Please pull these two patches that optmize how the OP-TEE driver private shared memory allocated as dynamic shared memory. Thanks, Jens The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86: Linux 6.7-rc1 (2023-11-12 16:19:07 -0800) are available in the Git repository at: https://git.linaro.org/people/jens.wiklander/linux-tee.git tags/kern-priv-shm-for-v6.8 for you to fetch changes up to 225a36b96359aceaa9a6399f2dff99627397e637: optee: allocate shared memory with alloc_pages_exact() (2023-12-04 14:48:42 +0100) ---------------------------------------------------------------- OP-TEE kernel private shared memory optimizations Optimize OP-TEE driver private shared memory allocated as dynamic shared memory. Both to handle larger than one page allocations and for more efficient memory usage. ---------------------------------------------------------------- Jens Wiklander (2): optee: add page list to kernel private shared memory optee: allocate shared memory with alloc_pages_exact() drivers/tee/optee/core.c | 44 +++++++++++++++++++++++--------------------- drivers/tee/optee/smc_abi.c | 45 +++++++++++++++++++++------------------------ 2 files changed, 44 insertions(+), 45 deletions(-)

2 years, 5 months

1
0
0 0

[GIT PULL] OP-TEE FF-A asynchronous notifications for 6.8

by Jens Wiklander

Hello arm-soc maintainers, Please pull these patches that enables asynchronous notifications in OP-TEE FF-A driver. This pull request is on top of the "system_thread_for_v6.8" pull request to avoid a merge conflict. Thanks, Jens The following changes since commit 4b391c9c37646f25118355f414b9e6d9fefe782f: firmware: arm_scmi: optee: use optee system invocation (2023-11-17 15:48:03 +0100) are available in the Git repository at: https://git.linaro.org/people/jens.wiklander/linux-tee.git tags/ffa-notif-for-v6.8 for you to fetch changes up to d0476a59de064205f4aaa8f7c6d6f32bc28a44d4: optee: ffa_abi: add asynchronous notifications (2023-11-17 15:55:41 +0100) ---------------------------------------------------------------- OP-TEE: asynchronous notifications with FF-A Add support for asynchronous notifications in the OP-TEE FF-A driver. This is the FF-A counterpart to the asynchronous notifications already available in the OP-TEE SMC ABI. ---------------------------------------------------------------- Jens Wiklander (2): optee: provide optee_do_bottom_half() as a common function optee: ffa_abi: add asynchronous notifications drivers/tee/optee/call.c | 31 ++++++++++++- drivers/tee/optee/ffa_abi.c | 93 +++++++++++++++++++++++++++++++++++++-- drivers/tee/optee/optee_ffa.h | 28 ++++++++++-- drivers/tee/optee/optee_private.h | 9 +++- drivers/tee/optee/smc_abi.c | 36 ++------------- 5 files changed, 155 insertions(+), 42 deletions(-)

2 years, 5 months

1
0
0 0

[GIT PULL] OP-TEE reserved system thread for 6.8

by Jens Wiklander

Hello arm-soc maintainers, Please pull these patches that enables SCMI with OP-TEE transport to to reserve a thread in the secure world to guarentee that requests will not have to wait for a thread to become available. Thanks, Jens The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86: Linux 6.7-rc1 (2023-11-12 16:19:07 -0800) are available in the Git repository at: https://git.linaro.org/people/jens.wiklander/linux-tee.git tags/system-thread-for-v6.8 for you to fetch changes up to 4b391c9c37646f25118355f414b9e6d9fefe782f: firmware: arm_scmi: optee: use optee system invocation (2023-11-17 15:48:03 +0100) ---------------------------------------------------------------- OP-TEE add reserved system thread Add support for a reserved system thread in the SMC-ABI of the OP-TEE driver. SCMI with OP-TEE transport uses this to guarantee that it will always have a thread available in the secure world. ---------------------------------------------------------------- Etienne Carriere (4): tee: optee: system thread call property tee: system session tee: optee: support tracking system threads firmware: arm_scmi: optee: use optee system invocation drivers/firmware/arm_scmi/optee.c | 4 ++ drivers/tee/optee/call.c | 130 ++++++++++++++++++++++++++++++++++++-- drivers/tee/optee/core.c | 5 +- drivers/tee/optee/ffa_abi.c | 14 ++-- drivers/tee/optee/optee_private.h | 29 ++++++++- drivers/tee/optee/smc_abi.c | 32 +++++++--- drivers/tee/tee_core.c | 8 +++ include/linux/tee_drv.h | 16 +++++ 8 files changed, 211 insertions(+), 27 deletions(-)

2 years, 5 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

OP-TEE