OP-TEE July 2021

op-tee@lists.trustedfirmware.org

14 participants
17 discussions

[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

5 years, 1 month

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

5 years, 1 month

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

5 years, 1 month

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

5 years, 1 month

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

5 years, 1 month

[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

5 years, 1 month

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.

5 years, 1 month

2026

2025

2024

2023

2022

2021

2020

OP-TEE July 2021