- OP-TEE - lists.trustedfirmware.org

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

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

OP-TEE