- OP-TEE - lists.trustedfirmware.org

[PATCH v2 0/5] Add FF-A support in OP-TEE driver

by Jens Wiklander

Hi all, This adds supports for the OP-TEE driver to communicate with secure world using FF-A [1] as transport. These patches are based on the FF-A v7 patch set by Sudeep Holla [2] [3]. There is one change to the TEE subsystem with "tee: add sec_world_id to struct tee_shm" to add support for holding globally unique handle assigned by the FF-A. This is a field that I believe could useful for the AMDTEE driver too. For communication the OP-TEE message protocol is still used, but with a new type of memory reference, struct optee_msg_param_fmem, to carry the information needed by FF-A. The OP-TEE driver is refactored internally with to sets of callbacks, one for the old SMC based communication and another set with FF-A as transport. There is also a difference in how the drivers are instantiated. With the SMC based transport we have a platform driver, module_platform_driver(), today which we're keeping as is for this configuration. In a FF-A system we have a FF-A driver, module_ffa_driver(), instead. The OP-TEE driver can be compiled for both targets at the same time and it's up to runtime configuration (device tree or ACPI) to decide how it's initialized. Thanks, Jens [1] https://developer.arm.com/documentation/den0077/latest [2] https://lore.kernel.org/linux-arm-kernel/20210521151033.181846-1-sudeep.hol… [3] git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git v5.13/ffa v1->v2: - Rebased to the FF-A v7 patch - Fixed a couple of reports from kernel test robot <lkp(a)intel.com> Jens Wiklander (5): tee: add sec_world_id to struct tee_shm optee: simplify optee_release() optee: refactor driver with internal callbacks optee: add a FF-A memory pool optee: add FF-A support drivers/tee/optee/call.c | 325 +++++++++++--- drivers/tee/optee/core.c | 689 ++++++++++++++++++++++++++---- drivers/tee/optee/optee_ffa.h | 153 +++++++ drivers/tee/optee/optee_msg.h | 27 +- drivers/tee/optee/optee_private.h | 88 +++- drivers/tee/optee/rpc.c | 137 +++++- drivers/tee/optee/shm_pool.c | 65 ++- drivers/tee/optee/shm_pool.h | 1 + include/linux/tee_drv.h | 7 +- 9 files changed, 1326 insertions(+), 166 deletions(-) create mode 100644 drivers/tee/optee/optee_ffa.h -- 2.25.1

4 years, 6 months

2
7
0 0

OP-TEE SKS

by Rafael Gameiro

Greetings, I’m Rafael Gameiro, and I’m currently doing my Thesis in Msc Computer Science course of FCT NOVA University of Lisbon. As the subject suggests, I have come across a presentation Linaro did some years ago [1]. In my thesis, I have been trying to create an attestation ta, that generates an attestation proof of a set of components created by me. To ensure trustability over this attestation service, I thought I could use this SKS to possibly generate a keypair, and perform the sign operation that I need to generate the attestation proof. I searched for this SKS on OP-TEE OS [2], OP-TEE Client [3], and OP-TEE Tests[4], but I did not found any TA that explicitly said it was the SKS that was referred in the said presentation. The only possible comparisons I found were the TEE_AsymmetricSignDigest etc functions, derived from GP internal API, and the TA PKCS#11. My Question is, does this SKS still exists, and if yes, where could I find it. If not, does one of the above mentioned libraries is a SKS "replacement"? If yes, which one? Thank you for your time. Best regards, Rafael Gameiro [1] https://pt.slideshare.net/linaroorg/hkg18402-build-secure-key-management-se… [2] https://github.com/OP-TEE/optee_os [3] https://github.com/OP-TEE/optee_client [4] https://github.com/OP-TEE/optee_test

4 years, 6 months

1
0
0 0

[PATCH 0/3] tee: optee: Allow to freeze when tee-supplicant is frozen

by Christoph Gellner

When the system is going to hibernate or suspend it might happen that the tee-supplicant task is frozen first. In this case a running OP-TEE task might get stuck in the loop using wait_for_completion_interruptible to wait for response of tee-supplicant. As a consequence other OP-TEE tasks waiting for the above or a succeeding stuck OP-TEE task might get stuck as well - waiting for call queue entry to be completed - waiting for OPTEE_RPC_WAIT_QUEUE_WAKEUP This will result in the tasks "refusing to freeze" and the hibernate or suspend will fail. OP-TEE issue: https://github.com/OP-TEE/optee_os/issues/4581 - Read back the object PM: suspend entry (s2idle) Filesystems sync: 0.000 seconds Freezing user space processes ... Freezing of tasks failed after 20.008 seconds (3 tasks refusing to freeze, wq_busy=0): task:optee_example_s state:R running task stack: 0 pid: 124 ppid: 1 flags:0x00000001 [<807d3e24>] (__schedule) from [<841c4000>] (0x841c4000) task:optee_example_s state:D stack: 0 pid: 126 ppid: 1 flags:0x00000001 [<807d3e24>] (__schedule) from [<807d41d0>] (schedule+0x60/0x120) [<807d41d0>] (schedule) from [<807d7ffc>] (schedule_timeout+0x1f4/0x340) [<807d7ffc>] (schedule_timeout) from [<807d56a0>] (wait_for_completion+0x94/0xfc) [<807d56a0>] (wait_for_completion) from [<80692134>] (optee_cq_wait_for_completion+0x14/0x60) [<80692134>] (optee_cq_wait_for_completion) from [<806924dc>] (optee_do_call_with_arg+0x14c/0x154) [<806924dc>] (optee_do_call_with_arg) from [<80692edc>] (optee_shm_unregister+0x78/0xcc) [<80692edc>] (optee_shm_unregister) from [<80690a9c>] (tee_shm_release+0x88/0x174) [<80690a9c>] (tee_shm_release) from [<8057f89c>] (dma_buf_release+0x44/0xb0) [<8057f89c>] (dma_buf_release) from [<8028e4e8>] (__dentry_kill+0x110/0x17c) [<8028e4e8>] (__dentry_kill) from [<80276cfc>] (__fput+0xc0/0x234) [<80276cfc>] (__fput) from [<80140b1c>] (task_work_run+0x90/0xbc) [<80140b1c>] (task_work_run) from [<8010b1c8>] (do_work_pending+0x4a0/0x5a0) [<8010b1c8>] (do_work_pending) from [<801000cc>] (slow_work_pending+0xc/0x20) Exception stack(0x843f5fb0 to 0x843f5ff8) 5fa0: 00000000 7ef63448 fffffffe 00000000 5fc0: 7ef63448 76f163b0 7ef63448 00000006 7ef63448 7ef634e0 7ef63438 00000000 5fe0: 00000006 7ef63400 76e74833 76dff856 800e0130 00000004 task:optee_example_s state:D stack: 0 pid: 128 ppid: 1 flags:0x00000001 [<807d3e24>] (__schedule) from [<807d41d0>] (schedule+0x60/0x120) [<807d41d0>] (schedule) from [<807d7ffc>] (schedule_timeout+0x1f4/0x340) [<807d7ffc>] (schedule_timeout) from [<807d56a0>] (wait_for_completion+0x94/0xfc) [<807d56a0>] (wait_for_completion) from [<8069359c>] (optee_handle_rpc+0x554/0x710) [<8069359c>] (optee_handle_rpc) from [<806924cc>] (optee_do_call_with_arg+0x13c/0x154) [<806924cc>] (optee_do_call_with_arg) from [<80692910>] (optee_invoke_func+0x110/0x190) [<80692910>] (optee_invoke_func) from [<8068fe3c>] (tee_ioctl+0x113c/0x1244) [<8068fe3c>] (tee_ioctl) from [<802892ec>] (sys_ioctl+0xe0/0xa24) [<802892ec>] (sys_ioctl) from [<80100060>] (ret_fast_syscall+0x0/0x54) Exception stack(0x8424ffa8 to 0x8424fff0) ffa0: 00000000 7eb67584 00000003 8010a403 7eb67438 7eb675fc ffc0: 00000000 7eb67584 7eb67604 00000036 7eb67448 7eb674e0 7eb67438 00000000 ffe0: 76ef7030 7eb6742c 76ee6469 76e83178 OOM killer enabled. Restarting tasks ... done. PM: suspend exit sh: write error: Device or resource busy The patch set will switch to interruptible waits and add try_to_freeze to allow the waiting OP-TEE tasks to be frozen as well. --- In my humble understanding without these patches OP-TEE tasks have only been frozen in user-space. With these patches it is possible that OP-TEE tasks are frozen although the OP-TEE command invocation didn't complete. I'm unable to judge if there are any OP-TEE implementations relying on the fact that suspend won't happen while the OP-TEE command invocation didn't complete. The theoretical alternative would be to prevent that tee-supplicant is frozen first. I was able to reproduce the issue in OP-TEE QEMU v7 using a modified version of optee_example_secure_storage (loop around REE FS read, support multi-session). See https://github.com/OP-TEE/optee_os/issues/4581 for details. After applying these patches (minor adjustments of the includes) I was no longer able to reproduce the issues. In my tests OP-TEE QEMU v7 did suspend and resume without troubles. I'm not able to test on other devices supporting OP-TEE. I decided to handle each of the locations the OP-TEE task could get stuck as a separate commit. The downside is that the above call stack doesn't really fit to any of the commits. Christoph Gellner (3): tee: optee: Allow to freeze the task waiting for tee-supplicant tee: optee: Allow to freeze while waiting for call_queue tee: optee: Allow to freeze while waiting in OPTEE_RPC_WAIT_QUEUE_SLEEP drivers/tee/optee/call.c | 8 +++++++- drivers/tee/optee/rpc.c | 9 ++++++++- drivers/tee/optee/supp.c | 3 +++ 3 files changed, 18 insertions(+), 2 deletions(-) base-commit: c4681547bcce777daf576925a966ffa824edd09d -- 2.32.0.rc0

4 years, 7 months

1
3
0 0

OP-TEE 3.14.0 has been released

by Jerome Forissier

Hi, I'm pleased to let you know that the v3.14.0 release for OP-TEE is now available. As usual, the list of changes can be found in the changelog [1]. Thanks to everyone who participated with contributions and helping out with testing the release candidate [2]. [1] https://github.com/OP-TEE/optee_os/blob/master/CHANGELOG.md [2] https://github.com/OP-TEE/optee_os/commit/d21befa5e53e Regards, -- Jerome

4 years, 7 months

1
0
0 0

Re: [PATCH v5 8/8] firmware: tee_bnxt: Release TEE shm, session, and context during kexec

by Vikas Gupta

Hi Tyler/Allen, The patch looks good to me. Thanks, Vikas > > From: Allen Pais <apais(a)linux.microsoft.com> > > > > Implement a .shutdown hook that will be called during a kexec operation > > so that the TEE shared memory, session, and context that were set up > > during .probe can be properly freed/closed. > > > > Additionally, don't use dma-buf backed shared memory for the > > fw_shm_pool. dma-buf backed shared memory cannot be reliably freed and > > unregistered during a kexec operation even when tee_shm_free() is called > > on the shm from a .shutdown hook. The problem occurs because > > dma_buf_put() calls fput() which then uses task_work_add(), with the > > TWA_RESUME parameter, to queue tee_shm_release() to be called before the > > current task returns to user mode. However, the current task never > > returns to user mode before the kexec completes so the memory is never > > freed nor unregistered. > > > > Use tee_shm_alloc_kernel_buf() to avoid dma-buf backed shared memory > > allocation so that tee_shm_free() can directly call tee_shm_release(). > > This will ensure that the shm can be freed and unregistered during a > > kexec operation. > > > > Fixes: 246880958ac9 ("firmware: broadcom: add OP-TEE based BNXT f/w manager") > > Cc: stable(a)vger.kernel.org > > Signed-off-by: Allen Pais <apais(a)linux.microsoft.com> > > Co-developed-by: Tyler Hicks <tyhicks(a)linux.microsoft.com> > > Signed-off-by: Tyler Hicks <tyhicks(a)linux.microsoft.com> > > --- > > drivers/firmware/broadcom/tee_bnxt_fw.c | 14 +++++++++++--- > > 1 file changed, 11 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/firmware/broadcom/tee_bnxt_fw.c b/drivers/firmware/broadcom/tee_bnxt_fw.c > > index ed10da5313e8..a5bf4c3f6dc7 100644 > > --- a/drivers/firmware/broadcom/tee_bnxt_fw.c > > +++ b/drivers/firmware/broadcom/tee_bnxt_fw.c > > @@ -212,10 +212,9 @@ static int tee_bnxt_fw_probe(struct device *dev) > > > > pvt_data.dev = dev; > > > > - fw_shm_pool = tee_shm_alloc(pvt_data.ctx, MAX_SHM_MEM_SZ, > > - TEE_SHM_MAPPED | TEE_SHM_DMA_BUF); > > + fw_shm_pool = tee_shm_alloc_kernel_buf(pvt_data.ctx, MAX_SHM_MEM_SZ); > > if (IS_ERR(fw_shm_pool)) { > > - dev_err(pvt_data.dev, "tee_shm_alloc failed\n"); > > + dev_err(pvt_data.dev, "tee_shm_alloc_kernel_buf failed\n"); > > err = PTR_ERR(fw_shm_pool); > > goto out_sess; > > } > > @@ -242,6 +241,14 @@ static int tee_bnxt_fw_remove(struct device *dev) > > return 0; > > } > > > > +static void tee_bnxt_fw_shutdown(struct device *dev) > > +{ > > + tee_shm_free(pvt_data.fw_shm_pool); > > + tee_client_close_session(pvt_data.ctx, pvt_data.session_id); > > + tee_client_close_context(pvt_data.ctx); > > + pvt_data.ctx = NULL; > > +} > > + > > static const struct tee_client_device_id tee_bnxt_fw_id_table[] = { > > {UUID_INIT(0x6272636D, 0x2019, 0x0716, > > 0x42, 0x43, 0x4D, 0x5F, 0x53, 0x43, 0x48, 0x49)}, > > @@ -257,6 +264,7 @@ static struct tee_client_driver tee_bnxt_fw_driver = { > > .bus = &tee_bus_type, > > .probe = tee_bnxt_fw_probe, > > .remove = tee_bnxt_fw_remove, > > + .shutdown = tee_bnxt_fw_shutdown, > > }, > > }; > > > > -- > > 2.25.1 > > > > ----- End forwarded message -----

4 years, 7 months

1
0
0 0

Re: [PATCH v5 8/8] firmware: tee_bnxt: Release TEE shm, session, and context during kexec

by vikas gupta

The patch looks good to me Thanks, Vikas

4 years, 7 months

1
0
0 0

Preparing for OP-TEE 3.14.0

by Jerome Forissier

[CC all OP-TEE maintainers] Hi OP-TEE maintainers & contributors, OP-TEE v3.14.0 is scheduled to be released on 2021-07-16. 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/4704. 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 Regards, -- Jerome

4 years, 7 months

1
1
0 0

[PATCH v2 0/7] Asynchronous notifications from secure world

by Jens Wiklander

Hi all, This adds support for asynchronous notifications from OP-TEE in secure world to the OP-TEE driver. This allows a design with a top half and bottom half type of driver where the top half runs in secure interrupt context and a notifications tells normal world to schedule a yielding call to do the bottom half processing. An interrupt is used to notify the driver that there are asynchronous notifications pending. v2: * Added documentation * Converted optee bindings to json-schema and added interrupt property * Configure notification interrupt from DT instead of getting it from secure world, suggested by Ard Biesheuvel <ardb(a)kernel.org>. Thanks, Jens Jens Wiklander (7): docs: staging/tee.rst: add a section on OP-TEE notifications dt-bindings: arm: Convert optee binding to json-schema dt-bindings: arm: optee: add interrupt property tee: fix put order in teedev_close_context() tee: add tee_dev_open_helper() primitive optee: separate notification functions optee: add asynchronous notifications .../bindings/arm/firmware/linaro,optee-tz.txt | 31 --- .../arm/firmware/linaro,optee-tz.yaml | 57 +++++ Documentation/staging/tee.rst | 27 +++ drivers/tee/optee/Makefile | 1 + drivers/tee/optee/call.c | 27 +++ drivers/tee/optee/core.c | 87 +++++-- drivers/tee/optee/notif.c | 226 ++++++++++++++++++ drivers/tee/optee/optee_msg.h | 9 + drivers/tee/optee/optee_private.h | 23 +- drivers/tee/optee/optee_rpc_cmd.h | 31 +-- drivers/tee/optee/optee_smc.h | 75 +++++- drivers/tee/optee/rpc.c | 73 +----- drivers/tee/tee_core.c | 37 ++- include/linux/tee_drv.h | 27 +++ 14 files changed, 576 insertions(+), 155 deletions(-) delete mode 100644 Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt create mode 100644 Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml create mode 100644 drivers/tee/optee/notif.c -- 2.31.1

4 years, 7 months

6
23
0 0

Changing OPTEE's filesystem

by Luis Macedo

Hi, my name is Luís Macedo, and I'm a university student in Portugal. I'm currently doing my dissertation for my masters degree about exploring OPTEE capabilities in ROS2, using libddssec. I'm struggling to install ROS2 in a development environment alongside OPTEE because ROS2 is compatible only with Ubuntu and not with buildroot. I saw a GitHub issue to change the filesystem from buildroot, which is excellent for me. However, I noticed that I need to include some OPTEE files in the new filesystem. I managed to identify some libraries, TAs, and the tee-supplicant, but it doesn't print anything when I run the hello_world example. Can I get some help to transition from buildroot to Ubuntu, or maybe an environment already built for this purpose? Thanks for your attention, Luís Macedo.

4 years, 7 months

1
0
0 0

Linaro OP-TEE Contributions meeting June 2021

by Joakim Bech

Hi, The next LOC monthly meeting is planned to take place Thursday June 24th(a)17.00 (UTC+2). We will have Mingshen Sun from Baidu talking about their efforts with OP-TEE and Rust. At Linaro Connect in San Diego 2019 Mingshen gave a presentation about this [1], but since then things have been improved and Baidu has officially donated their work to ASF which is called "Apache Teaclave TrustZone SDK (incubating) 0.1.0" [2]. Etienne (ST) and I have recently had a discussion with Mingshen as well, where our goal was to better understand what it would take to bring Baidu's OP-TEE Rust enablement into the official OP-TEE upstream tree. Doing so would enable official Trusted Application development for OP-TEE using Rust. We'll have no other topics this month, the entire hour is dedicated to this discussion. If you have any questions, we'll take them at the end of the call. Alternatively, feel free to add your question into the meeting notes whenever you like (anyone can edit). Note that we don't send out invites for this meeting, so if you're interested in attending, then please follow the "Connection details" link below that will take you to the Google calendar, where you can add the invite yourself by clicking on the meeting itself and then scroll down and click on "copy to my calendar»". Another reminder that people might not have realized is that we record all monthly LOC meetings, so in case you've missed a call or want to go back, then you'll find the Zoom link and the password for it in the meeting notes (link below as well). [1] https://connect.linaro.org/resources/san19/san19-513/ [2] https://teaclave.apache.org/blog/2021-06-15-announcing-teaclave-trustzone-s… Meeting details: --------------- Date/time: Thursday June 24th(a)17.00 (UTC+2) https://everytimezone.com/s/08f4fb4e Connection details: https://www.trustedfirmware.org/meetings/ Meeting notes: http://bit.ly/loc-notes Project page: https://www.linaro.org/projects/#LOC Regards, Joakim on behalf of the Linaro OP-TEE team

4 years, 7 months

1
1
0 0

2026

2025

2024

2023

2022

2021

2020

OP-TEE