July 2021 - OP-TEE - lists.trustedfirmware.org

[PATCH v3 0/6] Asynchronous notifications from secure world

by Jens Wiklander

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

3 years

3
12
0 0

[GIT PULL] TEE kexec fixes for v5.14

by Jens Wiklander

Hello arm-soc maintainers, Please pull these fixes relating to OP-TEE, ftpm (firmware TPM), and tee_bnxt_fw (Broadcom BNXT firmware manager) drivers in kexec and kdump (emergency kexec) based workflows. The two patches "firmware: tee_bnxt: Release TEE shm, session, and context during kexec" and "tpm_ftpm_tee: Free and unregister TEE shared memory during kexec" are acked by their respective maintainers. For more details please see the description of the last patch set https://lore.kernel.org/lkml/20210614223317.999867-1-tyhicks@linux.microsof… Thanks, Jens The following changes since commit 2734d6c1b1a089fb593ef6a23d4b70903526fe0c: Linux 5.14-rc2 (2021-07-18 14:13:49 -0700) are available in the Git repository at: git://git.linaro.org:/people/jens.wiklander/linux-tee.git tags/tee-kexec-fixes-for-v5.14 for you to fetch changes up to 914ab19e471d8fb535ed50dff108b0a615f3c2d8: firmware: tee_bnxt: Release TEE shm, session, and context during kexec (2021-07-21 07:55:50 +0200) ---------------------------------------------------------------- tee: Improve support for kexec and kdump This fixes several bugs uncovered while exercising the OP-TEE, ftpm (firmware TPM), and tee_bnxt_fw (Broadcom BNXT firmware manager) drivers with kexec and kdump (emergency kexec) based workflows. ---------------------------------------------------------------- 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() Sumit Garg (1): tee: Correct inappropriate usage of TEE_SHM_DMA_BUF flag Tyler Hicks (4): 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 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 | 38 ++++++++++++++++++++++++++--- drivers/tee/optee/core.c | 43 ++++++++++++++++++++++++++++++++- drivers/tee/optee/optee_private.h | 1 + drivers/tee/optee/rpc.c | 5 ++-- drivers/tee/optee/shm_pool.c | 20 ++++++++++++--- drivers/tee/tee_shm.c | 20 ++++++++++++++- include/linux/tee_drv.h | 2 ++ 9 files changed, 132 insertions(+), 19 deletions(-)

3 years, 3 months

2
1
0 0

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

by Jens Wiklander

Hi all, This adds supports for the OP-TEE driver to communicate with secure world using FF-A [1] as transport. 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. The functions relating to the SMC based ABI are moved to smc_abi.c while the FF-A based ABI is added in a ffa_abi.c. 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. Note that it's only the old SMC based driver instance that need device tree or ACPI to initialize. The FF-A based driver relies on the FF-A bus instead. This can be tested QEMU The repo for SPMC at S-EL1 retrieved by repo init -u https://github.com/jenswi-linaro/manifest.git -m qemu_v8.xml -b ffav4_spmc repo sync # Then checkout the branch optee_ffa_v3 from # git://git.linaro.org/people/jens.wiklander/linux-tee.git # in the linux directory To build do: cd build make toolchains make all To boot: make run-only Test with xtest, perhaps only with the command "xtest 1004" in case you're not interested in too many tests. Thanks, Jens [1] https://developer.arm.com/documentation/den0077/latest v2->v3: - Rebased on 5.14-rc2 which now have the FF-A patches merged - Fixed a couple bugs in optee_shm_register() and optee_shm_unregister() which where introduced in "optee: refactor driver with internal callbacks" in previous the version. - Separated SMC ABI specifics into smc_abi.c to keep it separated from the FF-A ABI functions as requested by Sumit. - Added the FF-A specifics in ffa_abi.c - Provided an implementation for optee_ffa_remove() v1->v2: - Rebased to the FF-A v7 patch - Fixed a couple of reports from kernel test robot <lkp(a)intel.com> Jens Wiklander (5): tee: add sec_world_id to struct tee_shm optee: simplify optee_release() optee: refactor driver with internal callbacks optee: isolate smc abi optee: add FF-A support drivers/tee/optee/Makefile | 7 +- drivers/tee/optee/call.c | 415 ++------- drivers/tee/optee/core.c | 673 ++------------- drivers/tee/optee/ffa_abi.c | 910 ++++++++++++++++++++ drivers/tee/optee/optee_ffa.h | 153 ++++ drivers/tee/optee/optee_msg.h | 27 +- drivers/tee/optee/optee_private.h | 155 +++- drivers/tee/optee/rpc.c | 270 +----- drivers/tee/optee/shm_pool.c | 89 -- drivers/tee/optee/shm_pool.h | 14 - drivers/tee/optee/smc_abi.c | 1301 +++++++++++++++++++++++++++++ include/linux/tee_drv.h | 7 +- 12 files changed, 2650 insertions(+), 1371 deletions(-) create mode 100644 drivers/tee/optee/ffa_abi.c create mode 100644 drivers/tee/optee/optee_ffa.h delete mode 100644 drivers/tee/optee/shm_pool.c delete mode 100644 drivers/tee/optee/shm_pool.h create mode 100644 drivers/tee/optee/smc_abi.c -- 2.31.1

3 years, 3 months

3
21
0 0

LOC Monthly Meeting - Thursday July 22

by Ruchika Gupta

Hi, LOC (Linaro OP-TEE Contribution) monthly meeting is planned to take place on Thursday July22(a)17.00 (UTC+2). Looking for topics from people. If you have anything you'd like to discuss, please let us know. Meeting details: --------------- Date/time: Thursday Jul22(a)17.00 (UTC+2) https://everytimezone.com/s/d926310d Connection details: https://www.trustedfirmware.org/meetings/ Meeting notes: http://bit.ly/loc-notes Regards, Ruchika on behalf of the Linaro OP-TEE team

3 years, 4 months

1
1
0 0

Question about OP-TEE

by 최호진

Dear. Linaro hello! my name is Hojin-Choi from Korea Univ in Korea I have a question about optee currently werun optee with virtual machine. Although we modify 'Makefile' in 'build' folder for changing cortex a-15 to cortex-a9 in optee, it give error message which "cortex-a9's support machines 'xilinx-zynq-a9, vexpress-a9, realview-pbx-a9, sabrelite' do not support secure". How can we fix the error or any other methods to run cortex-a9 with trustzone? best.

3 years, 4 months

1
0
0 0

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

by Tyler Hicks

v5: - Picked up Reviewed-by's from Jens. - Added 'Cc: stable(a)vger.kernel.org' to all commits as this is intended to be a bug fix series. I'm happy to sort out backports with the stable team. - Got rid of the bool is_mapped parameter of optee_disable_shm_cache() by abstracting out the function with two wrappers. One (optee_disable_shm_cache()) for normal case where the shm cache is fully mapped and another (optee_disable_unmapped_shm_cache()) for the unusual case of the shm cache having potentially invalid entries. - Replaced my previous 'tee: Support kernel shm registration without dma-buf' patch with a cleaner implementation ('tee: Correct inappropriate usage of TEE_SHM_DMA_BUF flag') from Sumit Garg. v4: https://lore.kernel.org/lkml/20210610210913.536081-1-tyhicks@linux.microsof… 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() Sumit Garg (1): tee: Correct inappropriate usage of TEE_SHM_DMA_BUF flag Tyler Hicks (4): 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 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 | 38 +++++++++++++++++++--- drivers/tee/optee/core.c | 43 ++++++++++++++++++++++++- drivers/tee/optee/optee_private.h | 1 + drivers/tee/optee/rpc.c | 5 +-- drivers/tee/optee/shm_pool.c | 20 +++++++++--- drivers/tee/tee_shm.c | 20 +++++++++++- include/linux/tee_drv.h | 2 ++ 9 files changed, 132 insertions(+), 19 deletions(-) -- 2.25.1

3 years, 4 months

4
16
0 0

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

by Vikas Gupta

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

3 years, 4 months

4
5
0 0

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

by Etienne CARRIERE

Hello Sudeep and all, On Wed, 7 Jul 2021 at 19:52, Sudeep Holla <sudeep.holla(a)arm.com> wrote: > > Hi Sumit, > > I was holding off you reply as I didn't have all the background on this. > Achin did mention that this is preparatory work for FFA notifications. > I did mention to him that this is more than that, it is custom extension > to address what FF-A notification is trying to in standard way. > > I share same opinion as Marc Z. > > On Wed, Jul 07, 2021 at 11:22:23AM +0530, Sumit Garg wrote: > > On Tue, 6 Jul 2021 at 18:16, Marc Zyngier <maz(a)kernel.org> wrote: > > [...] > > > > > > > I don't care about OP-TEE. If you are proposing a contract between S > > > and NS, it has to be TEE and OS independent. That's how the > > > architecture works. > > > > > > > Agree, here we are not proposing a common contract among the S and NS > > world that every TEE (based on Arm TrustZone) will use to communicate > > with REE (Linux in our case) but rather an OP-TEE specific > > notifications feature that is built on top of OP-TEE specific ABIs. > > > > And I can see your arguments coming from an FFA perspective but there > > are platforms like the ones based on Armv7 which don't support FFA > > ABI. Maybe Jens can elaborate how this feature will fit in when FFA > > comes into picture? > > > > I can understand that but won't those platforms add the support both in > the kernel(current series) and secure world to address notifications. > While you could argue that it is small extension to what is already present > but I prefer they support FF-A is they need such a support instead of adding > custom mechanisms. It is hard to maintain and each vendor will deviate > from this custom mechanism and soon we will have bunch of them to handle. There exist armv7-a platforms that expect OP-TEE notification support and will not move the FF-A, like the stm32mp15. This platform won't move to FF-A mainly due to the memory cost of the added SPM layer and the device physical constraints. We have a usecase for OP-TEE notification. We're working on the integration of an SCMI server in OP-TEE. SCMI notification is a feature needed is this scope and it requires OP-TEE async notification means as those proposed here. This OP-TEE async notif also brings a lot of value in OP-TEE as it allows a OP-TEE secure thread (i.e. executing a trusted application service) to gently wait on a secure interrupt (as a slow bus transaction completion or many other usecase) with the CPU relaxed. This support is provided by the proposed series. I believe existing device should be able to leverage this OP-TEE feature without needing their OP-TEE to move to the new FF-A interface. Regards, Etienne > > [...] ST Restricted

3 years, 4 months

3
4
0 0

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

by Jens Wiklander

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

3 years, 4 months

2
7
0 0

OP-TEE SKS

by Rafael Gameiro

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

3 years, 4 months

1
0
0 0

2024

2023

2022

2021

2020

OP-TEE July 2021