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

[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

[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

Preparing for OP-TEE 3.14.0

by Jerome Forissier

[CC all OP-TEE maintainers] Hi OP-TEE maintainers & contributors, OP-TEE v3.14.0 is scheduled to be released on 2021-07-16. So, now is a good time to start testing the master branch on the various platforms and report/fix any bugs. The GitHub pull request for collecting Tested-by tags or any other comments is https://github.com/OP-TEE/optee_os/pull/4704. As usual, we will create a release candidate tag one week before the release date for final testing. In addition to that you can find some additional information related to releases here: https://optee.readthedocs.io/en/latest/general/releases.html Regards, -- Jerome

3 years, 4 months

1
1
0 0

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

by Jens Wiklander

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

3 years, 4 months

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

3 years, 5 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(+)

3 years, 5 months

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

3 years, 5 months

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

3 years, 5 months

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

3 years, 5 months

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

3 years, 5 months

4
20
0 0

2024

2023

2022

2021

2020

OP-TEE June 2021