[RFC] SCMI PTA with OCALL #90
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Adds upstream-tee-subsys-patches.txt describing all upstream patches related to the TEE subsystem. Signed-off-by: Jens Wiklander <[email protected]> [jf: rebase on top of v4.18] Signed-off-by: Jerome Forissier <[email protected]>
This change allows userland to create a tee_shm object that refers to a dmabuf reference. Userland provides a dmabuf file descriptor as buffer reference. The created tee_shm object exported as a brand new dmabuf reference used to provide a clean fd to userland. Userland shall closed this new fd to release the tee_shm object resources. The initial dmabuf resources are tracked independently through original dmabuf file descriptor. Once the buffer is registered and until it is released, TEE driver keeps a refcount on the registered dmabuf structure. This change only support dmabuf references that relates to physically contiguous memory buffers. New tee_shm flag to identify tee_shm objects built from a registered dmabuf: TEE_SHM_EXT_DMA_BUF. Such tee_shm structures are flagged both TEE_SHM_DMA_BUF and TEE_SHM_EXT_DMA_BUF. Signed-off-by: Etienne Carriere <[email protected]> Reviewed-by: Jens Wiklander <[email protected]> [jf: squash fixup commit ("tee: fix unbalanced context refcount in register shm from fd")] [jf: rebase onto v5.9-rc8] Signed-off-by: Jerome Forissier <[email protected]>
From the commit below, the mt8173-evb failed to boot to console due to changes in the mt8173 device tree files. commit c0d6fe2 Merge: b44a3d2 3e4dda7 Author: Linus Torvalds <[email protected]> Date: Tue Nov 10 15:06:26 2015 -0800 Merge tag 'armsoc-dt' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc Until properly solved, let's just remove the section in the device tree blob that causes this. Signed-off-by: Joakim Bech <[email protected]> Reviewed-by: Pascal Brand <[email protected]>
Configures foundation-v8 with OP-TEE. Signed-off-by: Jens Wiklander <[email protected]> [jf: rebase onto v5.9-rc7] Signed-off-by: Jerome Forissier <[email protected]>
Configures Juno with OP-TEE. Reviewed-by: Pascal Brand <[email protected]> Signed-off-by: Jens Wiklander <[email protected]> [jf: rebase onto v5.9-rc7] Signed-off-by: Jerome Forissier <[email protected]>
…dation-v8 **not for mainline** All the platforms that reserve memory for OP-TEE statically via the DT (i.e., not those that reserve it via UEFI or that patch the DT dynamically thanks to OP-TEE's CFG_DT option) have to mark it 'no-map' so that only the TEE driver may map it. Signed-off-by: Jens Wiklander <[email protected]>
… **not for mainline** All the platforms that reserve memory for OP-TEE statically via the DT (i.e., not those that reserve it via UEFI or that patch the DT dynamically thanks to OP-TEE's CFG_DT option) have to mark it 'no-map' so that only the TEE driver may map it. Signed-off-by: Jens Wiklander <[email protected]>
Signed-off-by: Joakim Bech <[email protected]> Reviewed-by: Pascal Brand <[email protected]> Reviewed-by: Jerome Forissier <[email protected]>
Add Benchmark support Reviewed-by: Joakim Bech <[email protected]> Signed-off-by: Igor Opaniuk <[email protected]> [jf: squash fixup commit "tee: optee: optee_bench.h: remove useless include **not for mainline**"] [jf: rebase onto v5.9-rc7] Signed-off-by: Jerome Forissier <[email protected]>
Add support of allocating DMA shared buffers via RPC calls. The main difference with OPTEE_MSG_RPC_SHM_TYPE_KERNEL is that SHM pool manager for shared memory exported to user space is explicitly chosen. As dma-buf is used for exporting buffers to userspace, it provides a possiblity to mmap an allocated SHM buffer into multiple TEE client applications (unlike OPTEE_MSG_RPC_SHM_TYPE_APPL, which leverages tee-supplicant for private allocations). Such buffers should be used only for internal purposes, when there is a need to share meta data between different OP-TEE components (for debugging/profiling purposes). Signed-off-by: Igor Opaniuk <[email protected]> [jf: squash fixup commit] Signed-off-by: Jerome Forissier <[email protected]>
Records patches available upstream up to v4.20-rc1. Acked-by: Joakim Bech <[email protected]> Signed-off-by: Jens Wiklander <[email protected]>
Records patches available upstream up to v5.0. Signed-off-by: Jerome Forissier <[email protected]>
Records patches available upstream up to v5.1. Signed-off-by: Jerome Forissier <[email protected]>
Dumped from: https://github.com/loboris/OrangePI-Kernel/tree/master/linux-3.4 0cc8d855adb457d1860d6e25cb93b6cc75d5a09d Author: Sunny <[email protected]> for Allwinner. Changes made on original "secure heap" implementation: - minor coding style: fix includes, empty lines and overlong lines, indentation, comment layout. - Original path modified the ion uapi. We do not attempt to modify uapi/ion.h. "secure" (or "domain") heaps are under ID ION_HEAP_TYPE_CUSTOM + 1 (legacy 'secure heap type' value). Signed-off-by: Etienne Carriere <[email protected]>
OP-TEE/SDP (Secure Data Path) memory pools are created through ION secure type heap" from Allwinner. This change renames "secure" into "unmapped" as, from Linux point of view, the heap constraint is manipulating unampped memory pools/buffers. "Unmapped" heap support is integrated in ION UAPI (actually this was the Allwinner initial proposal) and ION DT parsing support. Based in work from Sunny <[email protected]> for Allwinner. Changes: - rename "secure_heap" into "unmapped_heap" - define ION_HEAP_TYPE_UNMAPPED in ION UAPI (sic!) - add structure "struct unmapped_buffer_priv" to hold allocated buffer private data (currently only the buffer physical address. - adapt to recent ION (i.e ion_phys_addr_t => phys_addr_t) - Support dummy heap configuration: one can hard code into the Linux kernel configuration the location of a "unmapped heap". It will be created during ION device inits: see CONFIG_ION_DUMMY_UNMAPPED_HEAP. Signed-off-by: Etienne Carriere <[email protected]>
Condition ION unmapped heap implementation to architectures that currently support it. ARM is one of these. Signed-off-by: Etienne Carriere <[email protected]> Reviewed-by: Joakim Bech <[email protected]>
Signed-off-by: Etienne Carriere <[email protected]>
Ion unmapped heap aims at not being mapped. This change prevents Ion from calling dma-mapping support on dma_buf_attach for buffers in an unmapped heap. This change is a bit intrusive in the Ion driver. Maybe there is another way to deal with the dma-mapping resources used for the unmapped heap. Signed-off-by: Etienne Carriere <[email protected]> [jf: rebase onto v5.9-rc7] Signed-off-by: Jerome Forissier <[email protected]>
Since commit 54ef5b9 (staging: android: ion: Initialize dma_address of new sg list") (Linux v4.17), the helper function dup_sg_table() called by ion_dma_buf_attach() does not preserve the dma_address from the original SG list. It is a problem for the unmapped heap, because dma_buf_attach() followed by dma_buf_map_attachment() now returns a SG table with NULL dma_address, which breaks tee_shm_register_fd(). This commit avoids the dma_address reset for the unmapped heap. Signed-off-by: Jerome Forissier <[email protected]> Tested-by: Jerome Forissier <[email protected]> (HiKey960, SDP) Tested-by: Etienne Carriere <[email protected]> (Qemu_v7/v8, SDP)
Records patches available upstream up to v5.4-rc7. Signed-off-by: Jerome Forissier <[email protected]>
Records patches available upstream up to v5.5. Signed-off-by: Jerome Forissier <[email protected]>
TEE Client introduce a new capability "TEE_GEN_CAP_MEMREF_NULL" to handle the support of the shared memory buffer with a NULL pointer. This capability depends on TEE Capabilities and driver support. Driver and TEE exchange capabilities at driver initialization. Signed-off-by: Michael Whitfield <[email protected]> Signed-off-by: Cedric Neveux <[email protected]> Reviewed-by: Jens Wiklander <[email protected]> Reviewed-by: Joakim Bech <[email protected]> Tested-by: Joakim Bech <[email protected]> (QEMU)
Reserve memory for bootloader purposes. Acked-by: Jerome Forissier <[email protected]> Signed-off-by: Igor Opaniuk <[email protected]>
Add optee node, so OP-TEE driver is probed properly. Acked-by: Jerome Forissier <[email protected]> Signed-off-by: Igor Opaniuk <[email protected]>
Define OP-TEE firmware node for stm32mp15 based platforms. The node if disable by default. Enable the OP-TEE node and define OP-TEE reserved memory for stm32mp157c-dk2. Signed-off-by: Etienne Carriere <[email protected]> [jf: rebase onto v5.9] Signed-off-by: Jerome Forissier <[email protected]>
Records patches available upstream up to v5.9. Signed-off-by: Jerome Forissier <[email protected]>
Since the addition of session's client UUID generation via commit [1], login via REE kernel method was disallowed. So fix that via passing nill UUID in case of TEE_IOCTL_LOGIN_REE_KERNEL method as well. Fixes: e33bcba ("tee: add support for session's client UUID generation") [1] Signed-off-by: Sumit Garg <[email protected]> Signed-off-by: Jens Wiklander <[email protected]>
Kconfig allows to customize the CONFIG_ prefix via the $CONFIG_ environment variable. Out-of-tree projects may therefore use Kconfig with a different prefix, or they may use a custom configuration tool which does not use the CONFIG_ prefix at all. Such projects may still want to adhere to the Linux kernel coding style and run checkpatch.pl. One example is OP-TEE [1] which does not use Kconfig but does have configuration options prefixed with CFG_. It also mostly follows the kernel coding style and therefore being able to use checkpatch is quite valuable. To make this possible, add the --kconfig-prefix command line option. [1] https://github.com/OP-TEE/optee_os Signed-off-by: Jerome Forissier <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Acked-by: Joe Perches <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]> [jf: commit 3e89ad8 from upstream] Signed-off-by: Jerome Forissier <[email protected]>
The ID for commit b83685b ("tee: amdtee: fix memory leak in amdtee_open_session()") is wrong in upstream-tee-subsys-patches.txt. Fix it. Reported-by: Victor Chong <[email protected]> Signed-off-by: Jerome Forissier <[email protected]>
Signed-off-by: Javier Almansa Sobrino <[email protected]> Acked-by: Joakim Bech <[email protected]> Link: linaro-swg#85 [jf: not currently intended for upstream; add link to PR] Signed-off-by: Jerome Forissier <[email protected]>
The optee device status is disabled by default, change its status to 'okay' in the dts of the EV1 board Signed-off-by: Timothée Cercueil <[email protected]>
Move the call queue handling logic off to a new file to allow for its use in other translation units cleanly. Signed-off-by: Hernan Gatta <[email protected]> Acked-by: Etienne Carriere <[email protected]>
Supporting OCALLs, where a TA may request a function invocation on its Client Application (CA), requires that the secure thread requesting the OCALL be temporarily suspended as a result of performing an RPC to send the OCALL request to normal world. A possible OCALL request is one where the TA requests that the CA allocate shared memory in order to pass large buffers as part of the function invocation. When this happens, the request is routed to the CA. Normally, this would result in another entry into secure world to register that shared memory, if OP-TEE supports it. This re-entry would block, however, if OP-TEE only has one thread available. To avoid this problem, the TEE supplicant readily supports registering shared memory only with the driver, and passing the necessary information back to OP-TEE via RPC parameters instead. This change introduces the TEE_IOCTL_SHM_OCALL flag. When used, the call into OP-TEE to register shared memory is not performed, nor is its corresponding free. It is up to the OCALL implementation to properly deal with reference counting. Signed-off-by: Hernan Gatta <[email protected]> Reviewed-by: Jens Wiklander <[email protected]>
Add a new generic capability to denote support for OCALLs in secure world: TEE_GEN_CAP_OCALL. Additionally, support detection of this capability in OP-TEE. Signed-off-by: Hernan Gatta <[email protected]> Reviewed-by: Jens Wiklander <[email protected]> Acked-by: Etienne Carriere <[email protected]>
At times, it may be useful to allow a caller to increase the reference count on a shared memory (SHM) object at will. This patch adds tee_shm_get, the increasing counterpart to tee_shm_put. Signed-off-by: Hernan Gatta <[email protected]> Reviewed-by: Jens Wiklander <[email protected]> Acked-by: Etienne Carriere <[email protected]>
Enable Trusted Applications (TAs) to invoke functions on their corresponding Client Application (CA), both during session open and function invocation. These function invocations from TA to CA are referred to as "Out Calls", or OCALLs for short. The fundamental mechanism is one whereby upon a function invocation from the CA to the TA, the TEE returns prematurely from the invocation with an RPC. This RPC is generated after a TA calls the TEEC_InvokeCommand equivalent function in secure world. The RPC carries information describing the OCALL as well as its parameters. When this happens, the driver saves the state of the current call and returns to user-mode. The TEE Client API will have invoked the TEE_IOC_INVOKE IOCTL with a special parameter that carries OCALL information. When the IOCTL returns prematurely, this parameter includes information about what the CA is expected to do on behalf of the TA along with data to be used to reply to the request. The TEE Client API dispatches the request accordingly to the CA proper. Once that is done, the TEE Client API calls the TEE_IOC_INVOKE IOCTL again with the modified OCALL parameter and associated information (such as the result of the OCALL, and the parameters, as requested by the TA). The driver notices that this invocation is in fact a resumption as opposed to a brand-new invocation, and resumes the secure world thread that sent the RPC in the first place. The same mechanism applies to OCALLs during session open. This patch also minimally updates the OP-TEE and AMD TEE drivers to match the new signatures for session open and invoke. If an OCALL is specified by the CA, EOPNOTSUPP is returned. Signed-off-by: Hernan Gatta <[email protected]>
Enable OCALL support specifically for OP-TEE. Signed-off-by: Hernan Gatta <[email protected]>
Introduce compatible "linaro,scmi-optee" for SCMI transport channel based on an OP-TEE service invocation. Change-Id: I277f504945a4b60d00a64d02416047548c4e0669
Add a new transport channel to the SCMI firmware interface driver for SCMI message exchange based on OP-TEE transport channel that leverage OP-TEE secure threaded context for processing of SCMI messages. The current proposal uses a statically defined physical memory area to be used as shared memory SCMI endpoints. The location is extracted from the FDT upon property "shmem". Entry in OP-TEE threaded context is realized by invoking a service PTA (Pseudo TA) in OP-TEE OS. Each invocation carries a agent numerical identifier for which a message is pending in the shared memory. The OP-TEE service provides means to get the agent identifier value for a given shared memory location. OPTEE transport driver depends on CONFIG_OPTEE and probes from SCMI compatible identifier "arm,scmi-optee". Signed-off-by: Etienne Carriere <[email protected]>
Using OP-TEE Ocall to provision a secure thread in OP-TEE for SCMI messages entry not to failed because userland has exhausted the available secure threads. New SCMI PTA command PTA_SCMI_CMD_OCALL_THREAD to create the Ocall thread context. New PTA_SCMI_CAPS_OCALL_THREAD capabilities for a channel. Ocall thread setup, use and close sequences are described in the inline comment describing the SCMI PTA API. Linux SCMI OP-TEE transport driver attempts an Ocall context and falls back to the standard invocation path if the PTA is not Ocall capable or fails the create the Ocall context. Signed-off-by: Etienne Carriere <[email protected]>
abuzarra
pushed a commit
to digi-embedded/linux
that referenced
this pull request
Nov 30, 2022
Sync with SCMI OP-TEE transport reviewed at upstream through pull-request linaro-swg/linux#90. Change-Id: Iae3a0e44717983bcd6db126edda2ea4bedf9fe7d Signed-off-by: Etienne Carriere <[email protected]> Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/linux-stm32/+/202488 Reviewed-by: Etienne CARRIERE <[email protected]> Reviewed-by: MPUOSTL Tested-by: Alexandre TORGUE <[email protected]>
|
Time to close this P-R. Another way to provision TEE thread is proposed in OP-TEE/optee_os#5789. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Relates to OP-TEE/optee_os#4535.
These changes build on top of OCALL implementation from @HernanGatta in #72.
These changes implement an SCMI transport using an identified SCMI PTA exposed by OP-TEE.
The 2 first commits implement an SCMI transport driver standard service, interfacing SCMI PTA from OP-TEE/optee_os#4533.
Last commit leverage OCALL support to provision a secure thread per SCMI communication channel, using SCMI PTA Ocall support from OP-TEE/optee_os#4535.
Linux/OP-TEE calls flow in shown in this comment.