December 2024 - OP-TEE - lists.trustedfirmware.org

Re: [PATCH v4 0/6] TEE subsystem for restricted dma-buf allocations

by Sumit Garg

Hi Lukas, On Tue, 24 Dec 2024 at 14:58, Lukas Wunner <lukas(a)wunner.de> wrote: > > On Tue, Dec 24, 2024 at 12:05:19PM +0530, Sumit Garg wrote: > > Restricted memory is a feature enforced by hardware specific firewalls > > where a particular TEE implementation governs which particular block > > of memory is accessible to a particular peripheral or a CPU running in > > a higher privileged mode than the Linux kernel. > [...] > > - Another possible use-case can be for the TEE implementation to store > > key material in a restricted buffer which is only accessible to the > > hardware crypto accelerator. > > Just a heads-up: > > For RSA sign/verify operations using rsassa-pkcs1 encoding, > the message to be signed/verified (which I understand could > be located in restricted memory) is prepended by a padding. > > The crypto subsystem does the prepending of the padding in software. > The actual signature generation/verification (which is an RSA encrypt > or decrypt operation) may be performed in hardware by a crypto > accelerator. > > Before commit 8552cb04e083 ("crypto: rsassa-pkcs1 - Copy source > data for SG list"), the kernel constructed a scatterlist > consisting of the padding on the one hand, and of the message > to be signed/verified on the other hand. I believe this worked > for use cases where the message is located in restricted memory. > > However since that commit, the kernel kmalloc's a new buffer and > copies the message to be signed/verified into it. The argument > was that although the *kernel* may be able to access the data, > the crypto accelerator may *not* be able to do so. In particular, > portions of the padding are located in the kernel's .rodata section > which is a valid virtual address on x86 but not on arm64 and > which may be inaccessible to a crypto accelerator. > > However in the case of restricted memory, the situation is exactly > the opposite: The kernel may *not* be able to access the data, > but the crypto accelerator can access it just fine. > > I did raise a concern about this to the maintainer, but to no avail: > https://lore.kernel.org/r/Z1Kym1-9ka8kGHrM@wunner.de/ Herbert's point is valid that there isn't any point for mapping restricted memory in the kernel virtual address space as any kernel access to that space can lead to platform specific hardware error scenarios. And for that reason we simply disallow dma_buf_mmap() and don't support dma_buf_vmap() for DMA-bufs holding TEE restricted memory. The only consumers for those DMA-bufs will be the DMA capable peripherals granted access permissions by the TEE implementation. IOW, kernel role here will be to just provide the DMA-buf infrastructure for buffers to be set up by TEE and then setting up DMA addresses for peripherals to access them. The hardware crypto accelerator can be one such peripheral. > > This is the alternative solution I would have preferred: > https://lore.kernel.org/r/3de5d373c86dcaa5abc36f501c1398c4fbf05f2f.17328651… > > > I am also in favour of end to end open source use-cases. But I fear > > without progressing in a step wise manner as with this proposal we > > would rather force developers to upstream all the software pieces in > > one go which will be kind of a chicken and egg situation. I am sure > > once this feature lands Mediatek folks will be interested to port > > their secure video playback patchset [3] on top of it. Similarly other > > silicon vendors like NXP, Qcom etc. will be motivated to do the same. > > The crypto use case may be easier to bring up than the video decoding > use case because you don't need to implement a huge amount of > user space code. Agree, if you already have such an existing hardware use-case then please feel free to build up on this patch-set. -Sumit > > Thanks, > > Lukas

4 days, 11 hours

1
0
0 0

Re: [PATCH v4 0/6] TEE subsystem for restricted dma-buf allocations

by Dmitry Baryshkov

On Tue, Dec 24, 2024 at 10:32:41AM +0100, Lukas Wunner wrote: > On Tue, Dec 24, 2024 at 10:28:31AM +0100, Lukas Wunner wrote: > > I did raise a concern about this to the maintainer, but to no avail: > > https://lore.kernel.org/r/Z1Kym1-9ka8kGHrM@wunner.de/ > > Sorry, wrong link. This is the one I meant to copy-paste... :( > > https://lore.kernel.org/r/Z0rPxCGdD7r8HFKb@wunner.de/ Herbert asked a logical question, which got no response from your side. -- With best wishes Dmitry

6 days, 7 hours

1
0
0 0

[PATCH v4 0/6] TEE subsystem for restricted dma-buf allocations

by Jens Wiklander

Hi, This patch set allocates the restricted DMA-bufs via the TEE subsystem. The TEE subsystem handles the DMA-buf allocations since it is the TEE (OP-TEE, AMD-TEE, TS-TEE, or perhaps a future QCOMTEE) which sets up the restrictions for the memory used for the DMA-bufs. I've added a new IOCTL, TEE_IOC_RSTMEM_ALLOC, to allocate the restricted DMA-bufs. This IOCTL reaches the backend TEE driver, allowing it to choose how to allocate the restricted physical memory. TEE_IOC_RSTMEM_ALLOC takes in addition to a size and flags parameters also a use-case parameter. This is used by the backend TEE driver to decide on allocation policy and which devices should be able to access the memory. Three use-cases (Secure Video Playback, Trusted UI, and Secure Video Recording) has been identified so far to serve as examples of what can be expected. More use-cases can be added in userspace ABI, but it's up to the backend TEE drivers to provide the implementation. Each use-case has it's own restricted memory pool since different use-cases requires isolation from different parts of the system. A restricted memory pool can be based on a static carveout instantiated while probing the TEE backend driver, or dynamically allocated from CMA and made restricted as needed by the TEE. This can be tested on QEMU with the following steps: repo init -u https://github.com/jenswi-linaro/manifest.git -m qemu_v8.xml \ -b prototype/sdp-v4 repo sync -j8 cd build make toolchains -j$(nproc) make SPMC_AT_EL=1 all -j$(nproc) make SPMC_AT_EL=1 run-only # login and at the prompt: xtest --sdp-basic The SPMC_AT_EL=1 parameter configures the build with FF-A and an SPMC at S-EL1 inside OP-TEE. The parameter can be changed into SPMC_AT_EL=n to test without FF-A using the original SMC ABI instead. Please remember to do %rm -rf ../trusted-firmware-a/build/qemu for TF-A to be rebuilt properly using the new configuration. https://optee.readthedocs.io/en/latest/building/prerequisites.html list dependencies needed to build the above. The tests are pretty basic, mostly checking that a Trusted Application in the secure world can access and manipulate the memory. There are also some negative tests for out of bounds buffers etc. Thanks, Jens Changes since V3: * Make the use_case and flags field in struct tee_shm u32's instead of u16's * Add more description for TEE_IOC_RSTMEM_ALLOC in the header file * Import namespace DMA_BUF in module tee, reported by lkp(a)intel.com * Added a note in the commit message for "optee: account for direction while converting parameters" why it's needed * Factor out dynamic restricted memory allocation from "optee: support restricted memory allocation" into two new commits "optee: FF-A: dynamic restricted memory allocation" and "optee: smc abi: dynamic restricted memory allocation" * Guard CMA usage with #ifdef CONFIG_CMA, effectively disabling dynamic restricted memory allocate if CMA isn't configured Changes since the V2 RFC: * Based on v6.12 * Replaced the flags for SVP and Trusted UID memory with a u32 field with unique id for each use case * Added dynamic allocation of restricted memory pools * Added OP-TEE ABI both with and without FF-A for dynamic restricted memory * Added support for FF-A with FFA_LEND Changes since the V1 RFC: * Based on v6.11 * Complete rewrite, replacing the restricted heap with TEE_IOC_RSTMEM_ALLOC Changes since Olivier's post [2]: * Based on Yong Wu's post [1] where much of dma-buf handling is done in the generic restricted heap * Simplifications and cleanup * New commit message for "dma-buf: heaps: add Linaro restricted dmabuf heap support" * Replaced the word "secure" with "restricted" where applicable Jens Wiklander (6): tee: add restricted memory allocation optee: account for direction while converting parameters optee: sync secure world ABI headers optee: support restricted memory allocation optee: FF-A: dynamic restricted memory allocation optee: smc abi: dynamic restricted memory allocation drivers/tee/Makefile | 1 + drivers/tee/optee/Makefile | 1 + drivers/tee/optee/call.c | 10 +- drivers/tee/optee/core.c | 1 + drivers/tee/optee/ffa_abi.c | 178 +++++++++++++- drivers/tee/optee/optee_ffa.h | 27 ++- drivers/tee/optee/optee_msg.h | 65 ++++- drivers/tee/optee/optee_private.h | 75 ++++-- drivers/tee/optee/optee_smc.h | 71 +++++- drivers/tee/optee/rpc.c | 31 ++- drivers/tee/optee/rstmem.c | 388 ++++++++++++++++++++++++++++++ drivers/tee/optee/smc_abi.c | 213 ++++++++++++++-- drivers/tee/tee_core.c | 38 ++- drivers/tee/tee_private.h | 2 + drivers/tee/tee_rstmem.c | 201 ++++++++++++++++ drivers/tee/tee_shm.c | 2 + drivers/tee/tee_shm_pool.c | 69 +++++- include/linux/tee_core.h | 15 ++ include/linux/tee_drv.h | 2 + include/uapi/linux/tee.h | 44 +++- 20 files changed, 1358 insertions(+), 76 deletions(-) create mode 100644 drivers/tee/optee/rstmem.c create mode 100644 drivers/tee/tee_rstmem.c base-commit: fac04efc5c793dccbd07e2d59af9f90b7fc0dca4 -- 2.43.0

6 days, 10 hours

4
10
0 0

[PATCH 00/10] Trusted Execution Environment (TEE) driver for Qualcomm TEE (QTEE)

by Amirreza Zarrabi

This patch series introduces a Trusted Execution Environment (TEE) driver for Qualcomm TEE (QTEE). QTEE enables Trusted Applications (TAs) and services to run securely. It uses an object-based interface, where each service is an object with sets of operations. Clients can invoke these operations on objects, which can generate results, including other objects. For example, an object can load a TA and return another object that represents the loaded TA, allowing access to its services. Kernel and userspace services are also available to QTEE through a similar approach. QTEE makes callback requests that are converted into object invocations. These objects can represent services within the kernel or userspace process. Note: This patch series focuses on QTEE objects and userspace services. Linux already provides a TEE subsystem, which is described in [1]. The tee subsystem provides a generic ioctl interface, TEE_IOC_INVOKE, which can be used by userspace to talk to a TEE backend driver. We extend the Linux TEE subsystem to understand object parameters and an ioctl call so client can invoke objects in QTEE: - TEE_IOCTL_PARAM_ATTR_TYPE_OBJREF_* - TEE_IOC_OBJECT_INVOKE The existing ioctl calls TEE_IOC_SUPPL_RECV and TEE_IOC_SUPPL_SEND are used for invoking services in the userspace process by QTEE. The TEE backend driver uses the QTEE Transport Message to communicate with QTEE. Interactions through the object INVOKE interface are translated into QTEE messages. Likewise, object invocations from QTEE for userspace objects are converted into SEND/RECV ioctl calls to supplicants. The details of QTEE Transport Message to communicate with QTEE is available in [PATCH 10/10] Documentation: tee: Add Qualcomm TEE driver. This patch series has been tested for basic QTEE object invocations and callback requests, including loading a TA and requesting services form the TA. However, the test platform is currently being prepared for upstream availability and will soon be accessible to the community for further validation. I will share updates as the platform become available. [1] https://www.kernel.org/doc/Documentation/tee.txt Signed-off-by: Amirreza Zarrabi <quic_azarrabi(a)quicinc.com> --- Amirreza Zarrabi (10): tee: allow a driver to allocate a tee_device without a pool tee: add TEE_IOCTL_PARAM_ATTR_TYPE_MEMBUF tee: add TEE_IOCTL_PARAM_ATTR_TYPE_OBJREF firmware: qcom: scm: add support for object invocation qcomtee: implement object invoke support qcomtee: add primordial object dt-bindings: arm: qcomtee: add QTEE driver devicetree binding for TEE subsystem tee: add Qualcomm TEE driver arm64: dts: qcom: sm8650: add support for QTEE Documentation: tee: Add Qualcomm TEE driver .../devicetree/bindings/arm/firmware/qcom,tee.yaml | 34 + Documentation/tee/index.rst | 1 + Documentation/tee/qtee.rst | 143 ++++ arch/arm64/boot/dts/qcom/sm8650.dtsi | 4 + drivers/firmware/qcom/qcom_scm.c | 60 ++ drivers/firmware/qcom/qcom_scm.h | 7 + drivers/tee/Kconfig | 1 + drivers/tee/Makefile | 1 + drivers/tee/qcomtee/Kconfig | 10 + drivers/tee/qcomtee/Makefile | 9 + drivers/tee/qcomtee/async.c | 153 ++++ drivers/tee/qcomtee/call.c | 707 ++++++++++++++++ drivers/tee/qcomtee/core.c | 942 +++++++++++++++++++++ drivers/tee/qcomtee/primordial_obj.c | 63 ++ drivers/tee/qcomtee/qcom_scm.c | 36 + drivers/tee/qcomtee/qcomtee_msg.h | 217 +++++ drivers/tee/qcomtee/qcomtee_private.h | 218 +++++ drivers/tee/qcomtee/release.c | 66 ++ drivers/tee/qcomtee/user_obj.c | 625 ++++++++++++++ drivers/tee/tee_core.c | 113 ++- include/linux/firmware/qcom/qcom_scm.h | 9 + include/linux/firmware/qcom/qcom_tee.h | 284 +++++++ include/linux/tee_core.h | 4 + include/linux/tee_drv.h | 12 + include/uapi/linux/tee.h | 54 +- 25 files changed, 3765 insertions(+), 8 deletions(-) --- base-commit: f486c8aa16b8172f63bddc70116a0c897a7f3f02 change-id: 20241202-qcom-tee-using-tee-ss-without-mem-obj-362c66340527 Best regards, -- Amirreza Zarrabi <quic_azarrabi(a)quicinc.com>

1 week, 4 days

7
33
0 0

[PATCH] tee: optee: Add support for supplicant timeout

by Sumit Garg

OP-TEE supplicant is a user-space daemon and it's possible for it being crashed or killed in the middle of processing an OP-TEE RPC call. It becomes more complicated when there is incorrect shutdown ordering of the supplicant process vs the OP-TEE client application which can eventually lead to system hang-up waiting for the closure of the client application. In order to gracefully handle this scenario, let's add a long enough timeout to wait for supplicant to process requests. In case there is a timeout then we return a proper error code for the RPC request. Signed-off-by: Sumit Garg <sumit.garg(a)linaro.org> --- drivers/tee/optee/supp.c | 58 +++++++++++++++++++++++++--------------- 1 file changed, 36 insertions(+), 22 deletions(-) diff --git a/drivers/tee/optee/supp.c b/drivers/tee/optee/supp.c index 322a543b8c27..92e86ac4cdd4 100644 --- a/drivers/tee/optee/supp.c +++ b/drivers/tee/optee/supp.c @@ -7,6 +7,15 @@ #include <linux/uaccess.h> #include "optee_private.h" +/* + * OP-TEE supplicant timeout, the user-space supplicant may get + * crashed or killed while servicing an RPC call. This will just lead + * to OP-TEE client hung indefinitely just waiting for supplicant to + * serve requests which isn't expected. It is rather expected to fail + * gracefully with a timeout which is long enough. + */ +#define SUPP_TIMEOUT (msecs_to_jiffies(10000)) + struct optee_supp_req { struct list_head link; @@ -52,8 +61,10 @@ void optee_supp_release(struct optee_supp *supp) /* Abort all queued requests */ list_for_each_entry_safe(req, req_tmp, &supp->reqs, link) { - list_del(&req->link); - req->in_queue = false; + if (req->in_queue) { + list_del(&req->link); + req->in_queue = false; + } req->ret = TEEC_ERROR_COMMUNICATION; complete(&req->c); } @@ -82,6 +93,7 @@ u32 optee_supp_thrd_req(struct tee_context *ctx, u32 func, size_t num_params, struct optee_supp_req *req; bool interruptable; u32 ret; + int res = 1; /* * Return in case there is no supplicant available and @@ -108,28 +120,28 @@ u32 optee_supp_thrd_req(struct tee_context *ctx, u32 func, size_t num_params, /* Tell an eventual waiter there's a new request */ complete(&supp->reqs_c); - /* - * Wait for supplicant to process and return result, once we've - * returned from wait_for_completion(&req->c) successfully we have - * exclusive access again. - */ - while (wait_for_completion_interruptible(&req->c)) { + /* Wait for supplicant to process and return result */ + while (res) { + res = wait_for_completion_interruptible_timeout(&req->c, + SUPP_TIMEOUT); + /* Check if supplicant served the request */ + if (res > 0) + break; + mutex_lock(&supp->mutex); + /* + * There's no supplicant available and since the supp->mutex + * currently is held none can become available until the mutex + * released again. + * + * Interrupting an RPC to supplicant is only allowed as a way + * of slightly improving the user experience in case the + * supplicant hasn't been started yet. During normal operation + * the supplicant will serve all requests in a timely manner and + * interrupting then wouldn't make sense. + */ interruptable = !supp->ctx; - if (interruptable) { - /* - * There's no supplicant available and since the - * supp->mutex currently is held none can - * become available until the mutex released - * again. - * - * Interrupting an RPC to supplicant is only - * allowed as a way of slightly improving the user - * experience in case the supplicant hasn't been - * started yet. During normal operation the supplicant - * will serve all requests in a timely manner and - * interrupting then wouldn't make sense. - */ + if (interruptable || (res == 0)) { if (req->in_queue) { list_del(&req->link); req->in_queue = false; @@ -141,6 +153,8 @@ u32 optee_supp_thrd_req(struct tee_context *ctx, u32 func, size_t num_params, req->ret = TEEC_ERROR_COMMUNICATION; break; } + if (res == 0) + req->ret = TEE_ERROR_TIMEOUT; } ret = req->ret; -- 2.43.0

1 week, 5 days

2
6
0 0

[PATCH] optee: fix format string for printing optee build_id

by Sahil Malhotra

There has been a recent change in OP-TEE to print 8 and 16 character commit id for 32bit and 64bit architecture respectively. In case if commit id is starting with 0 like 04d1c612ec7beaede073b8c it is printing revision as below removing leading 0 "optee: revision 4.4 (4d1c612ec7beaed)" Signed-off-by: Sahil Malhotra <sahil.malhotra(a)nxp.com> --- drivers/tee/optee/smc_abi.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/tee/optee/smc_abi.c b/drivers/tee/optee/smc_abi.c index e9456e3e74cc..eb51dc18f32d 100644 --- a/drivers/tee/optee/smc_abi.c +++ b/drivers/tee/optee/smc_abi.c @@ -1272,8 +1272,9 @@ static void optee_msg_get_os_revision(optee_invoke_fn *invoke_fn) &res.smccc); if (res.result.build_id) - pr_info("revision %lu.%lu (%08lx)", res.result.major, - res.result.minor, res.result.build_id); + pr_info("revision %lu.%lu (%0*lx)", res.result.major, + res.result.minor, (int)sizeof(res.result.build_id) * 2, + res.result.build_id); else pr_info("revision %lu.%lu", res.result.major, res.result.minor); } -- 2.34.1

1 week, 5 days

4
3
0 0

Canceled Linaro OP-TEE Contribution, LOC, monthly meeting December 24

by Jens Wiklander

Hi, The LOC meeting in December is canceled due to the holidays. Happy holidays and see you next year, Jens

1 week, 6 days

1
0
0 0

Using EFI variables stored in RPMB

by Patryk

Hi, not sure if this is a good place to ask, however I see that OPTEE developers are highly involved in this topic so I decided to ask. Short background - we've been working on an embedded system based on Layerscape 1028A SoC. On this platform we've been using TFA (bl2, el3 runtime services), OPTEE as BL32 and u-boot as BL33. In the previous, older platforms we usually stored u-boot's environment in let's say "traditional way", we just stored the env on some offset of the eMMC device, however I see that on this particular, new platform there are some better possibilities, like combining OPTEE, EDKII StandaloneMM and u-boot efivars implementation to store EFI variables in RPMB on eMMC which seems to be more secure, UEFI compliant way. The aspect I'm unsure of is - does it make sense to utilize these capabilities if we want to only use it to store some u-boot's writable env variables and not utilize features like UEFI SecureBoot (at least for now, it may change it in the future)? I would be grateful for some advice. Best regards Patryk

2 weeks, 3 days

2
3
0 0

OP-TEE queries

by murali selvaraj

Hi All, We are currently working on standard PKCS#11 TA and I'm new to this topic (PKCS11, OP-TEE,TA). Please go through and share your inputs on the following queries. -> slot How do we know how many slots are supported in my device? Is it based on the physical interface of the device or how do we find the list of available slots without pkcs11-tool? Please share the details with an example. -> token Is token is a kind of virtual to hold different objects(keys, cert and so on). Can one token have private, public, leaf cert, intermediate ca cert, root ca cart and so on or any limitations on the number of objects in a token? Can we have each token be specific to the object ( for example , token1 will have cert, token 2 will have key, token 3 will have seed/client cert )? How many tokens maximum support on each slot? -> As part of pkcs11-tool, we have been using SO-PIN, user PIN, token/label name which are more specific to security. If the normal world/REE is compromised, any sensitive data it holds, including PINs and tokens, could be exposed. Do we have any access control mechanism to avoid this security issue ( in PKCS11 TA, OP-TEE context). Thanks, Murali.S

2 weeks, 5 days

2
1
0 0

[PATCH v3 0/4] TEE subsystem for restricted dma-buf allocations

by Jens Wiklander

Hi, This patch set allocates the restricted DMA-bufs via the TEE subsystem. This a big update compared to the previous patch set [1]. The TEE subsystem handles the DMA-buf allocations since it is the TEE (OP-TEE, AMD-TEE, TS-TEE, or perhaps a future QTEE) which sets up the restrictions for the memory used for the DMA-bufs. I've added a new IOCTL, TEE_IOC_RSTMEM_ALLOC, to allocate the restricted DMA-bufs. This IOCTL reaches the backend TEE driver, allowing it to choose how to allocate the restricted physical memory. TEE_IOC_RSTMEM_ALLOC takes in addition to a size and flags parameters also a use-case parameter. This is used by the backend TEE driver to decide on allocation policy and which devices should be able to access the memory. Three use-cases (Secure Video Playback, Trusted UI, and Secure Video Recording) has been identified so far to serve as examples of what can be expected. More use-cases can be added in userspace ABI, but it's up to the backend TEE drivers to provide the implementation. Each use-case has it's own restricted memory pool since different use-cases requires isolation from different parts of the system. A restricted memory pool can be based on a static carveout instantiated while probing the TEE backend driver, or dynamically allocated from CMA and made restricted as needed by the TEE. This can be tested on QEMU with the following steps: repo init -u https://github.com/jenswi-linaro/manifest.git -m qemu_v8.xml \ -b prototype/sdp-v3 repo sync -j8 cd build make toolchains -j$(nproc) make SPMC_AT_EL=1 all -j$(nproc) make SPMC_AT_EL=1 run-only # login and at the prompt: xtest --sdp-basic The SPMC_AT_EL=1 parameter configures the build with FF-A and an SPMC at S-EL1 inside OP-TEE. The parameter can be changed into SPMC_AT_EL=n to test without FF-A using the original SMC ABI instead. Please remember to do %rm -rf ../trusted-firmware-a/build/qemu for TF-A to be rebuilt properly using the new configuration. https://optee.readthedocs.io/en/latest/building/prerequisites.html list dependencies needed to build the above. The tests are pretty basic, mostly checking that a Trusted Application in the secure world can access and manipulate the memory. There are also some negative tests for out of bounds buffers etc. Thanks, Jens [1] https://lore.kernel.org/lkml/20241015101716.740829-1-jens.wiklander@linaro.… Changes since the V2 RFC: * Based on v6.12 * Replaced the flags for SVP and Trusted UID memory with a u32 field with unique id for each use case * Added dynamic allocation of restricted memory pools * Added OP-TEE ABI both with and without FF-A for dynamic restricted memory * Added support for FF-A with FFA_LEND Changes since the V1 RFC: * Based on v6.11 * Complete rewrite, replacing the restricted heap with TEE_IOC_RSTMEM_ALLOC Changes since Olivier's post [2]: * Based on Yong Wu's post [1] where much of dma-buf handling is done in the generic restricted heap * Simplifications and cleanup * New commit message for "dma-buf: heaps: add Linaro restricted dmabuf heap support" * Replaced the word "secure" with "restricted" where applicable Jens Wiklander (4): tee: add restricted memory allocation optee: account for direction while converting parameters optee: sync secure world ABI headers optee: support restricted memory allocation drivers/tee/Makefile | 1 + drivers/tee/optee/Makefile | 1 + drivers/tee/optee/call.c | 10 +- drivers/tee/optee/core.c | 1 + drivers/tee/optee/ffa_abi.c | 178 +++++++++++++- drivers/tee/optee/optee_ffa.h | 27 ++- drivers/tee/optee/optee_msg.h | 65 ++++- drivers/tee/optee/optee_private.h | 75 ++++-- drivers/tee/optee/optee_smc.h | 71 +++++- drivers/tee/optee/rpc.c | 31 ++- drivers/tee/optee/rstmem.c | 380 ++++++++++++++++++++++++++++++ drivers/tee/optee/smc_abi.c | 214 +++++++++++++++-- drivers/tee/tee_core.c | 37 ++- drivers/tee/tee_private.h | 2 + drivers/tee/tee_rstmem.c | 201 ++++++++++++++++ drivers/tee/tee_shm.c | 2 + drivers/tee/tee_shm_pool.c | 69 +++++- include/linux/tee_core.h | 15 ++ include/linux/tee_drv.h | 4 +- include/uapi/linux/tee.h | 37 ++- 20 files changed, 1344 insertions(+), 77 deletions(-) create mode 100644 drivers/tee/optee/rstmem.c create mode 100644 drivers/tee/tee_rstmem.c -- 2.43.0

3 weeks, 4 days

2
12
0 0

2024

2023

2022

2021

2020

OP-TEE December 2024