- OP-TEE - lists.trustedfirmware.org

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, 11 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, 12 months

1
1
0 0

[GIT PULL] TEE reviewer for v5.13

by Jens Wiklander

Hello arm-soc maintainers, Please pull this patch which adds Sumit Garg as TEE subsystem reviewer. Thanks, Jens The following changes since commit d07f6ca923ea0927a1024dfccafc5b53b61cfecc: Linux 5.13-rc2 (2021-05-16 15:27:44 -0700) are available in the Git repository at: git://git.linaro.org:/people/jens.wiklander/linux-tee.git tags/tee-reviewer-for-v5.13 for you to fetch changes up to 9600948a2e919cabc18f196373e9f60c32bdb44e: MAINTAINERS: Add myself as TEE subsystem reviewer (2021-06-22 14:42:58 +0200) ---------------------------------------------------------------- Add Sumit Garg as TEE reviewer ---------------------------------------------------------------- Sumit Garg (1): MAINTAINERS: Add myself as TEE subsystem reviewer MAINTAINERS | 1 + 1 file changed, 1 insertion(+)

5 years

1
0
0 0

[PATCH] MAINTAINERS: Add myself as TEE subsystem reviewer

by Sumit Garg

Since I have been helping with TEE subsystem reviews, so make that role official. Signed-off-by: Sumit Garg <sumit.garg(a)linaro.org> --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index bd7aff0c120f..1e43bc497a15 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -17916,6 +17916,7 @@ F: include/media/i2c/tw9910.h TEE SUBSYSTEM M: Jens Wiklander <jens.wiklander(a)linaro.org> +R: Sumit Garg <sumit.garg(a)linaro.org> L: op-tee(a)lists.trustedfirmware.org S: Maintained F: Documentation/staging/tee.rst -- 2.25.1

5 years

2
1
0 0

[PATCH v4 0/8] tee: Improve support for kexec and kdump

by Tyler Hicks

v4: - Incorporated 'tee: add tee_shm_alloc_kernel_buf()' from Jens to remove the need to expose TEE_SHM_REGISTER to callers of tee_shm_alloc() - Updated 'tee: Support kernel shm registration without dma-buf backing' to drop the TEE_SHM_DMA_BUF flag when tee_shm_alloc_kernel_buf() calls tee_shm_alloc() - Updated the final two patches, against ftpm and tee_bnxt_fw, to use tee_shm_alloc_kernel_buf() instead of tee_shm_alloc() - Minor cleanups to the commit messages of the updates patches v3: https://lore.kernel.org/lkml/20210609002326.210024-1-tyhicks@linux.microsof… v2: https://lore.kernel.org/lkml/20210225090610.242623-1-allen.lkml@gmail.com/ v1: https://lore.kernel.org/lkml/20210217092714.121297-1-allen.lkml@gmail.com/ This series fixes several bugs uncovered while exercising the OP-TEE (Open Portable Trusted Execution Environment), ftpm (firmware TPM), and tee_bnxt_fw (Broadcom BNXT firmware manager) drivers with kexec and kdump (emergency kexec) based workflows. The majority of the problems are caused by missing .shutdown hooks in the drivers. The .shutdown hooks are used by the normal kexec code path to let the drivers clean up prior to executing the target kernel. The .remove hooks, which are already implemented in these drivers, are not called as part of the kexec code path. This resulted in shared memory regions, that were cached and/or registered with OP-TEE, not being cleared/unregistered prior to kexec. The new kernel would then run into problems when handling the previously cached virtual addresses or trying to register newly allocated shared memory objects that overlapped with the previously registered virtual addresses. The TEE didn't receive notification that the old virtual addresses were no longer meaningful and that a new kernel, with a new address space, would soon be running. However, implementing .shutdown hooks was not enough for supporting kexec. There was an additional problem caused by the TEE driver's reliance on the dma-buf subsystem for multi-page shared memory objects that were registered with the TEE. Shared memory objects backed by a dma-buf use a different mechanism for reference counting. When the final reference is released, work is scheduled to be executed to unregister the shared memory with the TEE but that work is only completed prior to the current task returning the userspace. In the case of a kexec operation, the current task that's calling the driver .shutdown hooks never returns to userspace prior to the kexec operation so the shared memory was never unregistered. This eventually caused problems from overlapping shared memory regions that were registered with the TEE after several kexec operations. The large 4M contiguous region allocated by the tee_bnxt_fw driver reliably ran into this issue on the fourth kexec on a system with 8G of RAM. The use of dma-buf makes sense for shared memory that's in use by userspace but dma-buf's aren't needed for shared memory that will only used by the driver. This series separates dma-buf backed shared memory allocated by the kernel from multi-page shared memory that the kernel simply needs registered with the TEE for private use. One other noteworthy change in this series is to completely refuse to load the OP-TEE driver in the kdump kernel. This is needed because the secure world may have had all of its threads in suspended state when the regular kernel crashed. The kdump kernel would then hang during boot because the OP-TEE driver's .probe function would attempt to use a secure world thread when they're all in suspended state. Another problem is that shared memory allocations could fail under the kdump kernel because the previously registered were not unregistered (the .shutdown hook is not called when kexec'ing into the kdump kernel). The first patch in the series fixes potential memory leaks that are not directly related to kexec or kdump but were noticed during the development of this series. Tyler Allen Pais (2): optee: fix tee out of memory failure seen during kexec reboot firmware: tee_bnxt: Release TEE shm, session, and context during kexec Jens Wiklander (1): tee: add tee_shm_alloc_kernel_buf() Tyler Hicks (5): optee: Fix memory leak when failing to register shm pages optee: Refuse to load the driver under the kdump kernel optee: Clear stale cache entries during initialization tee: Support kernel shm registration without dma-buf backing tpm_ftpm_tee: Free and unregister TEE shared memory during kexec drivers/char/tpm/tpm_ftpm_tee.c | 8 ++--- drivers/firmware/broadcom/tee_bnxt_fw.c | 14 +++++++-- drivers/tee/optee/call.c | 11 ++++++- drivers/tee/optee/core.c | 42 ++++++++++++++++++++++++- drivers/tee/optee/optee_private.h | 2 +- drivers/tee/optee/shm_pool.c | 17 +++++++--- drivers/tee/tee_shm.c | 29 ++++++++++++++++- include/linux/tee_drv.h | 1 + 8 files changed, 108 insertions(+), 16 deletions(-) -- 2.25.1

5 years

4
24
0 0

[PATCH 0/7] tee: shared memory updates

by Jens Wiklander

Hi all, Until now has the in-kernel tee clients, tpm_ftpm_tee, hwrng: optee-rng and firmware: tee_bnxt used shared memory objects which has been exported by dma-buf. Dma-buf isn't needed here since it's only an interaction between the kernel and secure world. This patchset fixes this by intruducing three new function tee_shm_alloc_user_buf(), tee_shm_alloc_kernel_buf() and tee_shm_alloc_anon_kernel_buf() to be used instead of the old tee_shm_alloc(). This should make the API a bit easier to use both within the TEE subsystem and for the tee clients in various drivers. The patch set starts with simplifying the shared memory pool handling, an internal matter for the two TEE drivers OP-TEE and AMDTEE. Thanks, Jens Jens Wiklander (7): tee: remove unused tee_shm_pool_alloc_res_mem() tee: simplify shm pool handling tee: add tee_shm_alloc_kernel_buf() hwrng: optee-rng: use tee_shm_alloc_kernel_buf() tpm_ftpm_tee: use tee_shm_alloc_kernel_buf() firmware: tee_bnxt: use tee_shm_alloc_kernel_buf() tee: replace tee_shm_alloc() drivers/char/hw_random/optee-rng.c | 6 +- drivers/char/tpm/tpm_ftpm_tee.c | 8 +- drivers/firmware/broadcom/tee_bnxt_fw.c | 5 +- drivers/tee/amdtee/shm_pool.c | 55 ++----- drivers/tee/optee/Kconfig | 8 - drivers/tee/optee/call.c | 16 +- drivers/tee/optee/core.c | 76 +-------- drivers/tee/optee/device.c | 5 +- drivers/tee/optee/rpc.c | 8 +- drivers/tee/optee/shm_pool.c | 51 +++--- drivers/tee/optee/shm_pool.h | 2 +- drivers/tee/tee_core.c | 2 +- drivers/tee/tee_private.h | 11 -- drivers/tee/tee_shm.c | 209 ++++++++++++++++++------ drivers/tee/tee_shm_pool.c | 160 ++++-------------- include/linux/tee_drv.h | 106 +++--------- 16 files changed, 291 insertions(+), 437 deletions(-) -- 2.31.1

5 years

2
18
0 0

[PATCH v3 0/7] tee: Improve support for kexec and kdump

by Tyler Hicks

v3: - Tyler inherited the original series from Allen Pais - New patch to fix memory leaks in OP-TEE's pool_op_alloc() + Unrelated to kexec/kdump - New patch to refuse to load the OP-TEE driver when booting the kdump kernel - Minor comment typo cleanups (s/alter/alert/) in the "optee: fix tee out of memory failure seen during kexec reboot" patch, as mentioned in v2 feedback - New patch to clear stale cache entries during initialization to avoid crashes when kexec'ing from a buggy kernel, that didn't disable the shm cache, to a fixed kernel - Three new patches to allow drivers to allocate a multi-page dynamic shm that's not dma-buf backed but is still fully registered with the TEE, ensuring that all driver private shms are unregistered during kexec v2: https://lore.kernel.org/lkml/20210225090610.242623-1-allen.lkml@gmail.com/ v1: https://lore.kernel.org/lkml/20210217092714.121297-1-allen.lkml@gmail.com/ This series fixes several bugs uncovered while exercising the OP-TEE (Open Portable Trusted Execution Environment), ftpm (firmware TPM), and tee_bnxt_fw (Broadcom BNXT firmware manager) drivers with kexec and kdump (emergency kexec) based workflows. The majority of the problems are caused by missing .shutdown hooks in the drivers. The .shutdown hooks are used by the normal kexec code path to let the drivers clean up prior to executing the target kernel. The .remove hooks, which are already implemented in these drivers, are not called as part of the kexec code path. This resulted in shared memory regions, that were cached and/or registered with OP-TEE, not being cleared/unregistered prior to kexec. The new kernel would then run into problems when handling the previously cached virtual addresses or trying to register newly allocated shared memory objects that overlapped with the previously registered virtual addresses. The TEE didn't receive notification that the old virtual addresses were no longer meaningful and that a new kernel, with a new address space, would soon be running. However, implementing .shutdown hooks was not enough for supporting kexec. There was an additional problem caused by the TEE driver's reliance on the dma-buf subsystem for multi-page shared memory objects that were registered with the TEE. Shared memory objects backed by a dma-buf use a different mechanism for reference counting. When the final reference is released, work is scheduled to be executed to unregister the shared memory with the TEE but that work is only completed prior to the current task returning the userspace. In the case of a kexec operation, the current task that's calling the driver .shutdown hooks never returns to userspace prior to the kexec operation so the shared memory was never unregistered. This eventually caused problems from overlapping shared memory regions that were registered with the TEE after several kexec operations. The large 4M contiguous region allocated by the tee_bnxt_fw driver reliably ran into this issue on the fourth kexec on a system with 8G of RAM. The use of dma-buf makes sense for shared memory that's in use by userspace but dma-buf's aren't needed for shared memory that will only used by the driver. This series separates dma-buf backed shared memory allocated by the kernel from multi-page shared memory that the kernel simply needs registered with the TEE for private use. One other noteworthy change in this series is to completely refuse to load the OP-TEE driver in the kdump kernel. This is needed because the secure world may have had all of its threads in suspended state when the regular kernel crashed. The kdump kernel would then hang during boot because the OP-TEE driver's .probe function would attempt to use a secure world thread when they're all in suspended state. Another problem is that shared memory allocations could fail under the kdump kernel because the previously registered were not unregistered (the .shutdown hook is not called when kexec'ing into the kdump kernel). The first patch in the series fixes potential memory leaks that are not directly related to kexec or kdump but were noticed during the development of this series. Tyler Allen Pais (2): optee: fix tee out of memory failure seen during kexec reboot firmware: tee_bnxt: Release shm, session, and context during kexec Tyler Hicks (5): optee: Fix memory leak when failing to register shm pages optee: Refuse to load the driver under the kdump kernel optee: Clear stale cache entries during initialization tee: Support shm registration without dma-buf backing tpm_ftpm_tee: Free and unregister dynamic shared memory during kexec drivers/char/tpm/tpm_ftpm_tee.c | 2 +- drivers/firmware/broadcom/tee_bnxt_fw.c | 11 ++++++- drivers/tee/optee/call.c | 11 ++++++- drivers/tee/optee/core.c | 42 ++++++++++++++++++++++++- drivers/tee/optee/optee_private.h | 2 +- drivers/tee/optee/shm_pool.c | 17 +++++++--- drivers/tee/tee_shm.c | 11 ++++++- 7 files changed, 85 insertions(+), 11 deletions(-) -- 2.25.1

5 years

4
20
0 0

[PATCH 0/4] 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 SPI interrupt is used to notify the driver that there are asynchronous notifications pending. Thanks, Jens Jens Wiklander (4): tee: fix put order in teedev_close_context() tee: add tee_dev_open_helper() primitive optee: separate notification functions optee: add asynchronous notifications drivers/tee/optee/Makefile | 1 + drivers/tee/optee/call.c | 27 ++++ drivers/tee/optee/core.c | 104 ++++++++++---- 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 | 79 ++++++++++- drivers/tee/optee/rpc.c | 73 ++-------- drivers/tee/tee_core.c | 37 +++-- include/linux/tee_drv.h | 27 ++++ 11 files changed, 512 insertions(+), 125 deletions(-) create mode 100644 drivers/tee/optee/notif.c -- 2.31.1

5 years

2
6
0 0

Zynq 7000 Support

by Manish Shakya

Hi Everyone, The documentation page says Zynq 7000 is not supported. I would like to know why the support was stopped. Was there any specific technical reason? Regards, Manish Shakya

5 years

1
0
0 0

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

2
4
0 0

Linaro OP-TEE Contributions meeting May 2021

by Joakim Bech

Hi, LOC monthly meeting is planned to take place Thursday May 27(a)17.00 (UTC+2). Looking for topics from people. If you have anything you'd like to discuss, please let me know. I have a couple of examples of things that could be worth having a chat about if there are no other proposals. - OP-TEE and MISRA C - Rust in OP-TEE - SDP (ION support removed in Linux kernel will affect OP-TEE's SDP solution) Meeting details: --------------- Date/time: Thursday May 27(a)17.00 (UTC+2) https://everytimezone.com/s/83944ce6 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

5 years, 1 month

1
0
0 0

[GIT PULL] OP-TEE fix for v5.13

by Jens Wiklander

Hello arm-soc maintainers, Please pull this small OP-TEE driver fix which uses export_uuid() to copy the client UUID instead of making asumptions about the internal format of uuid_t. Thanks, Jens The following changes since commit 6efb943b8616ec53a5e444193dccf1af9ad627b5: Linux 5.13-rc1 (2021-05-09 14:17:44 -0700) are available in the Git repository at: git://git.linaro.org/people/jens.wiklander/linux-tee.git tags/optee-fix-for-v5.13 for you to fetch changes up to 673c7aa2436bfc857b92417f3e590a297c586dde: optee: use export_uuid() to copy client UUID (2021-05-18 07:59:27 +0200) ---------------------------------------------------------------- OP-TEE use export_uuid() to copy UUID ---------------------------------------------------------------- Jens Wiklander (1): optee: use export_uuid() to copy client UUID drivers/tee/optee/call.c | 6 ++++-- drivers/tee/optee/optee_msg.h | 6 ++++-- 2 files changed, 8 insertions(+), 4 deletions(-)

5 years, 1 month

1
0
0 0

[PATCH 000/141] Fix fall-through warnings for Clang

by Gustavo A. R. Silva

Hi all, This series aims to fix almost all remaining fall-through warnings in order to enable -Wimplicit-fallthrough for Clang. In preparation to enable -Wimplicit-fallthrough for Clang, explicitly add multiple break/goto/return/fallthrough statements instead of just letting the code fall through to the next case. Notice that in order to enable -Wimplicit-fallthrough for Clang, this change[1] is meant to be reverted at some point. So, this patch helps to move in that direction. Something important to mention is that there is currently a discrepancy between GCC and Clang when dealing with switch fall-through to empty case statements or to cases that only contain a break/continue/return statement[2][3][4]. Now that the -Wimplicit-fallthrough option has been globally enabled[5], any compiler should really warn on missing either a fallthrough annotation or any of the other case-terminating statements (break/continue/return/ goto) when falling through to the next case statement. Making exceptions to this introduces variation in case handling which may continue to lead to bugs, misunderstandings, and a general lack of robustness. The point of enabling options like -Wimplicit-fallthrough is to prevent human error and aid developers in spotting bugs before their code is even built/ submitted/committed, therefore eliminating classes of bugs. So, in order to really accomplish this, we should, and can, move in the direction of addressing any error-prone scenarios and get rid of the unintentional fallthrough bug-class in the kernel, entirely, even if there is some minor redundancy. Better to have explicit case-ending statements than continue to have exceptions where one must guess as to the right result. The compiler will eliminate any actual redundancy. Note that there is already a patch in mainline that addresses almost 40,000 of these issues[6]. I'm happy to carry this whole series in my own tree if people are OK with it. :) [1] commit e2079e93f562c ("kbuild: Do not enable -Wimplicit-fallthrough for clang for now") [2] ClangBuiltLinux#636 [3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432 [4] https://godbolt.org/z/xgkvIh [5] commit a035d552a93b ("Makefile: Globally enable fall-through warning") [6] commit 4169e889e588 ("include: jhash/signal: Fix fall-through warnings for Clang") Thanks! Gustavo A. R. Silva (141): afs: Fix fall-through warnings for Clang ASoC: codecs: Fix fall-through warnings for Clang cifs: Fix fall-through warnings for Clang drm/amdgpu: Fix fall-through warnings for Clang drm/radeon: Fix fall-through warnings for Clang gfs2: Fix fall-through warnings for Clang gpio: Fix fall-through warnings for Clang IB/hfi1: Fix fall-through warnings for Clang igb: Fix fall-through warnings for Clang ima: Fix fall-through warnings for Clang ipv4: Fix fall-through warnings for Clang ixgbe: Fix fall-through warnings for Clang media: dvb-frontends: Fix fall-through warnings for Clang media: usb: dvb-usb-v2: Fix fall-through warnings for Clang netfilter: Fix fall-through warnings for Clang nfsd: Fix fall-through warnings for Clang nfs: Fix fall-through warnings for Clang qed: Fix fall-through warnings for Clang qlcnic: Fix fall-through warnings for Clang scsi: aic7xxx: Fix fall-through warnings for Clang scsi: aic94xx: Fix fall-through warnings for Clang scsi: bfa: Fix fall-through warnings for Clang staging: rtl8723bs: core: Fix fall-through warnings for Clang staging: vt6655: Fix fall-through warnings for Clang bnxt_en: Fix fall-through warnings for Clang ceph: Fix fall-through warnings for Clang drbd: Fix fall-through warnings for Clang drm/amd/display: Fix fall-through warnings for Clang e1000: Fix fall-through warnings for Clang ext2: Fix fall-through warnings for Clang ext4: Fix fall-through warnings for Clang floppy: Fix fall-through warnings for Clang fm10k: Fix fall-through warnings for Clang IB/mlx4: Fix fall-through warnings for Clang IB/qedr: Fix fall-through warnings for Clang ice: Fix fall-through warnings for Clang Input: pcspkr - Fix fall-through warnings for Clang isofs: Fix fall-through warnings for Clang ixgbevf: Fix fall-through warnings for Clang kprobes/x86: Fix fall-through warnings for Clang mm: Fix fall-through warnings for Clang net: 3c509: Fix fall-through warnings for Clang net: cassini: Fix fall-through warnings for Clang net/mlx4: Fix fall-through warnings for Clang net: mscc: ocelot: Fix fall-through warnings for Clang netxen_nic: Fix fall-through warnings for Clang nfp: Fix fall-through warnings for Clang perf/x86: Fix fall-through warnings for Clang pinctrl: Fix fall-through warnings for Clang RDMA/mlx5: Fix fall-through warnings for Clang reiserfs: Fix fall-through warnings for Clang security: keys: Fix fall-through warnings for Clang selinux: Fix fall-through warnings for Clang target: Fix fall-through warnings for Clang uprobes/x86: Fix fall-through warnings for Clang vxge: Fix fall-through warnings for Clang watchdog: Fix fall-through warnings for Clang xen-blkfront: Fix fall-through warnings for Clang regulator: as3722: Fix fall-through warnings for Clang habanalabs: Fix fall-through warnings for Clang tee: Fix fall-through warnings for Clang HID: usbhid: Fix fall-through warnings for Clang HID: input: Fix fall-through warnings for Clang ACPI: Fix fall-through warnings for Clang airo: Fix fall-through warnings for Clang ALSA: hdspm: Fix fall-through warnings for Clang ALSA: pcsp: Fix fall-through warnings for Clang ALSA: sb: Fix fall-through warnings for Clang ath5k: Fix fall-through warnings for Clang atm: fore200e: Fix fall-through warnings for Clang braille_console: Fix fall-through warnings for Clang can: peak_usb: Fix fall-through warnings for Clang carl9170: Fix fall-through warnings for Clang cfg80211: Fix fall-through warnings for Clang crypto: ccree - Fix fall-through warnings for Clang decnet: Fix fall-through warnings for Clang dm raid: Fix fall-through warnings for Clang drm/amd/pm: Fix fall-through warnings for Clang drm: Fix fall-through warnings for Clang drm/i915/gem: Fix fall-through warnings for Clang drm/nouveau/clk: Fix fall-through warnings for Clang drm/nouveau: Fix fall-through warnings for Clang drm/nouveau/therm: Fix fall-through warnings for Clang drm/via: Fix fall-through warnings for Clang firewire: core: Fix fall-through warnings for Clang hwmon: (corsair-cpro) Fix fall-through warnings for Clang hwmon: (max6621) Fix fall-through warnings for Clang i3c: master: cdns: Fix fall-through warnings for Clang ide: Fix fall-through warnings for Clang iio: adc: cpcap: Fix fall-through warnings for Clang iwlwifi: iwl-drv: Fix fall-through warnings for Clang libata: Fix fall-through warnings for Clang mac80211: Fix fall-through warnings for Clang media: atomisp: Fix fall-through warnings for Clang media: dvb_frontend: Fix fall-through warnings for Clang media: rcar_jpu: Fix fall-through warnings for Clang media: saa7134: Fix fall-through warnings for Clang mmc: sdhci-of-arasan: Fix fall-through warnings for Clang mt76: mt7615: Fix fall-through warnings for Clang mtd: cfi: Fix fall-through warnings for Clang mtd: mtdchar: Fix fall-through warnings for Clang mtd: onenand: Fix fall-through warnings for Clang mtd: rawnand: fsmc: Fix fall-through warnings for Clang mtd: rawnand: stm32_fmc2: Fix fall-through warnings for Clang net: ax25: Fix fall-through warnings for Clang net: bridge: Fix fall-through warnings for Clang net: core: Fix fall-through warnings for Clang netfilter: ipt_REJECT: Fix fall-through warnings for Clang net: netrom: Fix fall-through warnings for Clang net/packet: Fix fall-through warnings for Clang net: plip: Fix fall-through warnings for Clang net: rose: Fix fall-through warnings for Clang nl80211: Fix fall-through warnings for Clang phy: qcom-usb-hs: Fix fall-through warnings for Clang rds: Fix fall-through warnings for Clang rt2x00: Fix fall-through warnings for Clang rtl8xxxu: Fix fall-through warnings for Clang rtw88: Fix fall-through warnings for Clang rxrpc: Fix fall-through warnings for Clang scsi: aacraid: Fix fall-through warnings for Clang scsi: aha1740: Fix fall-through warnings for Clang scsi: csiostor: Fix fall-through warnings for Clang scsi: lpfc: Fix fall-through warnings for Clang scsi: stex: Fix fall-through warnings for Clang sctp: Fix fall-through warnings for Clang slimbus: messaging: Fix fall-through warnings for Clang staging: qlge: Fix fall-through warnings for Clang staging: vt6656: Fix fall-through warnings for Clang SUNRPC: Fix fall-through warnings for Clang tipc: Fix fall-through warnings for Clang tpm: Fix fall-through warnings for Clang ubi: Fix fall-through warnings for Clang usb: Fix fall-through warnings for Clang video: fbdev: lxfb_ops: Fix fall-through warnings for Clang video: fbdev: pm2fb: Fix fall-through warnings for Clang virtio_net: Fix fall-through warnings for Clang wcn36xx: Fix fall-through warnings for Clang xen/manage: Fix fall-through warnings for Clang xfrm: Fix fall-through warnings for Clang zd1201: Fix fall-through warnings for Clang Input: libps2 - Fix fall-through warnings for Clang arch/x86/events/core.c | 2 +- arch/x86/kernel/kprobes/core.c | 1 + arch/x86/kernel/uprobes.c | 2 ++ drivers/accessibility/braille/braille_console.c | 1 + drivers/acpi/sbshc.c | 1 + drivers/ata/libata-eh.c | 1 + drivers/atm/fore200e.c | 1 + drivers/block/drbd/drbd_receiver.c | 1 + drivers/block/drbd/drbd_req.c | 1 + drivers/block/floppy.c | 1 + drivers/block/xen-blkfront.c | 1 + drivers/char/tpm/eventlog/tpm1.c | 1 + drivers/crypto/ccree/cc_cipher.c | 3 +++ drivers/firewire/core-topology.c | 1 + drivers/gpio/gpio-ath79.c | 1 + drivers/gpio/gpiolib-acpi.c | 1 + drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 1 + drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 1 + drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 1 + drivers/gpu/drm/amd/amdgpu/vi.c | 1 + drivers/gpu/drm/amd/display/dc/bios/bios_parser.c | 1 + drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c | 2 ++ drivers/gpu/drm/amd/display/dc/core/dc_link.c | 1 + drivers/gpu/drm/amd/pm/powerplay/si_dpm.c | 2 +- .../gpu/drm/amd/pm/powerplay/smumgr/polaris10_smumgr.c | 1 + drivers/gpu/drm/drm_bufs.c | 1 + drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 1 + drivers/gpu/drm/nouveau/nouveau_bo.c | 1 + drivers/gpu/drm/nouveau/nouveau_connector.c | 1 + drivers/gpu/drm/nouveau/nvkm/subdev/clk/nv50.c | 1 + drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf119.c | 1 + drivers/gpu/drm/radeon/ci_dpm.c | 2 +- drivers/gpu/drm/radeon/r300.c | 1 + drivers/gpu/drm/radeon/si_dpm.c | 2 +- drivers/gpu/drm/via/via_irq.c | 1 + drivers/hid/hid-input.c | 1 + drivers/hid/usbhid/hid-core.c | 2 ++ drivers/hwmon/corsair-cpro.c | 1 + drivers/hwmon/max6621.c | 2 +- drivers/i3c/master/i3c-master-cdns.c | 2 ++ drivers/ide/siimage.c | 1 + drivers/iio/adc/cpcap-adc.c | 1 + drivers/infiniband/hw/hfi1/qp.c | 1 + drivers/infiniband/hw/hfi1/tid_rdma.c | 5 +++++ drivers/infiniband/hw/mlx4/mad.c | 1 + drivers/infiniband/hw/mlx5/qp.c | 1 + drivers/infiniband/hw/qedr/main.c | 1 + drivers/input/misc/pcspkr.c | 1 + drivers/input/serio/libps2.c | 2 +- drivers/md/dm-raid.c | 1 + drivers/media/dvb-core/dvb_frontend.c | 1 + drivers/media/dvb-frontends/cx24120.c | 1 + drivers/media/dvb-frontends/dib0090.c | 2 ++ drivers/media/dvb-frontends/drxk_hard.c | 1 + drivers/media/dvb-frontends/m88rs2000.c | 1 + drivers/media/pci/saa7134/saa7134-tvaudio.c | 1 + drivers/media/platform/rcar_jpu.c | 1 + drivers/media/usb/dvb-usb-v2/af9015.c | 1 + drivers/media/usb/dvb-usb-v2/lmedm04.c | 1 + drivers/misc/habanalabs/gaudi/gaudi.c | 1 + drivers/mmc/host/sdhci-of-arasan.c | 4 ++++ drivers/mtd/chips/cfi_cmdset_0001.c | 1 + drivers/mtd/chips/cfi_cmdset_0002.c | 2 ++ drivers/mtd/chips/cfi_cmdset_0020.c | 2 ++ drivers/mtd/mtdchar.c | 1 + drivers/mtd/nand/onenand/onenand_samsung.c | 1 + drivers/mtd/nand/raw/fsmc_nand.c | 1 + drivers/mtd/nand/raw/stm32_fmc2_nand.c | 2 ++ drivers/mtd/ubi/build.c | 1 + drivers/net/can/usb/peak_usb/pcan_usb_core.c | 2 ++ drivers/net/ethernet/3com/3c509.c | 1 + drivers/net/ethernet/broadcom/bnxt/bnxt.c | 1 + drivers/net/ethernet/intel/e1000/e1000_hw.c | 1 + drivers/net/ethernet/intel/fm10k/fm10k_mbx.c | 2 ++ drivers/net/ethernet/intel/ice/ice_txrx_lib.c | 1 + drivers/net/ethernet/intel/igb/e1000_phy.c | 1 + drivers/net/ethernet/intel/igb/igb_ethtool.c | 1 + drivers/net/ethernet/intel/igb/igb_ptp.c | 1 + drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c | 2 ++ drivers/net/ethernet/intel/ixgbe/ixgbe_common.c | 1 + drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c | 1 + drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c | 1 + drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 1 + drivers/net/ethernet/mellanox/mlx4/resource_tracker.c | 1 + drivers/net/ethernet/mscc/ocelot_vcap.c | 1 + drivers/net/ethernet/neterion/vxge/vxge-config.c | 1 + drivers/net/ethernet/netronome/nfp/nfp_net_repr.c | 1 + drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c | 1 + drivers/net/ethernet/qlogic/qed/qed_l2.c | 1 + drivers/net/ethernet/qlogic/qed/qed_sriov.c | 1 + drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c | 1 + drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c | 1 + drivers/net/ethernet/sun/cassini.c | 1 + drivers/net/plip/plip.c | 2 ++ drivers/net/virtio_net.c | 1 + drivers/net/wireless/ath/ath5k/mac80211-ops.c | 1 + drivers/net/wireless/ath/carl9170/tx.c | 1 + drivers/net/wireless/ath/wcn36xx/smd.c | 2 +- drivers/net/wireless/cisco/airo.c | 1 + drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 2 +- drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c | 2 +- drivers/net/wireless/ralink/rt2x00/rt2x00queue.c | 1 + drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 8 ++++---- drivers/net/wireless/realtek/rtw88/fw.c | 2 +- drivers/net/wireless/zydas/zd1201.c | 2 +- drivers/phy/qualcomm/phy-qcom-usb-hs.c | 1 + drivers/pinctrl/renesas/pinctrl-rza1.c | 1 + drivers/regulator/as3722-regulator.c | 3 ++- drivers/scsi/aacraid/commsup.c | 1 + drivers/scsi/aha1740.c | 1 + drivers/scsi/aic7xxx/aic79xx_core.c | 4 +++- drivers/scsi/aic7xxx/aic7xxx_core.c | 4 ++-- drivers/scsi/aic94xx/aic94xx_scb.c | 2 ++ drivers/scsi/aic94xx/aic94xx_task.c | 2 ++ drivers/scsi/bfa/bfa_fcs_lport.c | 2 +- drivers/scsi/bfa/bfa_ioc.c | 6 ++++-- drivers/scsi/csiostor/csio_wr.c | 1 + drivers/scsi/lpfc/lpfc_bsg.c | 1 + drivers/scsi/stex.c | 1 + drivers/slimbus/messaging.c | 1 + drivers/staging/media/atomisp/pci/runtime/isys/src/rx.c | 1 + drivers/staging/qlge/qlge_main.c | 1 + drivers/staging/rtl8723bs/core/rtw_cmd.c | 1 + drivers/staging/rtl8723bs/core/rtw_mlme_ext.c | 1 + drivers/staging/rtl8723bs/core/rtw_wlan_util.c | 1 + drivers/staging/vt6655/device_main.c | 1 + drivers/staging/vt6655/rxtx.c | 2 ++ drivers/staging/vt6656/main_usb.c | 1 + drivers/target/target_core_iblock.c | 1 + drivers/target/target_core_pr.c | 1 + drivers/tee/tee_core.c | 1 + drivers/usb/gadget/function/f_fs.c | 2 ++ drivers/usb/gadget/function/f_loopback.c | 2 +- drivers/usb/gadget/function/f_sourcesink.c | 1 + drivers/usb/gadget/udc/dummy_hcd.c | 2 ++ drivers/usb/host/fotg210-hcd.c | 2 +- drivers/usb/host/isp116x-hcd.c | 1 + drivers/usb/host/max3421-hcd.c | 1 + drivers/usb/host/oxu210hp-hcd.c | 1 + drivers/usb/misc/yurex.c | 1 + drivers/usb/musb/tusb6010.c | 1 + drivers/usb/storage/ene_ub6250.c | 1 + drivers/usb/storage/uas.c | 1 + drivers/video/fbdev/geode/lxfb_ops.c | 1 + drivers/video/fbdev/pm2fb.c | 1 + drivers/watchdog/machzwd.c | 1 + drivers/xen/manage.c | 1 + fs/afs/cmservice.c | 5 +++++ fs/afs/fsclient.c | 4 ++++ fs/afs/vlclient.c | 1 + fs/ceph/dir.c | 2 ++ fs/cifs/inode.c | 1 + fs/cifs/sess.c | 1 + fs/cifs/smbdirect.c | 1 + fs/ext2/inode.c | 1 + fs/ext4/super.c | 1 + fs/gfs2/inode.c | 2 ++ fs/gfs2/recovery.c | 1 + fs/isofs/rock.c | 1 + fs/nfs/nfs3acl.c | 1 + fs/nfs/nfs4client.c | 1 + fs/nfs/nfs4proc.c | 2 ++ fs/nfs/nfs4state.c | 1 + fs/nfs/pnfs.c | 2 ++ fs/nfsd/nfs4state.c | 1 + fs/nfsd/nfsctl.c | 1 + fs/reiserfs/namei.c | 1 + mm/mm_init.c | 1 + mm/vmscan.c | 1 + net/ax25/af_ax25.c | 1 + net/bridge/br_input.c | 1 + net/core/dev.c | 1 + net/decnet/dn_route.c | 2 +- net/ipv4/ah4.c | 1 + net/ipv4/esp4.c | 1 + net/ipv4/fib_semantics.c | 1 + net/ipv4/ip_vti.c | 1 + net/ipv4/ipcomp.c | 1 + net/ipv4/netfilter/ipt_REJECT.c | 1 + net/mac80211/cfg.c | 2 ++ net/netfilter/nf_conntrack_proto_dccp.c | 1 + net/netfilter/nf_tables_api.c | 1 + net/netfilter/nft_ct.c | 1 + net/netrom/nr_route.c | 4 ++++ net/packet/af_packet.c | 1 + net/rds/tcp_connect.c | 1 + net/rds/threads.c | 2 ++ net/rose/rose_route.c | 2 ++ net/rxrpc/af_rxrpc.c | 1 + net/sctp/input.c | 3 ++- net/sunrpc/rpc_pipe.c | 1 + net/sunrpc/xprtsock.c | 1 + net/tipc/link.c | 1 + net/wireless/nl80211.c | 1 + net/wireless/util.c | 1 + net/xfrm/xfrm_interface.c | 1 + security/integrity/ima/ima_main.c | 1 + security/integrity/ima/ima_policy.c | 2 ++ security/keys/process_keys.c | 1 + security/selinux/hooks.c | 1 + sound/drivers/pcsp/pcsp_input.c | 1 + sound/isa/sb/sb8_main.c | 1 + sound/pci/rme9652/hdspm.c | 1 + sound/soc/codecs/adav80x.c | 1 + sound/soc/codecs/arizona.c | 1 + sound/soc/codecs/cs42l52.c | 1 + sound/soc/codecs/cs42l56.c | 1 + sound/soc/codecs/cs47l92.c | 1 + sound/soc/codecs/wm8962.c | 1 + 209 files changed, 264 insertions(+), 26 deletions(-) -- 2.27.0

5 years, 1 month

21
73
0 0

[PATCH v2 0/2] optee: fix OOM seen due to tee_shm_free()

by Allen Pais

From: Allen Pais <apais(a)linux.microsoft.com> The following out of memory errors are seen on kexec reboot from the optee core. [ 0.368428] tee_bnxt_fw optee-clnt0: tee_shm_alloc failed [ 0.368461] tee_bnxt_fw: probe of optee-clnt0 failed with error -22 tee_shm_release() is not invoked on dma shm buffer. Implement .shutdown() in optee core as well as bnxt firmware driver to handle the release of the buffers correctly. More info: https://github.com/OP-TEE/optee_os/issues/3637 v2: keep the .shutdown() method simple. [Jens Wiklander] Allen Pais (2): optee: fix tee out of memory failure seen during kexec reboot firmware: tee_bnxt: implement shutdown method to handle kexec reboots drivers/firmware/broadcom/tee_bnxt_fw.c | 9 +++++++++ drivers/tee/optee/core.c | 20 ++++++++++++++++++++ 2 files changed, 29 insertions(+) -- 2.25.1

5 years, 1 month

4
27
0 0

[PATCH v3] tee: amdtee: unload TA only when its refcount becomes 0

by Rijo Thomas

Same Trusted Application (TA) can be loaded in multiple TEE contexts. If it is a single instance TA, the TA should not get unloaded from AMD Secure Processor, while it is still in use in another TEE context. Therefore reference count TA and unload it when the count becomes zero. Fixes: 757cc3e9ff1d ("tee: add AMD-TEE driver") Reviewed-by: Devaraj Rangasamy <Devaraj.Rangasamy(a)amd.com> Signed-off-by: Rijo Thomas <Rijo-john.Thomas(a)amd.com> --- v3: * Updated structure initialization list from {0} to preferred style {} v2: * Unload TA if get_ta_refcount() fails drivers/tee/amdtee/amdtee_private.h | 13 ++++ drivers/tee/amdtee/call.c | 94 ++++++++++++++++++++++++++--- drivers/tee/amdtee/core.c | 15 +++-- 3 files changed, 106 insertions(+), 16 deletions(-) diff --git a/drivers/tee/amdtee/amdtee_private.h b/drivers/tee/amdtee/amdtee_private.h index 337c8d82f74e..6d0f7062bb87 100644 --- a/drivers/tee/amdtee/amdtee_private.h +++ b/drivers/tee/amdtee/amdtee_private.h @@ -21,6 +21,7 @@ #define TEEC_SUCCESS 0x00000000 #define TEEC_ERROR_GENERIC 0xFFFF0000 #define TEEC_ERROR_BAD_PARAMETERS 0xFFFF0006 +#define TEEC_ERROR_OUT_OF_MEMORY 0xFFFF000C #define TEEC_ERROR_COMMUNICATION 0xFFFF000E #define TEEC_ORIGIN_COMMS 0x00000002 @@ -93,6 +94,18 @@ struct amdtee_shm_data { u32 buf_id; }; +/** + * struct amdtee_ta_data - Keeps track of all TAs loaded in AMD Secure + * Processor + * @ta_handle: Handle to TA loaded in TEE + * @refcount: Reference count for the loaded TA + */ +struct amdtee_ta_data { + struct list_head list_node; + u32 ta_handle; + u32 refcount; +}; + #define LOWER_TWO_BYTE_MASK 0x0000FFFF /** diff --git a/drivers/tee/amdtee/call.c b/drivers/tee/amdtee/call.c index 096dd4d92d39..07f36ac834c8 100644 --- a/drivers/tee/amdtee/call.c +++ b/drivers/tee/amdtee/call.c @@ -121,15 +121,69 @@ static int amd_params_to_tee_params(struct tee_param *tee, u32 count, return ret; } +static DEFINE_MUTEX(ta_refcount_mutex); +static struct list_head ta_list = LIST_HEAD_INIT(ta_list); + +static u32 get_ta_refcount(u32 ta_handle) +{ + struct amdtee_ta_data *ta_data; + u32 count = 0; + + /* Caller must hold a mutex */ + list_for_each_entry(ta_data, &ta_list, list_node) + if (ta_data->ta_handle == ta_handle) + return ++ta_data->refcount; + + ta_data = kzalloc(sizeof(*ta_data), GFP_KERNEL); + if (ta_data) { + ta_data->ta_handle = ta_handle; + ta_data->refcount = 1; + count = ta_data->refcount; + list_add(&ta_data->list_node, &ta_list); + } + + return count; +} + +static u32 put_ta_refcount(u32 ta_handle) +{ + struct amdtee_ta_data *ta_data; + u32 count = 0; + + /* Caller must hold a mutex */ + list_for_each_entry(ta_data, &ta_list, list_node) + if (ta_data->ta_handle == ta_handle) { + count = --ta_data->refcount; + if (count == 0) { + list_del(&ta_data->list_node); + kfree(ta_data); + break; + } + } + + return count; +} + int handle_unload_ta(u32 ta_handle) { struct tee_cmd_unload_ta cmd = {0}; - u32 status; + u32 status, count; int ret; if (!ta_handle) return -EINVAL; + mutex_lock(&ta_refcount_mutex); + + count = put_ta_refcount(ta_handle); + + if (count) { + pr_debug("unload ta: not unloading %u count %u\n", + ta_handle, count); + ret = -EBUSY; + goto unlock; + } + cmd.ta_handle = ta_handle; ret = psp_tee_process_cmd(TEE_CMD_ID_UNLOAD_TA, (void *)&cmd, @@ -137,8 +191,12 @@ int handle_unload_ta(u32 ta_handle) if (!ret && status != 0) { pr_err("unload ta: status = 0x%x\n", status); ret = -EBUSY; + } else { + pr_debug("unloaded ta handle %u\n", ta_handle); } +unlock: + mutex_unlock(&ta_refcount_mutex); return ret; } @@ -340,7 +398,8 @@ int handle_open_session(struct tee_ioctl_open_session_arg *arg, u32 *info, int handle_load_ta(void *data, u32 size, struct tee_ioctl_open_session_arg *arg) { - struct tee_cmd_load_ta cmd = {0}; + struct tee_cmd_unload_ta unload_cmd = {}; + struct tee_cmd_load_ta load_cmd = {}; phys_addr_t blob; int ret; @@ -353,21 +412,36 @@ int handle_load_ta(void *data, u32 size, struct tee_ioctl_open_session_arg *arg) return -EINVAL; } - cmd.hi_addr = upper_32_bits(blob); - cmd.low_addr = lower_32_bits(blob); - cmd.size = size; + load_cmd.hi_addr = upper_32_bits(blob); + load_cmd.low_addr = lower_32_bits(blob); + load_cmd.size = size; - ret = psp_tee_process_cmd(TEE_CMD_ID_LOAD_TA, (void *)&cmd, - sizeof(cmd), &arg->ret); + mutex_lock(&ta_refcount_mutex); + + ret = psp_tee_process_cmd(TEE_CMD_ID_LOAD_TA, (void *)&load_cmd, + sizeof(load_cmd), &arg->ret); if (ret) { arg->ret_origin = TEEC_ORIGIN_COMMS; arg->ret = TEEC_ERROR_COMMUNICATION; - } else { - set_session_id(cmd.ta_handle, 0, &arg->session); + } else if (arg->ret == TEEC_SUCCESS) { + ret = get_ta_refcount(load_cmd.ta_handle); + if (!ret) { + arg->ret_origin = TEEC_ORIGIN_COMMS; + arg->ret = TEEC_ERROR_OUT_OF_MEMORY; + + /* Unload the TA on error */ + unload_cmd.ta_handle = load_cmd.ta_handle; + psp_tee_process_cmd(TEE_CMD_ID_UNLOAD_TA, + (void *)&unload_cmd, + sizeof(unload_cmd), &ret); + } else { + set_session_id(load_cmd.ta_handle, 0, &arg->session); + } } + mutex_unlock(&ta_refcount_mutex); pr_debug("load TA: TA handle = 0x%x, RO = 0x%x, ret = 0x%x\n", - cmd.ta_handle, arg->ret_origin, arg->ret); + load_cmd.ta_handle, arg->ret_origin, arg->ret); return 0; } diff --git a/drivers/tee/amdtee/core.c b/drivers/tee/amdtee/core.c index 8a6a8f30bb42..da6b88e80dc0 100644 --- a/drivers/tee/amdtee/core.c +++ b/drivers/tee/amdtee/core.c @@ -59,10 +59,9 @@ static void release_session(struct amdtee_session *sess) continue; handle_close_session(sess->ta_handle, sess->session_info[i]); + handle_unload_ta(sess->ta_handle); } - /* Unload Trusted Application once all sessions are closed */ - handle_unload_ta(sess->ta_handle); kfree(sess); } @@ -224,8 +223,6 @@ static void destroy_session(struct kref *ref) struct amdtee_session *sess = container_of(ref, struct amdtee_session, refcount); - /* Unload the TA from TEE */ - handle_unload_ta(sess->ta_handle); mutex_lock(&session_list_mutex); list_del(&sess->list_node); mutex_unlock(&session_list_mutex); @@ -238,7 +235,7 @@ int amdtee_open_session(struct tee_context *ctx, { struct amdtee_context_data *ctxdata = ctx->data; struct amdtee_session *sess = NULL; - u32 session_info; + u32 session_info, ta_handle; size_t ta_size; int rc, i; void *ta; @@ -259,11 +256,14 @@ int amdtee_open_session(struct tee_context *ctx, if (arg->ret != TEEC_SUCCESS) goto out; + ta_handle = get_ta_handle(arg->session); + mutex_lock(&session_list_mutex); sess = alloc_session(ctxdata, arg->session); mutex_unlock(&session_list_mutex); if (!sess) { + handle_unload_ta(ta_handle); rc = -ENOMEM; goto out; } @@ -277,6 +277,7 @@ int amdtee_open_session(struct tee_context *ctx, if (i >= TEE_NUM_SESSIONS) { pr_err("reached maximum session count %d\n", TEE_NUM_SESSIONS); + handle_unload_ta(ta_handle); kref_put(&sess->refcount, destroy_session); rc = -ENOMEM; goto out; @@ -289,12 +290,13 @@ int amdtee_open_session(struct tee_context *ctx, spin_lock(&sess->lock); clear_bit(i, sess->sess_mask); spin_unlock(&sess->lock); + handle_unload_ta(ta_handle); kref_put(&sess->refcount, destroy_session); goto out; } sess->session_info[i] = session_info; - set_session_id(sess->ta_handle, i, &arg->session); + set_session_id(ta_handle, i, &arg->session); out: free_pages((u64)ta, get_order(ta_size)); return rc; @@ -329,6 +331,7 @@ int amdtee_close_session(struct tee_context *ctx, u32 session) /* Close the session */ handle_close_session(ta_handle, session_info); + handle_unload_ta(ta_handle); kref_put(&sess->refcount, destroy_session); -- 2.17.1

5 years, 1 month

3
4
0 0

[GIT PULL] AMD-TEE fix for v5.13

by Jens Wiklander

Hello arm-soc maintainers, Please pull this AMDTEE driver fix which adds reference counting to loaded TAs which is needed for proper life cycle management of TAs. Note that this isn't a usual Arm driver update. This targets AMD instead, but is part of the TEE subsystem. Thanks, Jens The following changes since commit 9f4ad9e425a1d3b6a34617b8ea226d56a119a717: Linux 5.12 (2021-04-25 13:49:08 -0700) are available in the Git repository at: git://git.linaro.org/people/jens.wiklander/linux-tee.git tags/amdtee-fixes-for-v5.13 for you to fetch changes up to 9f015b3765bf593b3ed5d3b588e409dc0ffa9f85: tee: amdtee: unload TA only when its refcount becomes 0 (2021-05-05 13:00:11 +0200) ---------------------------------------------------------------- AMD-TEE reference count loaded TAs ---------------------------------------------------------------- Rijo Thomas (1): tee: amdtee: unload TA only when its refcount becomes 0 drivers/tee/amdtee/amdtee_private.h | 13 +++++ drivers/tee/amdtee/call.c | 94 +++++++++++++++++++++++++++++++++---- drivers/tee/amdtee/core.c | 15 +++--- 3 files changed, 106 insertions(+), 16 deletions(-)

5 years, 1 month

1
0
0 0

[PATCH AUTOSEL 4.14 09/16] tee: optee: do not check memref size on return from Secure World

by Sasha Levin

From: Jerome Forissier <jerome(a)forissier.org> [ Upstream commit c650b8dc7a7910eb25af0aac1720f778b29e679d ] When Secure World returns, it may have changed the size attribute of the memory references passed as [in/out] parameters. The GlobalPlatform TEE Internal Core API specification does not restrict the values that this size can take. In particular, Secure World may increase the value to be larger than the size of the input buffer to indicate that it needs more. Therefore, the size check in optee_from_msg_param() is incorrect and needs to be removed. This fixes a number of failed test cases in the GlobalPlatform TEE Initial Configuratiom Test Suite v2_0_0_0-2017_06_09 when OP-TEE is compiled without dynamic shared memory support (CFG_CORE_DYN_SHM=n). Reviewed-by: Sumit Garg <sumit.garg(a)linaro.org> Suggested-by: Jens Wiklander <jens.wiklander(a)linaro.org> Signed-off-by: Jerome Forissier <jerome(a)forissier.org> Signed-off-by: Jens Wiklander <jens.wiklander(a)linaro.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/tee/optee/core.c | 10 ---------- 1 file changed, 10 deletions(-) diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c index 834884c370c5..63187b07dde0 100644 --- a/drivers/tee/optee/core.c +++ b/drivers/tee/optee/core.c @@ -86,16 +86,6 @@ int optee_from_msg_param(struct tee_param *params, size_t num_params, return rc; p->u.memref.shm_offs = mp->u.tmem.buf_ptr - pa; p->u.memref.shm = shm; - - /* Check that the memref is covered by the shm object */ - if (p->u.memref.size) { - size_t o = p->u.memref.shm_offs + - p->u.memref.size - 1; - - rc = tee_shm_get_pa(shm, o, NULL); - if (rc) - return rc; - } break; default: return -EINVAL; -- 2.30.2

5 years, 1 month

1
0
0 0

[PATCH AUTOSEL 4.19 10/21] tee: optee: do not check memref size on return from Secure World

by Sasha Levin

From: Jerome Forissier <jerome(a)forissier.org> [ Upstream commit c650b8dc7a7910eb25af0aac1720f778b29e679d ] When Secure World returns, it may have changed the size attribute of the memory references passed as [in/out] parameters. The GlobalPlatform TEE Internal Core API specification does not restrict the values that this size can take. In particular, Secure World may increase the value to be larger than the size of the input buffer to indicate that it needs more. Therefore, the size check in optee_from_msg_param() is incorrect and needs to be removed. This fixes a number of failed test cases in the GlobalPlatform TEE Initial Configuratiom Test Suite v2_0_0_0-2017_06_09 when OP-TEE is compiled without dynamic shared memory support (CFG_CORE_DYN_SHM=n). Reviewed-by: Sumit Garg <sumit.garg(a)linaro.org> Suggested-by: Jens Wiklander <jens.wiklander(a)linaro.org> Signed-off-by: Jerome Forissier <jerome(a)forissier.org> Signed-off-by: Jens Wiklander <jens.wiklander(a)linaro.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/tee/optee/core.c | 10 ---------- 1 file changed, 10 deletions(-) diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c index 2f254f957b0a..1d71fcb13dba 100644 --- a/drivers/tee/optee/core.c +++ b/drivers/tee/optee/core.c @@ -87,16 +87,6 @@ int optee_from_msg_param(struct tee_param *params, size_t num_params, return rc; p->u.memref.shm_offs = mp->u.tmem.buf_ptr - pa; p->u.memref.shm = shm; - - /* Check that the memref is covered by the shm object */ - if (p->u.memref.size) { - size_t o = p->u.memref.shm_offs + - p->u.memref.size - 1; - - rc = tee_shm_get_pa(shm, o, NULL); - if (rc) - return rc; - } break; case OPTEE_MSG_ATTR_TYPE_RMEM_INPUT: case OPTEE_MSG_ATTR_TYPE_RMEM_OUTPUT: -- 2.30.2

5 years, 1 month

1
0
0 0

[PATCH AUTOSEL 5.4 16/34] tee: optee: do not check memref size on return from Secure World

by Sasha Levin

From: Jerome Forissier <jerome(a)forissier.org> [ Upstream commit c650b8dc7a7910eb25af0aac1720f778b29e679d ] When Secure World returns, it may have changed the size attribute of the memory references passed as [in/out] parameters. The GlobalPlatform TEE Internal Core API specification does not restrict the values that this size can take. In particular, Secure World may increase the value to be larger than the size of the input buffer to indicate that it needs more. Therefore, the size check in optee_from_msg_param() is incorrect and needs to be removed. This fixes a number of failed test cases in the GlobalPlatform TEE Initial Configuratiom Test Suite v2_0_0_0-2017_06_09 when OP-TEE is compiled without dynamic shared memory support (CFG_CORE_DYN_SHM=n). Reviewed-by: Sumit Garg <sumit.garg(a)linaro.org> Suggested-by: Jens Wiklander <jens.wiklander(a)linaro.org> Signed-off-by: Jerome Forissier <jerome(a)forissier.org> Signed-off-by: Jens Wiklander <jens.wiklander(a)linaro.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/tee/optee/core.c | 10 ---------- 1 file changed, 10 deletions(-) diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c index b830e0a87fba..ba6cfba589a6 100644 --- a/drivers/tee/optee/core.c +++ b/drivers/tee/optee/core.c @@ -78,16 +78,6 @@ int optee_from_msg_param(struct tee_param *params, size_t num_params, return rc; p->u.memref.shm_offs = mp->u.tmem.buf_ptr - pa; p->u.memref.shm = shm; - - /* Check that the memref is covered by the shm object */ - if (p->u.memref.size) { - size_t o = p->u.memref.shm_offs + - p->u.memref.size - 1; - - rc = tee_shm_get_pa(shm, o, NULL); - if (rc) - return rc; - } break; case OPTEE_MSG_ATTR_TYPE_RMEM_INPUT: case OPTEE_MSG_ATTR_TYPE_RMEM_OUTPUT: -- 2.30.2

5 years, 1 month

1
0
0 0

OP-TEE 3.13.0 has been released

by Ruchika Gupta

Hi, I'm pleased to announce that the v3.13.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/30c13f9e2ff178c9a299e409de75d5052… Regards, Ruchika

5 years, 1 month

1
0
0 0

Re: Linaro OP-TEE Contributions meeting April 2021

by Elvira Khabirova

On Mon, 19 Apr 2021 12:30:51 +0000 Joakim Bech via OP-TEE <op-tee(a)lists.trustedfirmware.org> wrote: > Hi, > > LOC monthly meeting is planned to take place Thursday April 29th(a)17.00 > (UTC+2). > > First, note that we have pushed the meeting forward one hour. If you > subscribe to the meeting via the TrustedFirmware calendar, then your invite > hopefully should've been updated (it could be worth cross checking). > > This month we will have Achin Gupta from Arm giving us an update regarding > the evolution of FF-A and how that could work together with virtualization. > > Usually there is some time left over for other discussions. So if you > have anything you'd like to talk about, then please let me know by replying > to this email thread. We at OMP would like to discuss GLOBEX - the REE/TEE synchronization mechanism that we've proposed at https://github.com/OP-TEE/optee_os/issues/4539 . It allows for sharing access to HW resources - something that came up on the last contributors meeting. We would like to present the design and hear your thoughts about it. > Related to that, Linaro arranged an "OP-TEE readiness > for safety" workshop last week. We're looking at all kinds of things > related to that right now. But this is also something that we could touch > in the LOC meeting. How would that affect upstream work? What code changes > could we expect etc? Any expertise out there who would be interested in > collaborating? > > OP-TEE 3.13.0 is planned to be released 2012-04-30, so in case you have any > questions related to that, then the LOC meeting would be a good opportunity > to ask. > > Meeting details: > --------------- > Date/time: Thursday April 29th(a)17.00 (UTC+2) > https://everytimezone.com/s/c32cdcc3 > Connection details: https://www.trustedfirmware.org/meetings/ > Meeting notes: http://bit.ly/loc-notes > Project page: https://www.linaro.org/projects#trusted-substrate_TS > > Regards, > Joakim on behalf of the Linaro OP-TEE team

5 years, 1 month

2
1
0 0

Preparing for OP-TEE 3.13.0

by Ruchika Gupta

[BCC all OP-TEE maintainers] Hi OP-TEE maintainers & contributors, OP-TEE v3.13.0 is scheduled to be released at 2021-04-30. 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/4552. 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, Ruchika

5 years, 1 month

1
1
0 0

[PATCH v9 0/4] Introduce TEE based Trusted Keys support

by Sumit Garg

Add support for TEE based trusted keys where TEE provides the functionality to seal and unseal trusted keys using hardware unique key. Also, this is an alternative in case platform doesn't possess a TPM device. This patch-set has been tested with OP-TEE based early TA which is already merged in upstream [1]. [1] https://github.com/OP-TEE/optee_os/commit/f86ab8e7e0de869dfa25ca05a37ee070d… Changes in v9: 1. Rebased to latest tpmdd/master. 2. Defined pr_fmt() and removed redundant tags. 3. Patch #2: incorporated misc. comments. 4. Patch #3: incorporated doc changes from Elaine and misc. comments from Randy. 5. Patch #4: reverted to separate maintainer entry as per request from Jarkko. 6. Added Jarkko's Tested-by: tag on patch #2. Changes in v8: 1. Added static calls support instead of indirect calls. 2. Documented trusted keys source module parameter. 3. Refined patch #1 commit message discription. 4. Addressed misc. comments on patch #2. 5. Added myself as Trusted Keys co-maintainer instead. 6. Rebased to latest tpmdd master. Changes in v7: 1. Added a trusted.source module parameter in order to enforce user's choice in case a particular platform posses both TPM and TEE. 2. Refine commit description for patch #1. Changes in v6: 1. Revert back to dynamic detection of trust source. 2. Drop author mention from trusted_core.c and trusted_tpm1.c files. 3. Rebased to latest tpmdd/master. Changes in v5: 1. Drop dynamic detection of trust source and use compile time flags instead. 2. Rename trusted_common.c -> trusted_core.c. 3. Rename callback: cleanup() -> exit(). 4. Drop "tk" acronym. 5. Other misc. comments. 6. Added review tags for patch #3 and #4. Changes in v4: 1. Pushed independent TEE features separately: - Part of recent TEE PR: https://lkml.org/lkml/2020/5/4/1062 2. Updated trusted-encrypted doc with TEE as a new trust source. 3. Rebased onto latest tpmdd/master. Changes in v3: 1. Update patch #2 to support registration of multiple kernel pages. 2. Incoporate dependency patch #4 in this patch-set: https://patchwork.kernel.org/patch/11091435/ Changes in v2: 1. Add reviewed-by tags for patch #1 and #2. 2. Incorporate comments from Jens for patch #3. 3. Switch to use generic trusted keys framework. Sumit Garg (4): KEYS: trusted: Add generic trusted keys framework KEYS: trusted: Introduce TEE based Trusted Keys doc: trusted-encrypted: updates with TEE as a new trust source MAINTAINERS: Add entry for TEE based Trusted Keys .../admin-guide/kernel-parameters.txt | 12 + .../security/keys/trusted-encrypted.rst | 171 ++++++-- MAINTAINERS | 8 + include/keys/trusted-type.h | 53 +++ include/keys/trusted_tee.h | 16 + include/keys/trusted_tpm.h | 29 +- security/keys/trusted-keys/Makefile | 2 + security/keys/trusted-keys/trusted_core.c | 358 +++++++++++++++++ security/keys/trusted-keys/trusted_tee.c | 317 +++++++++++++++ security/keys/trusted-keys/trusted_tpm1.c | 366 ++++-------------- 10 files changed, 981 insertions(+), 351 deletions(-) create mode 100644 include/keys/trusted_tee.h create mode 100644 security/keys/trusted-keys/trusted_core.c create mode 100644 security/keys/trusted-keys/trusted_tee.c -- 2.25.1

5 years, 2 months

3
20
0 0

[PATCH] optee: use export_uuid() to copy client UUID

by Jens Wiklander

Prior to this patch optee_open_session() was making assumptions about the internal format of uuid_t by casting a memory location in a parameter struct to uuid_t *. Fix this using export_uuid() to get a well defined binary representation and also add an octets field in struct optee_msg_param in order to avoid casting. Fixes: c5b4312bea5d ("tee: optee: Add support for session login client UUID generation") Suggested-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Signed-off-by: Jens Wiklander <jens.wiklander(a)linaro.org> --- drivers/tee/optee/call.c | 6 ++++-- drivers/tee/optee/optee_msg.h | 6 ++++-- 2 files changed, 8 insertions(+), 4 deletions(-) diff --git a/drivers/tee/optee/call.c b/drivers/tee/optee/call.c index 7a77e375b503..6b52f0c526ba 100644 --- a/drivers/tee/optee/call.c +++ b/drivers/tee/optee/call.c @@ -216,6 +216,7 @@ int optee_open_session(struct tee_context *ctx, struct optee_msg_arg *msg_arg; phys_addr_t msg_parg; struct optee_session *sess = NULL; + uuid_t client_uuid; /* +2 for the meta parameters added below */ shm = get_msg_arg(ctx, arg->num_params + 2, &msg_arg, &msg_parg); @@ -236,10 +237,11 @@ int optee_open_session(struct tee_context *ctx, memcpy(&msg_arg->params[0].u.value, arg->uuid, sizeof(arg->uuid)); msg_arg->params[1].u.value.c = arg->clnt_login; - rc = tee_session_calc_client_uuid((uuid_t *)&msg_arg->params[1].u.value, - arg->clnt_login, arg->clnt_uuid); + rc = tee_session_calc_client_uuid(&client_uuid, arg->clnt_login, + arg->clnt_uuid); if (rc) goto out; + export_uuid(msg_arg->params[1].u.octets, &client_uuid); rc = optee_to_msg_param(msg_arg->params + 2, arg->num_params, param); if (rc) diff --git a/drivers/tee/optee/optee_msg.h b/drivers/tee/optee/optee_msg.h index 81ff593ac4ec..e3d72d09c484 100644 --- a/drivers/tee/optee/optee_msg.h +++ b/drivers/tee/optee/optee_msg.h @@ -9,7 +9,7 @@ #include <linux/types.h> /* - * This file defines the OP-TEE message protocol used to communicate + * This file defines the OP-TEE message protocol (ABI) used to communicate * with an instance of OP-TEE running in secure world. * * This file is divided into two sections. @@ -144,9 +144,10 @@ struct optee_msg_param_value { * @tmem: parameter by temporary memory reference * @rmem: parameter by registered memory reference * @value: parameter by opaque value + * @octets: parameter by octet string * * @attr & OPTEE_MSG_ATTR_TYPE_MASK indicates if tmem, rmem or value is used in - * the union. OPTEE_MSG_ATTR_TYPE_VALUE_* indicates value, + * the union. OPTEE_MSG_ATTR_TYPE_VALUE_* indicates value or octets, * OPTEE_MSG_ATTR_TYPE_TMEM_* indicates @tmem and * OPTEE_MSG_ATTR_TYPE_RMEM_* indicates @rmem, * OPTEE_MSG_ATTR_TYPE_NONE indicates that none of the members are used. @@ -157,6 +158,7 @@ struct optee_msg_param { struct optee_msg_param_tmem tmem; struct optee_msg_param_rmem rmem; struct optee_msg_param_value value; + u8 octets[24]; } u; }; -- 2.25.1

5 years, 2 months

2
1
0 0

[PATCH v1 1/1] tee: optee: Provide special parameter field for UUID values

by Andy Shevchenko

Dereferencing something to uuid_t value is not good idea strictly speaking. Provide a special parameter field for UUID values and drop ugly casting. Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> --- drivers/tee/optee/call.c | 2 +- drivers/tee/optee/optee_msg.h | 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/tee/optee/call.c b/drivers/tee/optee/call.c index 1f0a68381656..d50cff7a9406 100644 --- a/drivers/tee/optee/call.c +++ b/drivers/tee/optee/call.c @@ -241,7 +241,7 @@ int optee_open_session(struct tee_context *ctx, memcpy(&msg_arg->params[0].u.value, arg->uuid, sizeof(arg->uuid)); msg_arg->params[1].u.value.c = arg->clnt_login; - rc = tee_session_calc_client_uuid((uuid_t *)&msg_arg->params[1].u.value, + rc = tee_session_calc_client_uuid(&msg_arg->params[1].u.uuid, arg->clnt_login, arg->clnt_uuid); if (rc) goto out; diff --git a/drivers/tee/optee/optee_msg.h b/drivers/tee/optee/optee_msg.h index 81ff593ac4ec..df095a974f3f 100644 --- a/drivers/tee/optee/optee_msg.h +++ b/drivers/tee/optee/optee_msg.h @@ -144,6 +144,7 @@ struct optee_msg_param_value { * @tmem: parameter by temporary memory reference * @rmem: parameter by registered memory reference * @value: parameter by opaque value + * @uuid: parameter by UUID * * @attr & OPTEE_MSG_ATTR_TYPE_MASK indicates if tmem, rmem or value is used in * the union. OPTEE_MSG_ATTR_TYPE_VALUE_* indicates value, @@ -157,6 +158,7 @@ struct optee_msg_param { struct optee_msg_param_tmem tmem; struct optee_msg_param_rmem rmem; struct optee_msg_param_value value; + uuid_t uuid; } u; }; -- 2.30.2

5 years, 2 months

3
6
0 0

Linaro OP-TEE Contributions meeting April 2021

by Joakim Bech

Hi, LOC monthly meeting is planned to take place Thursday April 29th(a)17.00 (UTC+2). First, note that we have pushed the meeting forward one hour. If you subscribe to the meeting via the TrustedFirmware calendar, then your invite hopefully should've been updated (it could be worth cross checking). This month we will have Achin Gupta from Arm giving us an update regarding the evolution of FF-A and how that could work together with virtualization. Usually there is some time left over for other discussions. So if you have anything you'd like to talk about, then please let me know by replying to this email thread. Related to that, Linaro arranged an "OP-TEE readiness for safety" workshop last week. We're looking at all kinds of things related to that right now. But this is also something that we could touch in the LOC meeting. How would that affect upstream work? What code changes could we expect etc? Any expertise out there who would be interested in collaborating? OP-TEE 3.13.0 is planned to be released 2012-04-30, so in case you have any questions related to that, then the LOC meeting would be a good opportunity to ask. Meeting details: --------------- Date/time: Thursday April 29th(a)17.00 (UTC+2) https://everytimezone.com/s/c32cdcc3 Connection details: https://www.trustedfirmware.org/meetings/ Meeting notes: http://bit.ly/loc-notes Project page: https://www.linaro.org/projects#trusted-substrate_TS Regards, Joakim on behalf of the Linaro OP-TEE team

5 years, 2 months

1
0
0 0

[PATCH v2] tee: amdtee: unload TA only when its refcount becomes 0

by Rijo Thomas

Same Trusted Application (TA) can be loaded in multiple TEE contexts. If it is a single instance TA, the TA should not get unloaded from AMD Secure Processor, while it is still in use in another TEE context. Therefore reference count TA and unload it when the count becomes zero. Fixes: 757cc3e9ff1d ("tee: add AMD-TEE driver") Reviewed-by: Devaraj Rangasamy <Devaraj.Rangasamy(a)amd.com> Signed-off-by: Rijo Thomas <Rijo-john.Thomas(a)amd.com> --- v2: * Unload TA if get_ta_refcount() fails drivers/tee/amdtee/amdtee_private.h | 13 ++++ drivers/tee/amdtee/call.c | 94 ++++++++++++++++++++++++++--- drivers/tee/amdtee/core.c | 15 +++-- 3 files changed, 106 insertions(+), 16 deletions(-) diff --git a/drivers/tee/amdtee/amdtee_private.h b/drivers/tee/amdtee/amdtee_private.h index 337c8d82f74e..6d0f7062bb87 100644 --- a/drivers/tee/amdtee/amdtee_private.h +++ b/drivers/tee/amdtee/amdtee_private.h @@ -21,6 +21,7 @@ #define TEEC_SUCCESS 0x00000000 #define TEEC_ERROR_GENERIC 0xFFFF0000 #define TEEC_ERROR_BAD_PARAMETERS 0xFFFF0006 +#define TEEC_ERROR_OUT_OF_MEMORY 0xFFFF000C #define TEEC_ERROR_COMMUNICATION 0xFFFF000E #define TEEC_ORIGIN_COMMS 0x00000002 @@ -93,6 +94,18 @@ struct amdtee_shm_data { u32 buf_id; }; +/** + * struct amdtee_ta_data - Keeps track of all TAs loaded in AMD Secure + * Processor + * @ta_handle: Handle to TA loaded in TEE + * @refcount: Reference count for the loaded TA + */ +struct amdtee_ta_data { + struct list_head list_node; + u32 ta_handle; + u32 refcount; +}; + #define LOWER_TWO_BYTE_MASK 0x0000FFFF /** diff --git a/drivers/tee/amdtee/call.c b/drivers/tee/amdtee/call.c index 096dd4d92d39..06abaa518921 100644 --- a/drivers/tee/amdtee/call.c +++ b/drivers/tee/amdtee/call.c @@ -121,15 +121,69 @@ static int amd_params_to_tee_params(struct tee_param *tee, u32 count, return ret; } +static DEFINE_MUTEX(ta_refcount_mutex); +static struct list_head ta_list = LIST_HEAD_INIT(ta_list); + +static u32 get_ta_refcount(u32 ta_handle) +{ + struct amdtee_ta_data *ta_data; + u32 count = 0; + + /* Caller must hold a mutex */ + list_for_each_entry(ta_data, &ta_list, list_node) + if (ta_data->ta_handle == ta_handle) + return ++ta_data->refcount; + + ta_data = kzalloc(sizeof(*ta_data), GFP_KERNEL); + if (ta_data) { + ta_data->ta_handle = ta_handle; + ta_data->refcount = 1; + count = ta_data->refcount; + list_add(&ta_data->list_node, &ta_list); + } + + return count; +} + +static u32 put_ta_refcount(u32 ta_handle) +{ + struct amdtee_ta_data *ta_data; + u32 count = 0; + + /* Caller must hold a mutex */ + list_for_each_entry(ta_data, &ta_list, list_node) + if (ta_data->ta_handle == ta_handle) { + count = --ta_data->refcount; + if (count == 0) { + list_del(&ta_data->list_node); + kfree(ta_data); + break; + } + } + + return count; +} + int handle_unload_ta(u32 ta_handle) { struct tee_cmd_unload_ta cmd = {0}; - u32 status; + u32 status, count; int ret; if (!ta_handle) return -EINVAL; + mutex_lock(&ta_refcount_mutex); + + count = put_ta_refcount(ta_handle); + + if (count) { + pr_debug("unload ta: not unloading %u count %u\n", + ta_handle, count); + ret = -EBUSY; + goto unlock; + } + cmd.ta_handle = ta_handle; ret = psp_tee_process_cmd(TEE_CMD_ID_UNLOAD_TA, (void *)&cmd, @@ -137,8 +191,12 @@ int handle_unload_ta(u32 ta_handle) if (!ret && status != 0) { pr_err("unload ta: status = 0x%x\n", status); ret = -EBUSY; + } else { + pr_debug("unloaded ta handle %u\n", ta_handle); } +unlock: + mutex_unlock(&ta_refcount_mutex); return ret; } @@ -340,7 +398,8 @@ int handle_open_session(struct tee_ioctl_open_session_arg *arg, u32 *info, int handle_load_ta(void *data, u32 size, struct tee_ioctl_open_session_arg *arg) { - struct tee_cmd_load_ta cmd = {0}; + struct tee_cmd_unload_ta unload_cmd = {0}; + struct tee_cmd_load_ta load_cmd = {0}; phys_addr_t blob; int ret; @@ -353,21 +412,36 @@ int handle_load_ta(void *data, u32 size, struct tee_ioctl_open_session_arg *arg) return -EINVAL; } - cmd.hi_addr = upper_32_bits(blob); - cmd.low_addr = lower_32_bits(blob); - cmd.size = size; + load_cmd.hi_addr = upper_32_bits(blob); + load_cmd.low_addr = lower_32_bits(blob); + load_cmd.size = size; - ret = psp_tee_process_cmd(TEE_CMD_ID_LOAD_TA, (void *)&cmd, - sizeof(cmd), &arg->ret); + mutex_lock(&ta_refcount_mutex); + + ret = psp_tee_process_cmd(TEE_CMD_ID_LOAD_TA, (void *)&load_cmd, + sizeof(load_cmd), &arg->ret); if (ret) { arg->ret_origin = TEEC_ORIGIN_COMMS; arg->ret = TEEC_ERROR_COMMUNICATION; - } else { - set_session_id(cmd.ta_handle, 0, &arg->session); + } else if (arg->ret == TEEC_SUCCESS) { + ret = get_ta_refcount(load_cmd.ta_handle); + if (!ret) { + arg->ret_origin = TEEC_ORIGIN_COMMS; + arg->ret = TEEC_ERROR_OUT_OF_MEMORY; + + /* Unload the TA on error */ + unload_cmd.ta_handle = load_cmd.ta_handle; + psp_tee_process_cmd(TEE_CMD_ID_UNLOAD_TA, + (void *)&unload_cmd, + sizeof(unload_cmd), &ret); + } else { + set_session_id(load_cmd.ta_handle, 0, &arg->session); + } } + mutex_unlock(&ta_refcount_mutex); pr_debug("load TA: TA handle = 0x%x, RO = 0x%x, ret = 0x%x\n", - cmd.ta_handle, arg->ret_origin, arg->ret); + load_cmd.ta_handle, arg->ret_origin, arg->ret); return 0; } diff --git a/drivers/tee/amdtee/core.c b/drivers/tee/amdtee/core.c index 8a6a8f30bb42..da6b88e80dc0 100644 --- a/drivers/tee/amdtee/core.c +++ b/drivers/tee/amdtee/core.c @@ -59,10 +59,9 @@ static void release_session(struct amdtee_session *sess) continue; handle_close_session(sess->ta_handle, sess->session_info[i]); + handle_unload_ta(sess->ta_handle); } - /* Unload Trusted Application once all sessions are closed */ - handle_unload_ta(sess->ta_handle); kfree(sess); } @@ -224,8 +223,6 @@ static void destroy_session(struct kref *ref) struct amdtee_session *sess = container_of(ref, struct amdtee_session, refcount); - /* Unload the TA from TEE */ - handle_unload_ta(sess->ta_handle); mutex_lock(&session_list_mutex); list_del(&sess->list_node); mutex_unlock(&session_list_mutex); @@ -238,7 +235,7 @@ int amdtee_open_session(struct tee_context *ctx, { struct amdtee_context_data *ctxdata = ctx->data; struct amdtee_session *sess = NULL; - u32 session_info; + u32 session_info, ta_handle; size_t ta_size; int rc, i; void *ta; @@ -259,11 +256,14 @@ int amdtee_open_session(struct tee_context *ctx, if (arg->ret != TEEC_SUCCESS) goto out; + ta_handle = get_ta_handle(arg->session); + mutex_lock(&session_list_mutex); sess = alloc_session(ctxdata, arg->session); mutex_unlock(&session_list_mutex); if (!sess) { + handle_unload_ta(ta_handle); rc = -ENOMEM; goto out; } @@ -277,6 +277,7 @@ int amdtee_open_session(struct tee_context *ctx, if (i >= TEE_NUM_SESSIONS) { pr_err("reached maximum session count %d\n", TEE_NUM_SESSIONS); + handle_unload_ta(ta_handle); kref_put(&sess->refcount, destroy_session); rc = -ENOMEM; goto out; @@ -289,12 +290,13 @@ int amdtee_open_session(struct tee_context *ctx, spin_lock(&sess->lock); clear_bit(i, sess->sess_mask); spin_unlock(&sess->lock); + handle_unload_ta(ta_handle); kref_put(&sess->refcount, destroy_session); goto out; } sess->session_info[i] = session_info; - set_session_id(sess->ta_handle, i, &arg->session); + set_session_id(ta_handle, i, &arg->session); out: free_pages((u64)ta, get_order(ta_size)); return rc; @@ -329,6 +331,7 @@ int amdtee_close_session(struct tee_context *ctx, u32 session) /* Close the session */ handle_close_session(ta_handle, session_info); + handle_unload_ta(ta_handle); kref_put(&sess->refcount, destroy_session); -- 2.17.1

5 years, 2 months

3
6
0 0

[PATCH] tee: optee: fix build error caused by recent optee tracepoints feature

by Jisheng Zhang

If build kernel without "O=dir", below error will be seen: In file included from drivers/tee/optee/optee_trace.h:67, from drivers/tee/optee/call.c:18: ./include/trace/define_trace.h:95:42: fatal error: ./optee_trace.h: No such file or directory 95 | #include TRACE_INCLUDE(TRACE_INCLUDE_FILE) | ^ compilation terminated. Fix it by adding below line to Makefile: CFLAGS_call.o := -I$(src) Tested with and without "O=dir", both can build successfully. Reported-by: Guenter Roeck <linux(a)roeck-us.net> Suggested-by: Steven Rostedt <rostedt(a)goodmis.org> Signed-off-by: Jisheng Zhang <Jisheng.Zhang(a)synaptics.com> --- drivers/tee/optee/Makefile | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/tee/optee/Makefile b/drivers/tee/optee/Makefile index 56263ae3b1d7..3aa33ea9e6a6 100644 --- a/drivers/tee/optee/Makefile +++ b/drivers/tee/optee/Makefile @@ -6,3 +6,6 @@ optee-objs += rpc.o optee-objs += supp.o optee-objs += shm_pool.o optee-objs += device.o + +# for tracing framework to find optee_trace.h +CFLAGS_call.o := -I$(src) -- 2.31.0

5 years, 2 months

3
5
0 0

[PATCH] tee: amdtee: unload TA only when its refcount becomes 0

by Rijo Thomas

Same Trusted Application (TA) can be loaded in multiple TEE contexts. If it is a single instance TA, the TA should not get unloaded from AMD Secure Processor, while it is still in use in another TEE context. Therefore reference count TA and unload it when the count becomes zero. Fixes: 757cc3e9ff1d ("tee: add AMD-TEE driver") Reviewed-by: Devaraj Rangasamy <Devaraj.Rangasamy(a)amd.com> Signed-off-by: Rijo Thomas <Rijo-john.Thomas(a)amd.com> --- drivers/tee/amdtee/amdtee_private.h | 13 +++++ drivers/tee/amdtee/call.c | 73 +++++++++++++++++++++++++++-- drivers/tee/amdtee/core.c | 15 +++--- 3 files changed, 92 insertions(+), 9 deletions(-) diff --git a/drivers/tee/amdtee/amdtee_private.h b/drivers/tee/amdtee/amdtee_private.h index 337c8d82f74e..6d0f7062bb87 100644 --- a/drivers/tee/amdtee/amdtee_private.h +++ b/drivers/tee/amdtee/amdtee_private.h @@ -21,6 +21,7 @@ #define TEEC_SUCCESS 0x00000000 #define TEEC_ERROR_GENERIC 0xFFFF0000 #define TEEC_ERROR_BAD_PARAMETERS 0xFFFF0006 +#define TEEC_ERROR_OUT_OF_MEMORY 0xFFFF000C #define TEEC_ERROR_COMMUNICATION 0xFFFF000E #define TEEC_ORIGIN_COMMS 0x00000002 @@ -93,6 +94,18 @@ struct amdtee_shm_data { u32 buf_id; }; +/** + * struct amdtee_ta_data - Keeps track of all TAs loaded in AMD Secure + * Processor + * @ta_handle: Handle to TA loaded in TEE + * @refcount: Reference count for the loaded TA + */ +struct amdtee_ta_data { + struct list_head list_node; + u32 ta_handle; + u32 refcount; +}; + #define LOWER_TWO_BYTE_MASK 0x0000FFFF /** diff --git a/drivers/tee/amdtee/call.c b/drivers/tee/amdtee/call.c index 096dd4d92d39..e10601417ea3 100644 --- a/drivers/tee/amdtee/call.c +++ b/drivers/tee/amdtee/call.c @@ -121,15 +121,69 @@ static int amd_params_to_tee_params(struct tee_param *tee, u32 count, return ret; } +static DEFINE_MUTEX(ta_refcount_mutex); +static struct list_head ta_list = LIST_HEAD_INIT(ta_list); + +static u32 get_ta_refcount(u32 ta_handle) +{ + struct amdtee_ta_data *ta_data; + u32 count = 0; + + /* Caller must hold a mutex */ + list_for_each_entry(ta_data, &ta_list, list_node) + if (ta_data->ta_handle == ta_handle) + return ++ta_data->refcount; + + ta_data = kzalloc(sizeof(*ta_data), GFP_KERNEL); + if (ta_data) { + ta_data->ta_handle = ta_handle; + ta_data->refcount = 1; + count = ta_data->refcount; + list_add(&ta_data->list_node, &ta_list); + } + + return count; +} + +static u32 put_ta_refcount(u32 ta_handle) +{ + struct amdtee_ta_data *ta_data; + u32 count = 0; + + /* Caller must hold a mutex */ + list_for_each_entry(ta_data, &ta_list, list_node) + if (ta_data->ta_handle == ta_handle) { + count = --ta_data->refcount; + if (count == 0) { + list_del(&ta_data->list_node); + kfree(ta_data); + break; + } + } + + return count; +} + int handle_unload_ta(u32 ta_handle) { struct tee_cmd_unload_ta cmd = {0}; - u32 status; + u32 status, count; int ret; if (!ta_handle) return -EINVAL; + mutex_lock(&ta_refcount_mutex); + + count = put_ta_refcount(ta_handle); + + if (count) { + pr_debug("unload ta: not unloading %u count %u\n", + ta_handle, count); + ret = -EBUSY; + goto unlock; + } + cmd.ta_handle = ta_handle; ret = psp_tee_process_cmd(TEE_CMD_ID_UNLOAD_TA, (void *)&cmd, @@ -137,8 +191,12 @@ int handle_unload_ta(u32 ta_handle) if (!ret && status != 0) { pr_err("unload ta: status = 0x%x\n", status); ret = -EBUSY; + } else { + pr_debug("unloaded ta handle %u\n", ta_handle); } +unlock: + mutex_unlock(&ta_refcount_mutex); return ret; } @@ -357,14 +415,23 @@ int handle_load_ta(void *data, u32 size, struct tee_ioctl_open_session_arg *arg) cmd.low_addr = lower_32_bits(blob); cmd.size = size; + mutex_lock(&ta_refcount_mutex); + ret = psp_tee_process_cmd(TEE_CMD_ID_LOAD_TA, (void *)&cmd, sizeof(cmd), &arg->ret); if (ret) { arg->ret_origin = TEEC_ORIGIN_COMMS; arg->ret = TEEC_ERROR_COMMUNICATION; - } else { - set_session_id(cmd.ta_handle, 0, &arg->session); + } else if (arg->ret == TEEC_SUCCESS) { + ret = get_ta_refcount(cmd.ta_handle); + if (!ret) { + arg->ret_origin = TEEC_ORIGIN_COMMS; + arg->ret = TEEC_ERROR_OUT_OF_MEMORY; + } else { + set_session_id(cmd.ta_handle, 0, &arg->session); + } } + mutex_unlock(&ta_refcount_mutex); pr_debug("load TA: TA handle = 0x%x, RO = 0x%x, ret = 0x%x\n", cmd.ta_handle, arg->ret_origin, arg->ret); diff --git a/drivers/tee/amdtee/core.c b/drivers/tee/amdtee/core.c index 8a6a8f30bb42..da6b88e80dc0 100644 --- a/drivers/tee/amdtee/core.c +++ b/drivers/tee/amdtee/core.c @@ -59,10 +59,9 @@ static void release_session(struct amdtee_session *sess) continue; handle_close_session(sess->ta_handle, sess->session_info[i]); + handle_unload_ta(sess->ta_handle); } - /* Unload Trusted Application once all sessions are closed */ - handle_unload_ta(sess->ta_handle); kfree(sess); } @@ -224,8 +223,6 @@ static void destroy_session(struct kref *ref) struct amdtee_session *sess = container_of(ref, struct amdtee_session, refcount); - /* Unload the TA from TEE */ - handle_unload_ta(sess->ta_handle); mutex_lock(&session_list_mutex); list_del(&sess->list_node); mutex_unlock(&session_list_mutex); @@ -238,7 +235,7 @@ int amdtee_open_session(struct tee_context *ctx, { struct amdtee_context_data *ctxdata = ctx->data; struct amdtee_session *sess = NULL; - u32 session_info; + u32 session_info, ta_handle; size_t ta_size; int rc, i; void *ta; @@ -259,11 +256,14 @@ int amdtee_open_session(struct tee_context *ctx, if (arg->ret != TEEC_SUCCESS) goto out; + ta_handle = get_ta_handle(arg->session); + mutex_lock(&session_list_mutex); sess = alloc_session(ctxdata, arg->session); mutex_unlock(&session_list_mutex); if (!sess) { + handle_unload_ta(ta_handle); rc = -ENOMEM; goto out; } @@ -277,6 +277,7 @@ int amdtee_open_session(struct tee_context *ctx, if (i >= TEE_NUM_SESSIONS) { pr_err("reached maximum session count %d\n", TEE_NUM_SESSIONS); + handle_unload_ta(ta_handle); kref_put(&sess->refcount, destroy_session); rc = -ENOMEM; goto out; @@ -289,12 +290,13 @@ int amdtee_open_session(struct tee_context *ctx, spin_lock(&sess->lock); clear_bit(i, sess->sess_mask); spin_unlock(&sess->lock); + handle_unload_ta(ta_handle); kref_put(&sess->refcount, destroy_session); goto out; } sess->session_info[i] = session_info; - set_session_id(sess->ta_handle, i, &arg->session); + set_session_id(ta_handle, i, &arg->session); out: free_pages((u64)ta, get_order(ta_size)); return rc; @@ -329,6 +331,7 @@ int amdtee_close_session(struct tee_context *ctx, u32 session) /* Close the session */ handle_close_session(ta_handle, session_info); + handle_unload_ta(ta_handle); kref_put(&sess->refcount, destroy_session); -- 2.17.1

5 years, 2 months

2
2
0 0

[GIT PULL] OP-TEE memref size check for v5.13

by Jens Wiklander

Hello arm-soc maintainers, Please pull this small patch for the OP-TEE driver to remove the invalid size check of outgoing memref parameters. This code path is only activated for a certain configuration of OP-TEE in secure world (CFG_CORE_DYN_SHM=n) so this problem isn't always visible. Thanks, Jens The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15: Linux 5.12-rc2 (2021-03-05 17:33:41 -0800) are available in the Git repository at: git://git.linaro.org/people/jens.wiklander/linux-tee.git/ tags/optee-memref-size-for-v5.13 for you to fetch changes up to c650b8dc7a7910eb25af0aac1720f778b29e679d: tee: optee: do not check memref size on return from Secure World (2021-03-30 10:44:50 +0200) ---------------------------------------------------------------- OP-TEE skip check of returned memref size ---------------------------------------------------------------- Jerome Forissier (1): tee: optee: do not check memref size on return from Secure World drivers/tee/optee/core.c | 10 ---------- 1 file changed, 10 deletions(-)

5 years, 2 months

2
1
0 0

[GIT PULL] OP-TEE tracepoints fix for v5.13

by Jens Wiklander

Hello arm-soc maintainers, The previous pull request for OP-TEE tracepoints introduced a build error when building whithout O=..., apparently many regression builds uses that option. Please pull this small fix for the build error. Thanks, Jens The following changes since commit 0101947dbcc3204f08fb5b69a21dbd4b1535cad6: tee: optee: add invoke_fn tracepoints (2021-03-15 12:04:01 +0100) are available in the Git repository at: git://git.linaro.org/people/jens.wiklander/linux-tee.git/ tags/optee-tracepoints-fix-for-v5.13 for you to fetch changes up to 7ccdcaace80810175bd20b2ece856b42edd43991: tee: optee: fix build error caused by recent optee tracepoints feature (2021-03-30 09:33:33 +0200) ---------------------------------------------------------------- Fixes build error for recently added OP-TEE tracepoints ---------------------------------------------------------------- Jisheng Zhang (1): tee: optee: fix build error caused by recent optee tracepoints feature drivers/tee/optee/Makefile | 3 +++ 1 file changed, 3 insertions(+)

5 years, 2 months

2
3
0 0

Re: [PATCH 1/1] tee: optee: do not check memref size on return from Secure World

by Sumit Garg

On Mon, 22 Mar 2021 at 16:11, Jerome Forissier via OP-TEE <op-tee(a)lists.trustedfirmware.org> wrote: > > When Secure World returns, it may have changed the size attribute of the > memory references passed as [in/out] parameters. The GlobalPlatform TEE > Internal Core API specification does not restrict the values that this > size can take. In particular, Secure World may increase the value to be > larger than the size of the input buffer to indicate that it needs more. > > Therefore, the size check in optee_from_msg_param() is incorrect and > needs to be removed. This fixes a number of failed test cases in the > GlobalPlatform TEE Initial Configuratiom Test Suite v2_0_0_0-2017_06_09 > when OP-TEE is compiled without dynamic shared memory support > (CFG_CORE_DYN_SHM=n). > > Suggested-by: Jens Wiklander <jens.wiklander(a)linaro.org> > Signed-off-by: Jerome Forissier <jerome(a)forissier.org> > --- > drivers/tee/optee/core.c | 10 ---------- > 1 file changed, 10 deletions(-) > Looks good to me. Reviewed-by: Sumit Garg <sumit.garg(a)linaro.org> -Sumit > diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c > index 319a1e701163..ddb8f9ecf307 100644 > --- a/drivers/tee/optee/core.c > +++ b/drivers/tee/optee/core.c > @@ -79,16 +79,6 @@ int optee_from_msg_param(struct tee_param *params, size_t num_params, > return rc; > p->u.memref.shm_offs = mp->u.tmem.buf_ptr - pa; > p->u.memref.shm = shm; > - > - /* Check that the memref is covered by the shm object */ > - if (p->u.memref.size) { > - size_t o = p->u.memref.shm_offs + > - p->u.memref.size - 1; > - > - rc = tee_shm_get_pa(shm, o, NULL); > - if (rc) > - return rc; > - } > break; > case OPTEE_MSG_ATTR_TYPE_RMEM_INPUT: > case OPTEE_MSG_ATTR_TYPE_RMEM_OUTPUT: > -- > 2.25.1 >

5 years, 2 months

2
1
0 0

Build breakage in next-20210330 due to optee_trace.h

by Pratyush Yadav

Hi, I recently rebased a dev branch on top of next-20210330 (4143e05b7b17) and I notice a build error from the optee driver: In file included from drivers/tee/optee/call.c:18: In file included from drivers/tee/optee/optee_trace.h:67: ./include/trace/define_trace.h:95:10: fatal error: './optee_trace.h' file not found #include TRACE_INCLUDE(TRACE_INCLUDE_FILE) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./include/trace/define_trace.h:90:32: note: expanded from macro 'TRACE_INCLUDE' # define TRACE_INCLUDE(system) __TRACE_INCLUDE(system) ^~~~~~~~~~~~~~~~~~~~~~~ ./include/trace/define_trace.h:87:34: note: expanded from macro '__TRACE_INCLUDE' # define __TRACE_INCLUDE(system) __stringify(TRACE_INCLUDE_PATH/system.h) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./include/linux/stringify.h:10:27: note: expanded from macro '__stringify' #define __stringify(x...) __stringify_1(x) ^~~~~~~~~~~~~~~~ ./include/linux/stringify.h:9:29: note: expanded from macro '__stringify_1' #define __stringify_1(x...) #x ^~ <scratch space>:135:1: note: expanded from here "./optee_trace.h" ^~~~~~~~~~~~~~~~~ 1 error generated. The config is attached. I am building using clang. $ clang --version clang version 11.1.0 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/bin -- Regards, Pratyush Yadav

5 years, 2 months

2
1
0 0

RE: [TF-A] Firmware FuSa workshop

by Miklos Balint

To += op-tee(a)lists.trustedfirmware.org<mailto:op-tee@lists.trustedfirmware.org> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of François Ozog via TF-A Sent: 26 March 2021 19:08 To: Heinrich Schuchardt <xypron.glpk(a)gmx.de> Cc: tf-a(a)lists.trustedfirmware.org; Boot Architecture Mailman List <boot-architecture(a)lists.linaro.org>; Ilias Apalodimas <ilias.apalodimas(a)linaro.org> Subject: Re: [TF-A] Firmware FuSa workshop Le ven. 26 mars 2021 à 18:42, Heinrich Schuchardt <xypron.glpk(a)gmx.de<mailto:xypron.glpk@gmx.de>> a écrit : On 26.03.21 16:05, François Ozog wrote: > Hi, > > > Linaro is conducting an opportunity assessment to make OP-TEE ready for > functional safety sensitive environments. The goal is to present a plan to > Linaro members by the end of July 2021. > > The scope of the research is somewhat bigger because we can’t think of > OP-TEE without thinking of Trusted Firmware and Hafnium. The plan will > though not address those (unless we recognize we have to). We don’t think > U-Boot shall be part of the picture but we are welcoming contradictory > points of views. Hello François, Some boards boot via SPL->TF-A->U-Boot. Here U-Boot's SPL is relevant for OP-TEE's security. U-Boot can save variables via OP-TEE (implemented by Ilias). In this case OP-TEE has an implication on secure boot. I fully understand that these scenarios are not in the focus of the workshop. it may if companies have this particular flow in mind for safety certification. Our goal is not to make all boot flows safety ready but to identify which ones we need to consider. And the workshop may help in this identification. Best regards Heinrich > > We are organizing a 2 hours workshop on April 15th 9am CET to mostly hear > about use cases and ideas about Long Term Support requirements . We will > present the state of the research. > > The first use case is booting a safety certified type-1 hypervisor (open > source or commercial is irrelevant). > > But we know there are many more: please be ready to contribute. > > We think of more radical use cases: a safety payload is actually loaded as > a Secure Partition on top of Hafnium with OP-TEE or Zephyr used as a device > backends. In other words, Trust Zone hosts both safety and security worlds > , EL3 being the « software root of trust » pivot world. In those cases, > some cores never go out of secure state… > > > Agenda (to be refined) > > - > > Vision > - > > State of the research > <https://docs.google.com/presentation/u/0/d/1jWqu39gCF-5XzbFkodXsiVNJJLUN88B…> > - > > Use cases discussion > - > > What is the right scope? > - > > “Who do what” discussion (LTS, archiving...) > - > > Safety personnel (Linaro and contractors) discussion > - > > Other considerations from participants? > - > > Community organizations and funding? > - > > Closing and next steps > > > Should you want to participate and have not yet received an invite, please > contact me directly. > > Cordially, > > François-Frédéric > > PS: Please reach out should you want another date with a time compatible > with more time zones. This alternate date is not guaranteed though. > > -- [https://drive.google.com/a/linaro.org/uc?id=0BxTAygkus3RgQVhuNHMwUi1mYWc&ex…] François-Frédéric Ozog | Director Linaro Edge & Fog Computing Group T: +33.67221.6485 francois.ozog(a)linaro.org<mailto:francois.ozog@linaro.org> | Skype: ffozog

5 years, 2 months

1
0
0 0

Re: Possible OB1 bug in imx_csu.c

by Jerome Forissier

On 2/22/21 11:26 AM, Jerome Forissier via OP-TEE wrote: > Hi Robert, > > On 2/22/21 11:01 AM, Robert Delien via OP-TEE wrote: >> Hi, >> >> In imx_csu.c, the Central Security Unit's CSU_CSL*n* registers are set, >> configuring access privileges for different peripherals. These registers >> range from CSU_CSL0 (@ 0x021c0000) to CSU_CSL39 (@ 0x021c009c). >> >> The different i.MX6 platform variants each have their individual tables, >> filled with sets of CSL index and register value, terminated by a sentinel >> set with the index set to -1. (the reason for the parentheses around -1 >> espaces me) >> >> in .../core/arch/arm/plat-imx/drivers/imx_csu.c:csu_init()@115, a while >> loop runs through this aforementioned table, setting the CSL registers >> according to the table. However, this loop loops on CSL index values > 0: >> while (csu_setting->csu_index *>* 0) { >> io_write32(csu_base + (csu_setting->csu_index * 4), >> csu_setting->value); >> >> csu_setting++; >> } >> I think it should loop on CSL index values >= 0, because index 0 is a valid >> index, utilized for the PWM peripherals. (I also think csl_index is a more >> descriptive name, but that's besides the point). >> >> I have attached a patch for his. > > It does look like a genuine bug to me, but I will let the i.MX expert > comment further. Unfortunately, the OP-TEE ML strips attachments. Would > you mind creating a GitHub pull request [1] (preferred method), or send > the patch inline? > > [1] https://github.com/OP-TEE/optee_os/pulls > > Thanks, > https://github.com/OP-TEE/optee_os/pull/4511

5 years, 2 months

1
0
0 0

Re: [TF-A] EHF + OPTEE on ARM64

by Peng Fan

Hi Sandeep, I just noticed that your PR is abandoned. Will you resend your PR? Thanks, Peng. ________________________________ From: OP-TEE <op-tee-bounces(a)lists.trustedfirmware.org> on behalf of Peng Fan via OP-TEE <op-tee(a)lists.trustedfirmware.org> Sent: Tuesday, March 23, 2021 10:14 AM To: Sandeep Tripathy <sandeep.tripathy(a)broadcom.com> Cc: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org>; op-tee(a)lists.trustedfirmware.org <op-tee(a)lists.trustedfirmware.org> Subject: RE: [TF-A] EHF + OPTEE on ARM64 Hi Sandeep > Subject: Re: [TF-A] EHF + OPTEE on ARM64 > > Hi Peng, > > 1-Asynchronous preemption of SP: > The long route is to make changes in the dispatcher and the > corresponding SPD implementation to have synchronous preemption. > ie: OP-TEE dispatcher will implement a G1NS (fiq) handler and invoke > an entry of OP-TEE synchronously. OP-TEE will save the thread context > and return. > I did some POC but the complexity and effort to generalise was not > justified by our requirement at that point especially envisioning the > movement to SPMD in future. > > 2-Synchronous preemption of SP: > ref: > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr… > > I used this approach instead to unblock OP-TEE work alongside EHF. > This serves the purpose without changing the routing model with a > limitation that non yielding/fast SMC can > not be preempted. And ofcourse OP-TEE can mask G0 interrupt in > anycase. But I think this is sufficient for your purpose. > > Please feedback if the above patch works for you. I was trying using #ifndef SPD_opteed to wrap the secure stuff. Thanks for your patch. I test on i.MX8MM-EVK, it works well. Thanks, Peng. > > Thanks > Sandeep > > On Mon, Mar 22, 2021 at 2:43 PM Peng Fan via TF-A > <tf-a(a)lists.trustedfirmware.org> wrote: > > > > Hi Achin, > > > > > > > > We are using SDEI for Jailhouse hypervisor to minimize interrupt latency, > however we also wanna use OP-TEE when SDEI enabled. > > > > > > > > So I wanna how to make both work together. > > > > > > > > Thanks, > > > > Peng. > > > > > > > > From: Achin Gupta [mailto:Achin.Gupta@arm.com] > > Sent: 2021年3月17日 17:59 > > To: Peng Fan <peng.fan(a)nxp.com>; Jens Wiklander > <jens.wiklander(a)linaro.org> > > Cc: op-tee(a)lists.trustedfirmware.org; tf-a(a)lists.trustedfirmware.org > > Subject: Re: EHF + OPTEE on ARM64 > > > > > > > > Hi Peng, > > > > > > > > +TF-A folk. > > > > > > > > My 0.02$. > > > > > > > > What is the problem you are trying to solve? Why do you need to run > OP-TEE and EHF together? EHF was originally written to support a S-EL0 SP > that is managed directly by TF-A in EL3 (TF-A folk can chime in). > > > > > > > > The SP could perform RAS error handling for which it needs the EHF. The EHF > triages asynchronous exceptions and hands RAS errors to the SP for further > handling. > > > > > > > > This is just one use case but there is no Trusted OS in these configurations. > > > > > > > > So, it would help to understand the requirement. > > > > > > > > cheers, > > > > Achin > > > > > > > > ________________________________ > > > > From: OP-TEE <op-tee-bounces(a)lists.trustedfirmware.org> on behalf of > Jens Wiklander via OP-TEE <op-tee(a)lists.trustedfirmware.org> > > Sent: 17 March 2021 09:23 > > To: Peng Fan <peng.fan(a)nxp.com> > > Cc: op-tee(a)lists.trustedfirmware.org <op-tee(a)lists.trustedfirmware.org> > > Subject: Re: EHF + OPTEE on ARM64 > > > > > > > > On Wed, Mar 17, 2021 at 9:43 AM Peng Fan <peng.fan(a)nxp.com> wrote: > > > > > > > Subject: Re: EHF + OPTEE on ARM64 > > > > > > > > On Wed, Mar 17, 2021 at 9:02 AM Peng Fan <peng.fan(a)nxp.com> > wrote: > > > > > > > > > > > Subject: Re: EHF + OPTEE on ARM64 > > > > > > > > > > > > On Wed, Mar 17, 2021 at 8:41 AM Peng Fan <peng.fan(a)nxp.com> > wrote: > > > > > > > > > > > > > > > Subject: Re: EHF + OPTEE on ARM64 > > > > > > > > > > > > > > > > On Tue, Mar 16, 2021 at 11:08 AM Peng Fan > <peng.fan(a)nxp.com> > > > > wrote: > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > In bl31/ehf.c, there are following two lines, per my > > > > > > > > > understanding, when cpu is in secure world, the non-secure > > > > > > > > > interrupt as FIQ(GICv3) will be directly catched by EL3, not > S-EL1 > > > > > > > > > /* Route EL3 interrupts when in Secure and > Non-secure. > > > > */ > > > > > > > > > set_interrupt_rm_flag(flags, NON_SECURE); > > > > > > > > > set_interrupt_rm_flag(flags, SECURE); > > > > > > > > > > > > > > > > > > So this will conflict with OP-TEE, because OP-TEE needs catch > > > > > > > > > NS-interrupt as FIQ in S-EL1 world. > > > > > > > > > > > > > > > > In the case of GICv3, OP-TEE is configured to receive the > > > > > > > > non-secure interrupts as FIQ and secure interrupts as IRQ. See > > > > CFG_ARM_GICV3. > > > > > > > > > > > > > > But EHF needs NS-interrupt FIQ be catched by EL3 if I understand > > > > > > > correct, per " set_interrupt_rm_flag(flags, SECURE);" > > > > > > > > > > > > > > So currently EHF could not work together with OP-TEE, right? > > > > > > > > > > > > To be honest, I'm not completely sure what EHF does. From OP-TEE > > > > > > point of view we expect to receive the non-secure interrupts as a > > > > > > way of doing a controlled exit. This allows OP-TEE to resume > > > > > > execution with a different core on re-entry. If EL3 takes the > > > > > > non-secure interrupts directly it will have to make sure to only > re-enter > > > > OP-TEE on this core as a return from exception. > > > > > > > > > > Is this easy to be achieved? > > > > > > > > I don't know, it depends on what you intend to do with this non-secure > > > > interrupt. If it's handled at EL3 and then there's a return from exception > back > > > > to S-EL1 there's likely no harm done. But if there's a world switch > involved > > > > there might be trouble, OP-TEE might not be in a suitable state for a > world > > > > switch. > > > > > > > > > > > > > > Or by using opteed_sel1_interrupt_handler, could we have similar > > > > > behavior to allow the other core resume execution? > > > > > > > > Only OP-TEE itself can make a controlled exit as there's an internal state > to > > > > maintain. Currently that's signalled with a non-secure interrupt. > > > > > > > > > Per EHF, > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrustedfi… > andling.html?highlight=Exception%20Handling%20Framework > > > On GICv3 systems, when executing in S-EL1, pending Non-secure > interrupts of > > > sufficient priority are signalled as FIQs, and therefore will be routed to > EL3. > > > As a result, S-EL1 software cannot expect to handle Non-secure interrupts > at S-EL1. > > > Essentially, this deprecates the routing mode described as CSS=0, TEL3=0. > > > > > > In order for S-EL1 software to handle Non-secure interrupts while having > EHF enabled, > > > the dispatcher must adopt a model where Non-secure interrupts are > received at EL3, > > > but are then synchronously handled over to S-EL1. > > > > > > The issue to me here how to synchronously handled over to S-EL1 and not > break optee. > > > > I understand. OP-TEE is masking interrupts in some critical sections, > > while in such a state OP-TEE cannot handle any asynchronous interrupt. > > Temporarily masking interrupts is normally a quick operation so we do > > it in quite a few places. > > So the crux of the problem is to make sure that OP-TEE is in a state > > where it can make a controlled exit. I don't have any good ideas for > > this right now. > > > > Cheers, > > Jens > > > > -- > > TF-A mailing list > > TF-A(a)lists.trustedfirmware.org > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

5 years, 2 months

1
0
0 0

[PATCH 0/6] 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 v4 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/20210212154614.38604-1-sudeep.holl… [3] git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git v5.11/ffa Jens Wiklander (6): tee: add sec_world_id to struct tee_shm optee: simplify optee_release() optee: sync optee_msg.h and optee_rpc_cmd.h optee: refactor driver with internal callbacks optee: add a FF-A memory pool optee: add FF-A support drivers/tee/optee/call.c | 327 +++++++++++--- drivers/tee/optee/core.c | 698 +++++++++++++++++++++++++----- drivers/tee/optee/optee_ffa.h | 153 +++++++ drivers/tee/optee/optee_msg.h | 168 ++----- drivers/tee/optee/optee_private.h | 88 +++- drivers/tee/optee/optee_rpc_cmd.h | 333 ++++++++++++++ drivers/tee/optee/rpc.c | 169 +++++++- drivers/tee/optee/shm_pool.c | 65 ++- drivers/tee/optee/shm_pool.h | 1 + include/linux/tee_drv.h | 7 +- 10 files changed, 1685 insertions(+), 324 deletions(-) create mode 100644 drivers/tee/optee/optee_ffa.h create mode 100644 drivers/tee/optee/optee_rpc_cmd.h base-commit: 31ef391700953fb59ea8755ea38c6085bdec380e -- 2.25.1

5 years, 3 months

1
6
0 0

[PATCH] tee: optee: add invoke_fn tracepoints

by Jisheng Zhang

Add tracepoints to retrieve information about the invoke_fn. This would help to measure how many invoke_fn are triggered and how long it takes to complete one invoke_fn call. Signed-off-by: Jisheng Zhang <Jisheng.Zhang(a)synaptics.com> --- Since v1: - add BUILD_BUG_ON() macro usage to make sure that the size of what is being copied, is not smaller than the amount being copied. Thank Steve. - move optee_trace.h to keep include headers sorted drivers/tee/optee/call.c | 4 ++ drivers/tee/optee/optee_trace.h | 67 +++++++++++++++++++++++++++++++++ 2 files changed, 71 insertions(+) create mode 100644 drivers/tee/optee/optee_trace.h diff --git a/drivers/tee/optee/call.c b/drivers/tee/optee/call.c index 780d7c4fd756..0da6fe50f1af 100644 --- a/drivers/tee/optee/call.c +++ b/drivers/tee/optee/call.c @@ -14,6 +14,8 @@ #include <linux/uaccess.h> #include "optee_private.h" #include "optee_smc.h" +#define CREATE_TRACE_POINTS +#include "optee_trace.h" struct optee_call_waiter { struct list_head list_node; @@ -138,9 +140,11 @@ u32 optee_do_call_with_arg(struct tee_context *ctx, phys_addr_t parg) while (true) { struct arm_smccc_res res; + trace_optee_invoke_fn_begin(&param); optee->invoke_fn(param.a0, param.a1, param.a2, param.a3, param.a4, param.a5, param.a6, param.a7, &res); + trace_optee_invoke_fn_end(&param, &res); if (res.a0 == OPTEE_SMC_RETURN_ETHREAD_LIMIT) { /* diff --git a/drivers/tee/optee/optee_trace.h b/drivers/tee/optee/optee_trace.h new file mode 100644 index 000000000000..7c954eefa4bf --- /dev/null +++ b/drivers/tee/optee/optee_trace.h @@ -0,0 +1,67 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * optee trace points + * + * Copyright (C) 2021 Synaptics Incorporated + * Author: Jisheng Zhang <jszhang(a)kernel.org> + */ + +#undef TRACE_SYSTEM +#define TRACE_SYSTEM optee + +#if !defined(_TRACE_OPTEE_H) || defined(TRACE_HEADER_MULTI_READ) +#define _TRACE_OPTEE_H + +#include <linux/arm-smccc.h> +#include <linux/tracepoint.h> +#include "optee_private.h" + +TRACE_EVENT(optee_invoke_fn_begin, + TP_PROTO(struct optee_rpc_param *param), + TP_ARGS(param), + + TP_STRUCT__entry( + __field(void *, param) + __array(u32, args, 8) + ), + + TP_fast_assign( + __entry->param = param; + BUILD_BUG_ON(sizeof(*param) < sizeof(__entry->args)); + memcpy(__entry->args, param, sizeof(__entry->args)); + ), + + TP_printk("param=%p (%x, %x, %x, %x, %x, %x, %x, %x)", __entry->param, + __entry->args[0], __entry->args[1], __entry->args[2], + __entry->args[3], __entry->args[4], __entry->args[5], + __entry->args[6], __entry->args[7]) +); + +TRACE_EVENT(optee_invoke_fn_end, + TP_PROTO(struct optee_rpc_param *param, struct arm_smccc_res *res), + TP_ARGS(param, res), + + TP_STRUCT__entry( + __field(void *, param) + __array(unsigned long, rets, 4) + ), + + TP_fast_assign( + __entry->param = param; + BUILD_BUG_ON(sizeof(*res) < sizeof(__entry->rets)); + memcpy(__entry->rets, res, sizeof(__entry->rets)); + ), + + TP_printk("param=%p ret (%lx, %lx, %lx, %lx)", __entry->param, + __entry->rets[0], __entry->rets[1], __entry->rets[2], + __entry->rets[3]) +); +#endif /* _TRACE_OPTEE_H */ + +#undef TRACE_INCLUDE_PATH +#define TRACE_INCLUDE_PATH . +#undef TRACE_INCLUDE_FILE +#define TRACE_INCLUDE_FILE optee_trace + +/* This part must be outside protection */ +#include <trace/define_trace.h> -- 2.30.0

5 years, 3 months

4
11
0 0

Re: [PATCH] tee: optee: fix build error caused by recent optee tracepoints feature

by Guenter Roeck

On Thu, Mar 25, 2021 at 12:06:01PM +0800, Jisheng Zhang wrote: > If build kernel without "O=dir", below error will be seen: > > In file included from drivers/tee/optee/optee_trace.h:67, > from drivers/tee/optee/call.c:18: > ./include/trace/define_trace.h:95:42: fatal error: ./optee_trace.h: No such file or directory > 95 | #include TRACE_INCLUDE(TRACE_INCLUDE_FILE) > | ^ > compilation terminated. > > Fix it by adding below line to Makefile: > CFLAGS_call.o := -I$(src) > > Tested with and without "O=dir", both can build successfully. > > Reported-by: Guenter Roeck <linux(a)roeck-us.net> > Suggested-by: Steven Rostedt <rostedt(a)goodmis.org> > Signed-off-by: Jisheng Zhang <Jisheng.Zhang(a)synaptics.com> Tested-by: Guenter Roeck <linux(a)roeck-us.net> > --- > drivers/tee/optee/Makefile | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/tee/optee/Makefile b/drivers/tee/optee/Makefile > index 56263ae3b1d7..3aa33ea9e6a6 100644 > --- a/drivers/tee/optee/Makefile > +++ b/drivers/tee/optee/Makefile > @@ -6,3 +6,6 @@ optee-objs += rpc.o > optee-objs += supp.o > optee-objs += shm_pool.o > optee-objs += device.o > + > +# for tracing framework to find optee_trace.h > +CFLAGS_call.o := -I$(src) > -- > 2.31.0 >

5 years, 3 months

1
0
0 0

[GIT PULL] OP-TEE tracepoints for v5.13

by Jens Wiklander

Hello arm-soc maintainers, Please pull this patch adding tracepoints around calls to OP-TEE in secure world. Thanks, Jens The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15: Linux 5.12-rc2 (2021-03-05 17:33:41 -0800) are available in the Git repository at: git://git.linaro.org/people/jens.wiklander/linux-tee.git tags/optee-tracepoints-for-v5.13 for you to fetch changes up to 0101947dbcc3204f08fb5b69a21dbd4b1535cad6: tee: optee: add invoke_fn tracepoints (2021-03-15 12:04:01 +0100) ---------------------------------------------------------------- Add tracepoints around calls to secure world ---------------------------------------------------------------- Jisheng Zhang (1): tee: optee: add invoke_fn tracepoints drivers/tee/optee/call.c | 4 +++ drivers/tee/optee/optee_trace.h | 67 +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 71 insertions(+) create mode 100644 drivers/tee/optee/optee_trace.h

5 years, 3 months

2
1
0 0

Linaro OP-TEE Contributions meeting March 2021

by Joakim Bech

Hi, LOC monthly meeting is planned to take place Thursday March 25th(a)16.00 (UTC+1). Current topics on the agenda are: - RNG in OP-TEE: This was proposed by Jorge for Foundries.io who created a couple of patches in a pull request. However he's unable to continue working with that, but no matter it's a good discussion, so I've left it on the agenda. - OCALL: Then there has been a patch set / PR: OCALL pull request, Jerome wanted to discuss what the next steps are. There is most likely room for additional topics, so feel free to suggest. Meeting details: --------------- Date/time: Thursday March 25th(a)16.00 (UTC+1) https://everytimezone.com/s/3596d6d3 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

5 years, 3 months

1
1
0 0

Re: [TF-A] EHF + OPTEE on ARM64

by Sandeep Tripathy

Hi Peng, 1-Asynchronous preemption of SP: The long route is to make changes in the dispatcher and the corresponding SPD implementation to have synchronous preemption. ie: OP-TEE dispatcher will implement a G1NS (fiq) handler and invoke an entry of OP-TEE synchronously. OP-TEE will save the thread context and return. I did some POC but the complexity and effort to generalise was not justified by our requirement at that point especially envisioning the movement to SPMD in future. 2-Synchronous preemption of SP: ref: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/6345 I used this approach instead to unblock OP-TEE work alongside EHF. This serves the purpose without changing the routing model with a limitation that non yielding/fast SMC can not be preempted. And ofcourse OP-TEE can mask G0 interrupt in anycase. But I think this is sufficient for your purpose. Please feedback if the above patch works for you. Thanks Sandeep On Mon, Mar 22, 2021 at 2:43 PM Peng Fan via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > Hi Achin, > > > > We are using SDEI for Jailhouse hypervisor to minimize interrupt latency, however we also wanna use OP-TEE when SDEI enabled. > > > > So I wanna how to make both work together. > > > > Thanks, > > Peng. > > > > From: Achin Gupta [mailto:Achin.Gupta@arm.com] > Sent: 2021年3月17日 17:59 > To: Peng Fan <peng.fan(a)nxp.com>; Jens Wiklander <jens.wiklander(a)linaro.org> > Cc: op-tee(a)lists.trustedfirmware.org; tf-a(a)lists.trustedfirmware.org > Subject: Re: EHF + OPTEE on ARM64 > > > > Hi Peng, > > > > +TF-A folk. > > > > My 0.02$. > > > > What is the problem you are trying to solve? Why do you need to run OP-TEE and EHF together? EHF was originally written to support a S-EL0 SP that is managed directly by TF-A in EL3 (TF-A folk can chime in). > > > > The SP could perform RAS error handling for which it needs the EHF. The EHF triages asynchronous exceptions and hands RAS errors to the SP for further handling. > > > > This is just one use case but there is no Trusted OS in these configurations. > > > > So, it would help to understand the requirement. > > > > cheers, > > Achin > > > > ________________________________ > > From: OP-TEE <op-tee-bounces(a)lists.trustedfirmware.org> on behalf of Jens Wiklander via OP-TEE <op-tee(a)lists.trustedfirmware.org> > Sent: 17 March 2021 09:23 > To: Peng Fan <peng.fan(a)nxp.com> > Cc: op-tee(a)lists.trustedfirmware.org <op-tee(a)lists.trustedfirmware.org> > Subject: Re: EHF + OPTEE on ARM64 > > > > On Wed, Mar 17, 2021 at 9:43 AM Peng Fan <peng.fan(a)nxp.com> wrote: > > > > > Subject: Re: EHF + OPTEE on ARM64 > > > > > > On Wed, Mar 17, 2021 at 9:02 AM Peng Fan <peng.fan(a)nxp.com> wrote: > > > > > > > > > Subject: Re: EHF + OPTEE on ARM64 > > > > > > > > > > On Wed, Mar 17, 2021 at 8:41 AM Peng Fan <peng.fan(a)nxp.com> wrote: > > > > > > > > > > > > > Subject: Re: EHF + OPTEE on ARM64 > > > > > > > > > > > > > > On Tue, Mar 16, 2021 at 11:08 AM Peng Fan <peng.fan(a)nxp.com> > > > wrote: > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > In bl31/ehf.c, there are following two lines, per my > > > > > > > > understanding, when cpu is in secure world, the non-secure > > > > > > > > interrupt as FIQ(GICv3) will be directly catched by EL3, not S-EL1 > > > > > > > > /* Route EL3 interrupts when in Secure and Non-secure. > > > */ > > > > > > > > set_interrupt_rm_flag(flags, NON_SECURE); > > > > > > > > set_interrupt_rm_flag(flags, SECURE); > > > > > > > > > > > > > > > > So this will conflict with OP-TEE, because OP-TEE needs catch > > > > > > > > NS-interrupt as FIQ in S-EL1 world. > > > > > > > > > > > > > > In the case of GICv3, OP-TEE is configured to receive the > > > > > > > non-secure interrupts as FIQ and secure interrupts as IRQ. See > > > CFG_ARM_GICV3. > > > > > > > > > > > > But EHF needs NS-interrupt FIQ be catched by EL3 if I understand > > > > > > correct, per " set_interrupt_rm_flag(flags, SECURE);" > > > > > > > > > > > > So currently EHF could not work together with OP-TEE, right? > > > > > > > > > > To be honest, I'm not completely sure what EHF does. From OP-TEE > > > > > point of view we expect to receive the non-secure interrupts as a > > > > > way of doing a controlled exit. This allows OP-TEE to resume > > > > > execution with a different core on re-entry. If EL3 takes the > > > > > non-secure interrupts directly it will have to make sure to only re-enter > > > OP-TEE on this core as a return from exception. > > > > > > > > Is this easy to be achieved? > > > > > > I don't know, it depends on what you intend to do with this non-secure > > > interrupt. If it's handled at EL3 and then there's a return from exception back > > > to S-EL1 there's likely no harm done. But if there's a world switch involved > > > there might be trouble, OP-TEE might not be in a suitable state for a world > > > switch. > > > > > > > > > > > Or by using opteed_sel1_interrupt_handler, could we have similar > > > > behavior to allow the other core resume execution? > > > > > > Only OP-TEE itself can make a controlled exit as there's an internal state to > > > maintain. Currently that's signalled with a non-secure interrupt. > > > > > > Per EHF, https://trustedfirmware-a.readthedocs.io/en/latest/components/exception-han… > > On GICv3 systems, when executing in S-EL1, pending Non-secure interrupts of > > sufficient priority are signalled as FIQs, and therefore will be routed to EL3. > > As a result, S-EL1 software cannot expect to handle Non-secure interrupts at S-EL1. > > Essentially, this deprecates the routing mode described as CSS=0, TEL3=0. > > > > In order for S-EL1 software to handle Non-secure interrupts while having EHF enabled, > > the dispatcher must adopt a model where Non-secure interrupts are received at EL3, > > but are then synchronously handled over to S-EL1. > > > > The issue to me here how to synchronously handled over to S-EL1 and not break optee. > > I understand. OP-TEE is masking interrupts in some critical sections, > while in such a state OP-TEE cannot handle any asynchronous interrupt. > Temporarily masking interrupts is normally a quick operation so we do > it in quite a few places. > So the crux of the problem is to make sure that OP-TEE is in a state > where it can make a controlled exit. I don't have any good ideas for > this right now. > > Cheers, > Jens > > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 3 months

2
1
0 0

[PATCH 1/1] tee: optee: do not check memref size on return from Secure World

by Jerome Forissier

When Secure World returns, it may have changed the size attribute of the memory references passed as [in/out] parameters. The GlobalPlatform TEE Internal Core API specification does not restrict the values that this size can take. In particular, Secure World may increase the value to be larger than the size of the input buffer to indicate that it needs more. Therefore, the size check in optee_from_msg_param() is incorrect and needs to be removed. This fixes a number of failed test cases in the GlobalPlatform TEE Initial Configuratiom Test Suite v2_0_0_0-2017_06_09 when OP-TEE is compiled without dynamic shared memory support (CFG_CORE_DYN_SHM=n). Suggested-by: Jens Wiklander <jens.wiklander(a)linaro.org> Signed-off-by: Jerome Forissier <jerome(a)forissier.org> --- drivers/tee/optee/core.c | 10 ---------- 1 file changed, 10 deletions(-) diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c index 319a1e701163..ddb8f9ecf307 100644 --- a/drivers/tee/optee/core.c +++ b/drivers/tee/optee/core.c @@ -79,16 +79,6 @@ int optee_from_msg_param(struct tee_param *params, size_t num_params, return rc; p->u.memref.shm_offs = mp->u.tmem.buf_ptr - pa; p->u.memref.shm = shm; - - /* Check that the memref is covered by the shm object */ - if (p->u.memref.size) { - size_t o = p->u.memref.shm_offs + - p->u.memref.size - 1; - - rc = tee_shm_get_pa(shm, o, NULL); - if (rc) - return rc; - } break; case OPTEE_MSG_ATTR_TYPE_RMEM_INPUT: case OPTEE_MSG_ATTR_TYPE_RMEM_OUTPUT: -- 2.25.1

5 years, 3 months

1
0
0 0

Re: EHF + OPTEE on ARM64

by Achin Gupta

Hi Peng, +TF-A folk. My 0.02$. What is the problem you are trying to solve? Why do you need to run OP-TEE and EHF together? EHF was originally written to support a S-EL0 SP that is managed directly by TF-A in EL3 (TF-A folk can chime in). The SP could perform RAS error handling for which it needs the EHF. The EHF triages asynchronous exceptions and hands RAS errors to the SP for further handling. This is just one use case but there is no Trusted OS in these configurations. So, it would help to understand the requirement. cheers, Achin ________________________________ From: OP-TEE <op-tee-bounces(a)lists.trustedfirmware.org> on behalf of Jens Wiklander via OP-TEE <op-tee(a)lists.trustedfirmware.org> Sent: 17 March 2021 09:23 To: Peng Fan <peng.fan(a)nxp.com> Cc: op-tee(a)lists.trustedfirmware.org <op-tee(a)lists.trustedfirmware.org> Subject: Re: EHF + OPTEE on ARM64 On Wed, Mar 17, 2021 at 9:43 AM Peng Fan <peng.fan(a)nxp.com> wrote: > > > Subject: Re: EHF + OPTEE on ARM64 > > > > On Wed, Mar 17, 2021 at 9:02 AM Peng Fan <peng.fan(a)nxp.com> wrote: > > > > > > > Subject: Re: EHF + OPTEE on ARM64 > > > > > > > > On Wed, Mar 17, 2021 at 8:41 AM Peng Fan <peng.fan(a)nxp.com> wrote: > > > > > > > > > > > Subject: Re: EHF + OPTEE on ARM64 > > > > > > > > > > > > On Tue, Mar 16, 2021 at 11:08 AM Peng Fan <peng.fan(a)nxp.com> > > wrote: > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > In bl31/ehf.c, there are following two lines, per my > > > > > > > understanding, when cpu is in secure world, the non-secure > > > > > > > interrupt as FIQ(GICv3) will be directly catched by EL3, not S-EL1 > > > > > > > /* Route EL3 interrupts when in Secure and Non-secure. > > */ > > > > > > > set_interrupt_rm_flag(flags, NON_SECURE); > > > > > > > set_interrupt_rm_flag(flags, SECURE); > > > > > > > > > > > > > > So this will conflict with OP-TEE, because OP-TEE needs catch > > > > > > > NS-interrupt as FIQ in S-EL1 world. > > > > > > > > > > > > In the case of GICv3, OP-TEE is configured to receive the > > > > > > non-secure interrupts as FIQ and secure interrupts as IRQ. See > > CFG_ARM_GICV3. > > > > > > > > > > But EHF needs NS-interrupt FIQ be catched by EL3 if I understand > > > > > correct, per " set_interrupt_rm_flag(flags, SECURE);" > > > > > > > > > > So currently EHF could not work together with OP-TEE, right? > > > > > > > > To be honest, I'm not completely sure what EHF does. From OP-TEE > > > > point of view we expect to receive the non-secure interrupts as a > > > > way of doing a controlled exit. This allows OP-TEE to resume > > > > execution with a different core on re-entry. If EL3 takes the > > > > non-secure interrupts directly it will have to make sure to only re-enter > > OP-TEE on this core as a return from exception. > > > > > > Is this easy to be achieved? > > > > I don't know, it depends on what you intend to do with this non-secure > > interrupt. If it's handled at EL3 and then there's a return from exception back > > to S-EL1 there's likely no harm done. But if there's a world switch involved > > there might be trouble, OP-TEE might not be in a suitable state for a world > > switch. > > > > > > > > Or by using opteed_sel1_interrupt_handler, could we have similar > > > behavior to allow the other core resume execution? > > > > Only OP-TEE itself can make a controlled exit as there's an internal state to > > maintain. Currently that's signalled with a non-secure interrupt. > > > Per EHF, https://trustedfirmware-a.readthedocs.io/en/latest/components/exception-han… > On GICv3 systems, when executing in S-EL1, pending Non-secure interrupts of > sufficient priority are signalled as FIQs, and therefore will be routed to EL3. > As a result, S-EL1 software cannot expect to handle Non-secure interrupts at S-EL1. > Essentially, this deprecates the routing mode described as CSS=0, TEL3=0. > > In order for S-EL1 software to handle Non-secure interrupts while having EHF enabled, > the dispatcher must adopt a model where Non-secure interrupts are received at EL3, > but are then synchronously handled over to S-EL1. > > The issue to me here how to synchronously handled over to S-EL1 and not break optee. I understand. OP-TEE is masking interrupts in some critical sections, while in such a state OP-TEE cannot handle any asynchronous interrupt. Temporarily masking interrupts is normally a quick operation so we do it in quite a few places. So the crux of the problem is to make sure that OP-TEE is in a state where it can make a controlled exit. I don't have any good ideas for this right now. Cheers, Jens

5 years, 3 months

2
1
0 0

[PATCH] optee: enable apci support

by Ran Wang

This patch add ACPI support for optee driver. Signed-off-by: Ran Wang <ran.wang_1(a)nxp.com> --- drivers/tee/optee/core.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c index cf4718c6d35d..8fb261f4b9db 100644 --- a/drivers/tee/optee/core.c +++ b/drivers/tee/optee/core.c @@ -5,6 +5,7 @@ #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt +#include <linux/acpi.h> #include <linux/arm-smccc.h> #include <linux/errno.h> #include <linux/io.h> @@ -735,12 +736,21 @@ static const struct of_device_id optee_dt_match[] = { }; MODULE_DEVICE_TABLE(of, optee_dt_match); +#ifdef CONFIG_ACPI +static const struct acpi_device_id optee_acpi_match[] = { + { "OPTEE01",}, + { }, +}; +MODULE_DEVICE_TABLE(acpi, dwc3_acpi_match); +#endif + static struct platform_driver optee_driver = { .probe = optee_probe, .remove = optee_remove, .driver = { .name = "optee", .of_match_table = optee_dt_match, + .acpi_match_table = ACPI_PTR(optee_acpi_match), }, }; module_platform_driver(optee_driver); -- 2.25.1

5 years, 3 months

3
5
0 0

EHF + OPTEE on ARM64

by Peng Fan

Hi, In bl31/ehf.c, there are following two lines, per my understanding, when cpu is in secure world, the non-secure interrupt as FIQ(GICv3) will be directly catched by EL3, not S-EL1 /* Route EL3 interrupts when in Secure and Non-secure. */ set_interrupt_rm_flag(flags, NON_SECURE); set_interrupt_rm_flag(flags, SECURE); So this will conflict with OP-TEE, because OP-TEE needs catch NS-interrupt as FIQ in S-EL1 world. Am I understand correct? Any ideas how we could address this to make EHF + OPTEE run together? Thanks Peng.

5 years, 3 months

2
7
0 0

Re: EHF + OPTEE on ARM64

by Jelle Sels

Hi, If I am not mistaking, the fiq handler should be opteed_sel1_interrupt_handler which will forward the interrupt to S-EL1. R, Jelle ________________________________________ From: OP-TEE <op-tee-bounces(a)lists.trustedfirmware.org> on behalf of Peng Fan via OP-TEE <op-tee(a)lists.trustedfirmware.org> Sent: Tuesday, March 16, 2021 11:08 To: op-tee(a)lists.trustedfirmware.org; Jens Wiklander; Joakim Bech Subject: EHF + OPTEE on ARM64 Hi, In bl31/ehf.c, there are following two lines, per my understanding, when cpu is in secure world, the non-secure interrupt as FIQ(GICv3) will be directly catched by EL3, not S-EL1 /* Route EL3 interrupts when in Secure and Non-secure. */ set_interrupt_rm_flag(flags, NON_SECURE); set_interrupt_rm_flag(flags, SECURE); So this will conflict with OP-TEE, because OP-TEE needs catch NS-interrupt as FIQ in S-EL1 world. Am I understand correct? Any ideas how we could address this to make EHF + OPTEE run together? Thanks Peng.

5 years, 3 months

1
0
0 0

[PATCH] drivers: tee: optee: removed repeated words in comments

by Anupama K Patil

the word "the" is repeated in the file core.c so it has been removed. Likewise the word "of" is repeated in optee_smc.h and have removed it. Signed-off-by: Anupama K Patil <anupamakpatil123(a)gmail.com> --- drivers/tee/optee/core.c | 2 +- drivers/tee/optee/optee_smc.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c index cf4718c6d35d..2ccb091cd643 100644 --- a/drivers/tee/optee/core.c +++ b/drivers/tee/optee/core.c @@ -422,7 +422,7 @@ static bool optee_msg_exchange_capabilities(optee_invoke_fn *invoke_fn, /* * TODO This isn't enough to tell if it's UP system (from kernel - * point of view) or not, is_smp() returns the the information + * point of view) or not, is_smp() returns the information * needed, but can't be called directly from here. */ if (!IS_ENABLED(CONFIG_SMP) || nr_cpu_ids == 1) diff --git a/drivers/tee/optee/optee_smc.h b/drivers/tee/optee/optee_smc.h index 80eb763a8a80..49e8e027dc5b 100644 --- a/drivers/tee/optee/optee_smc.h +++ b/drivers/tee/optee/optee_smc.h @@ -162,7 +162,7 @@ struct optee_smc_call_get_os_revision_result { * Have config return register usage: * a0 OPTEE_SMC_RETURN_OK * a1 Physical address of start of SHM - * a2 Size of of SHM + * a2 Size of SHM * a3 Cache settings of memory, as defined by the * OPTEE_SMC_SHM_* values above * a4-7 Preserved -- 2.25.1

5 years, 3 months

1
0
0 0

Re: Request for support opensource optee contribution guide line

by Jens Wiklander

Hi Raghu, On Wed, Mar 3, 2021 at 8:38 AM Yejerla, VeeraraghavuluX via OP-TEE <op-tee(a)lists.trustedfirmware.org> wrote: > > Dear Sir, > > I would like to know that, if I want submit any patch for optee opensource features, could please guide me what are the guide line I have to follow it. Below are some information require . > > > 1. What is the maximum patch size shall I submit? That depends, it might be good to start with something small as a first contribution. > 2. What are the code guide line I have to follow it? https://optee.readthedocs.io/en/latest/general/coding_standards.html > 3. What are mail chain I have to include for patch review purpose? > 4. Is there any open source link for post quarry ? See https://optee.readthedocs.io/en/latest/general/contribute.html Cheers, Jens

5 years, 3 months

1
0
0 0

Re: Linaro OP-TEE Contributions meeting February 2021

by Jens Wiklander

Hi, On Fri, Feb 26, 2021 at 9:50 AM Jérôme Forissier via OP-TEE <op-tee(a)lists.trustedfirmware.org> wrote: > > Hi, > > On Thu, Feb 25, 2021 at 9:41 AM Joakim Bech via OP-TEE < > op-tee(a)lists.trustedfirmware.org> wrote: > > > Hi Jorge, > > > > On Wed, 24 Feb 2021 at 18:14, Jorge Ramirez <jorge(a)foundries.io> wrote: > > > > > Sorry Joakim. > > > I guess it is too late now but It would have been good to talk about the > > > TEE strategy/direction with RNG. > > > 1) how often do we seed the PRNG. > > > 2) should we always use PRNG and only use HWRNG to seed if with a certain > > > cadence. > > > 3) how do we measure the quality of an RNG in OPTEE (how do we guarantee > > > no regressions) > > > this would be really an open discussion more than anything else (unless > > > there is a matematician amongst us) > > > > > Yes, good suggestions. I'll add it to the next meeting (March 25:th). > > > > And now that I think of it... there is this big OCALL contribution that has > been mostly stalled for months... > https://github.com/OP-TEE/optee_os/pull/3673 > We should discuss what to do with it. Yes, the kernel part is the hard part here. Cheers, Jens

5 years, 3 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

OP-TEE