- OP-TEE - lists.trustedfirmware.org

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 months, 3 weeks

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>

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

3 months, 1 week

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

3 months, 1 week

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.

3 months, 1 week

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

3 months, 1 week

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?

3 months, 2 weeks

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

3 months, 2 weeks

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

3 months, 2 weeks

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

3 months, 2 weeks

1
2
0 0

2024

2023

2022

2021

2020

OP-TEE