May 2023 - OP-TEE - lists.trustedfirmware.org

Re: rk3399 issue: no DMA in Linux with mainline TF-A and U-Boot SPL

by kever.yang＠rock-chips.com

The content of this message was lost. It was probably cross-posted to multiple lists and previously handled on another list.

3 months

3
2
0 0

[PATCH v2 0/4] rpmb subsystem, uapi and virtio-rpmb driver

by Shyam Saini

Hi Alex, [ Resending, Sorry for the noise ] Are you still working on it or planning to resubmit it ? [1] The current optee tee kernel driver implementation doesn't work when IMA is used with optee implemented ftpm. The ftpm has dependency on tee-supplicant which comes once the user space is up and running and IMA attestation happens at boot time and it requires to extend ftpm PCRs. But IMA can't use PCRs if ftpm use secure emmc RPMB partition. As optee can only access RPMB via tee-supplicant(user space). So, there should be a fast path to allow optee os to access the RPMB parititon without waiting for user-space tee supplicant. To achieve this fast path linux optee driver and mmc driver needs some work and finally it will need RPMB driver which you posted. Please let me know what's your plan on this. [1] https://optee.readthedocs.io/en/latest/architecture/secure_storage.html Best Regards, Shyam

1 year, 1 month

5
7
0 0

[PATCH v5 0/3] introduce tee-based EFI Runtime Variable Service

by Masahisa Kojima

This series introduces the tee based EFI Runtime Variable Service. The eMMC device is typically owned by the non-secure world(linux in this case). There is an existing solution utilizing eMMC RPMB partition for EFI Variables, it is implemented by interacting with OP-TEE, StandaloneMM(as EFI Variable Service Pseudo TA), eMMC driver and tee-supplicant. The last piece is the tee-based variable access driver to interact with OP-TEE and StandaloneMM. Changelog: v4 -> v5 - rebase to efi-next based on v6.4-rc1 - set generic_ops.query_variable_info, it works as expected as follows. $ df -h /sys/firmware/efi/efivars/ Filesystem Size Used Avail Use% Mounted on efivarfs 16K 1.3K 15K 8% /sys/firmware/efi/efivars v3 -> v4: - replace the reference from EDK2 to PI Specification - remove EDK2 source code reference comments - prepare nonblocking variant of set_variable, it just returns EFI_UNSUPPORTED - remove redundant buffer size check - argument name change in mm_communicate - function interface changes in setup_mm_hdr to remove (void **) cast v2 -> v3: - add CONFIG_EFI dependency to TEE_STMM_EFI - add missing return code check for tee_client_invoke_func() - directly call efivars_register/unregister from tee_stmm_efi.c rfc v1 -> v2: - split patch into three patches, one for drivers/tee, one for include/linux/efi.h, and one for the driver/firmware/efi/stmm - context/session management into probe() and remove() same as other tee client driver - StMM variable driver is moved from driver/tee/optee to driver/firmware/efi - use "tee" prefix instead of "optee" in driver/firmware/efi/stmm/tee_stmm_efi.c, this file does not contain op-tee specific code, abstracted by tee layer and StMM variable driver will work on other tee implementation. - PTA_STMM_CMD_COMMUNICATE -> PTA_STMM_CMD_COMMUNICATE - implement query_variable_store() but currently not used - no use of TEEC_SUCCESS, it is defined in driver/tee/optee/optee_private.h. Other tee client drivers use 0 instead of using TEEC_SUCCESS - remove TEEC_ERROR_EXCESS_DATA status, it is referred just to output error message Masahisa Kojima (3): efi: expose efivar generic ops register function efi: Add EFI_ACCESS_DENIED status code efi: Add tee-based EFI variable driver drivers/firmware/efi/Kconfig | 15 + drivers/firmware/efi/Makefile | 1 + drivers/firmware/efi/efi.c | 12 + drivers/firmware/efi/stmm/mm_communication.h | 236 +++++++ drivers/firmware/efi/stmm/tee_stmm_efi.c | 638 +++++++++++++++++++ include/linux/efi.h | 4 + 6 files changed, 906 insertions(+) create mode 100644 drivers/firmware/efi/stmm/mm_communication.h create mode 100644 drivers/firmware/efi/stmm/tee_stmm_efi.c -- 2.30.2

1 year, 1 month

6
33
0 0

[PATCH v5 1/2] dt-bindings: arm: optee: add interrupt controller properties

by Etienne Carriere

Adds an optional interrupt controller property to optee firmware node in the DT bindings. Optee driver may embeds an irqchip exposing OP-TEE interrupt events notified by the TEE world. Optee registers up to 1 interrupt controller and identifies each line with a line number from 0 to UINT16_MAX. The identifiers and meaning of the interrupt line number are specific to the platform and shall be found in the OP-TEE platform documentation. In the example shown in optee DT binding documentation, the platform SCMI device controlled by Linux scmi driver uses optee interrupt irq 5 as signal to trigger processing of an asynchronous incoming SCMI message in the scope of a CPU DVFS control. A platform can have several SCMI channels driven this way. Optee irqs also permit small embedded devices to share e.g. a gpio expander, a group of wakeup sources, etc... between OP-TEE world (for sensitive services) and Linux world (for non-sensitive services). The physical controller is driven from the TEE which exposes some controls to Linux kernel. Cc: Jens Wiklander <jens.wiklander(a)linaro.org> Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt(a)linaro.org> Cc: Marc Zyngier <maz(a)kernel.org> Cc: Rob Herring <robh+dt(a)kernel.org> Cc: Sumit Garg <sumit.garg(a)linaro.org> Co-developed-by: Pascal Paillet <p.paillet(a)foss.st.com> Signed-off-by: Pascal Paillet <p.paillet(a)foss.st.com> Signed-off-by: Etienne Carriere <etienne.carriere(a)linaro.org> --- Changes since v4: - Removed empty line between Cc: tags and S-o-b tags. No changes since v3 Changes since v2: - Added a sentence on optee irq line number values and meaning, in DT binding doc and commit message. - Updated example in DT binding doc from comment, fixed misplaced interrupt-parent property and removed gic and sram shm nodes. Changes since v1: - Added a description to #interrupt-cells property. - Changed of example. Linux wakeup event was subject to discussion and i don't know much about input events in Linux. So move to SCMI. In the example, an SCMI server in OP-TEE world raises optee irq 5 so that Linux scmi optee channel &scmi_cpu_dvfs pushed in the incoming SCMI message in the scmi device for liekly later processing in threaded context. The example includes all parties: optee, scmi, sram, gic. - Obviously rephrased the commit message. --- .../arm/firmware/linaro,optee-tz.yaml | 38 +++++++++++++++++++ 1 file changed, 38 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml index 5d033570b57b..9d9a797a6b2f 100644 --- a/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml +++ b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml @@ -41,6 +41,16 @@ properties: HVC #0, register assignments register assignments are specified in drivers/tee/optee/optee_smc.h + interrupt-controller: true + + "#interrupt-cells": + const: 1 + description: | + OP-TEE exposes irq for irp chip controllers from OP-TEE world. Each + irq is assigned a single line number identifier used as first argument. + Line number identifiers and their meaning shall be found in the OP-TEE + firmware platform documentation. + required: - compatible - method @@ -65,3 +75,31 @@ examples: method = "hvc"; }; }; + + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + firmware { + optee: optee { + compatible = "linaro,optee-tz"; + method = "smc"; + interrupt-parent = <&gic>; + interrupts = <GIC_SPI 187 IRQ_TYPE_EDGE_RISING>; + interrupt-controller; + #interrupt-cells = <1>; + }; + + scmi { + compatible = "linaro,scmi-optee"; + linaro,optee-channel-id = <0>; + shmem = <&scmi_shm_tx>, <&scmi_shm_rx>; + interrupts-extended = <&optee 5>; + interrupt-names = "a2p"; + #address-cells = <1>; + #size-cells = <0>; + + scmi_cpu_dvfs: protocol@13 { + reg = <0x13>; + #clock-cells = <1>; + }; + }; + }; -- 2.25.1

1 year, 1 month

3
4
0 0

[RFC PATCH 0/4] introduction of a remoteproc tee to load signed firmware images

by Arnaud Pouliquen

This RFC proposes an implementation of a remoteproc tee driver to communicate with a TEE trusted application in charge of authenticating and loading remoteproc firmware image in an Arm secure context. The services implemented are the same as those offered by the Linux remoteproc framework: - load of a signed firmware - start/stop of a coprocessor - get the resource table The OP-TEE code in charge of providing the service in a trusted application is proposed for upstream here: https://github.com/OP-TEE/optee_os/pull/6027 For more details on the implementation a presentation is available here: https://resources.linaro.org/en/resource/6c5bGvZwUAjX56fvxthxds Arnaud Pouliquen (4): tee: Re-enable vmalloc page support for shared memory remoteproc: Add TEE support dt-bindings: remoteproc: add compatibility for TEE support remoteproc: stm32: Add support of an OP-TEE TA to load the firmware .../bindings/remoteproc/st,stm32-rproc.yaml | 33 +- drivers/remoteproc/Kconfig | 9 + drivers/remoteproc/Makefile | 1 + drivers/remoteproc/stm32_rproc.c | 234 +++++++++-- drivers/remoteproc/tee_remoteproc.c | 397 ++++++++++++++++++ drivers/tee/tee_shm.c | 24 +- include/linux/tee_remoteproc.h | 101 +++++ 7 files changed, 753 insertions(+), 46 deletions(-) create mode 100644 drivers/remoteproc/tee_remoteproc.c create mode 100644 include/linux/tee_remoteproc.h -- 2.25.1

1 year, 1 month

5
14
0 0

optee_benchmark pmccfiltr_el0

by 梅建强(禹夜)

Hi, It is confirmed that the problem is related to the pmu register configuration and that pmccntr_el0 can be read at any exception level. Regards, Yuye. ------------------------------------------------------------------ 发件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 发送时间：2023年5月26日(星期五) 16:59 收件人：Jens Wiklander <jens.wiklander(a)linaro.org>; Olivier Deprez <olivier.deprez(a)arm.com> 抄　送：op-tee <op-tee(a)lists.trustedfirmware.org>; hafnium <hafnium(a)lists.trustedfirmware.org>; 黄明(连一) <hm281385(a)alibaba-inc.com> 主　题：optee_benchmark pmccfiltr_el0 Hi, Jens, Olivier, In case of that optee runs at sel1 and hafnium runs at sel2, we want to test benchmark by executing the following command at optee_benchmark path: ./out/benchmark ../optee_examples/out/ca/optee_example_hello_world After entering into the benchmark pta, the bm_timestamp function attempts to read the pmccfiltr_el0 register. In cold boot, the following code will be executed during hafnium initialization: vm->arch.trapped_features |= HF_FEATURE_PERFMON; This will prevent the secondary vm from accessing the performance counter registers. We remove the code, the bm_timestamp function can read pmccfiltr_el0 without trapping into hafnium. But the value of pmccfiltr_el0 remains unchanged and cannot be counted. We tried to read the register in hafnium and found that there was no change either. In contrast, in the normal world, pmccfiltr_el0 counts normally. Is it related to the pmu register configuration or does sel1 not support the pmccfiltr_el0 count at present? Thanks for the support. Regards, Yuye.

1 year, 1 month

2
1
0 0

[v2,0/4] rpmb subsystem, uapi and virtio-rpmb driver

by Shyam Saini

Hi Alex, Are you still working on it or planning to resubmit it ? [1] The current optee tee kernel driver implementation doesn't work when IMA is used with optee implemented ftpm. The ftpm has dependency on tee-supplicant which comes once the user-space is up and running and IMA attestation happens at boot time and it requires to extend ftpm PCRs. But IMA can't use PCRs if ftpm use secure emmc RPMB partition. As optee can only access RPMB via tee-supplicant(user space). So, there should be a fast path to allow optee os to access the RPMB parititon without waiting for user-space the tee supplicant. To achieve this fast path linux optee driver and mmc driver needs some work and finally it will need RPMB driver which you posted. Please let me know what's your plan on this. [1] https://optee.readthedocs.io/en/latest/architecture/secure_storage.html Thanks, Shyam

1 year, 1 month

1
0
0 0

[PATCH v9 3/4] tee: optee: support tracking system threads

by Sumit Garg

From: Etienne Carriere <etienne.carriere(a)linaro.org> Adds support in the OP-TEE driver to keep track of reserved system threads. The optee_cq_*() functions are updated to handle this if enabled. The SMC ABI part of the driver enables this tracking, but the FF-A ABI part does not. The logic allows atleast 1 OP-TEE thread can be reserved to TEE system sessions. For sake of simplicity, initialization of call queue management is factorized into new helper function optee_cq_init(). Co-developed-by: Jens Wiklander <jens.wiklander(a)linaro.org> Signed-off-by: Jens Wiklander <jens.wiklander(a)linaro.org> Signed-off-by: Etienne Carriere <etienne.carriere(a)linaro.org> Co-developed-by: Sumit Garg <sumit.garg(a)linaro.org> Signed-off-by: Sumit Garg <sumit.garg(a)linaro.org> --- Disclaimer: Compile tested only Hi Etienne, Overall the idea we agreed upon was okay but the implementation looked complex to me. So I thought it would be harder to explain that via review and I decided myself to give a try at simplification. I would like you to test it if this still addresses the SCMI deadlock problem or not. Also, feel free to include this in your patchset if all goes fine wrt testing. -Sumit Changes since v8: - Simplified system threads tracking implementation. drivers/tee/optee/call.c | 72 +++++++++++++++++++++++++++++-- drivers/tee/optee/ffa_abi.c | 3 +- drivers/tee/optee/optee_private.h | 16 +++++++ drivers/tee/optee/smc_abi.c | 16 ++++++- 4 files changed, 99 insertions(+), 8 deletions(-) diff --git a/drivers/tee/optee/call.c b/drivers/tee/optee/call.c index 42e478ac6ce1..09e824e4dcaf 100644 --- a/drivers/tee/optee/call.c +++ b/drivers/tee/optee/call.c @@ -39,9 +39,27 @@ struct optee_shm_arg_entry { DECLARE_BITMAP(map, MAX_ARG_COUNT_PER_ENTRY); }; +void optee_cq_init(struct optee_call_queue *cq, int thread_count) +{ + mutex_init(&cq->mutex); + INIT_LIST_HEAD(&cq->waiters); + /* + * If cq->total_thread_count is 0 then we're not trying to keep + * track of how many free threads we have, instead we're relying on + * the secure world to tell us when we're out of thread and have to + * wait for another thread to become available. + */ + cq->total_thread_count = thread_count; + cq->free_thread_count = thread_count; +} + void optee_cq_wait_init(struct optee_call_queue *cq, struct optee_call_waiter *w, bool sys_thread) { + bool need_wait = false; + + memset(w, 0, sizeof(*w)); + /* * We're preparing to make a call to secure world. In case we can't * allocate a thread in secure world we'll end up waiting in @@ -53,15 +71,43 @@ void optee_cq_wait_init(struct optee_call_queue *cq, mutex_lock(&cq->mutex); /* - * We add ourselves to the queue, but we don't wait. This - * guarantees that we don't lose a completion if secure world - * returns busy and another thread just exited and try to complete - * someone. + * We add ourselves to a queue, but we don't wait. This guarantees + * that we don't lose a completion if secure world returns busy and + * another thread just exited and try to complete someone. */ init_completion(&w->c); list_add_tail(&w->list_node, &cq->waiters); + if (cq->total_thread_count && sys_thread) { + if (cq->free_thread_count > 0) + cq->free_thread_count--; + else + need_wait = true; + } else if (cq->total_thread_count) { + if (cq->free_thread_count > 1) + cq->free_thread_count--; + else + need_wait = true; + } + mutex_unlock(&cq->mutex); + + while (need_wait) { + optee_cq_wait_for_completion(cq, w); + mutex_lock(&cq->mutex); + if (sys_thread) { + if (cq->free_thread_count > 0) { + cq->free_thread_count--; + need_wait = false; + } + } else { + if (cq->free_thread_count > 1) { + cq->free_thread_count--; + need_wait = false; + } + } + mutex_unlock(&cq->mutex); + } } void optee_cq_wait_for_completion(struct optee_call_queue *cq, @@ -104,6 +150,8 @@ void optee_cq_wait_final(struct optee_call_queue *cq, /* Get out of the list */ list_del(&w->list_node); + cq->free_thread_count++; + /* Wake up one eventual waiting task */ optee_cq_complete_one(cq); @@ -361,6 +409,22 @@ int optee_open_session(struct tee_context *ctx, return rc; } +int optee_system_session(struct tee_context *ctx, u32 session) +{ + struct optee_context_data *ctxdata = ctx->data; + struct optee_session *sess; + + mutex_lock(&ctxdata->mutex); + + sess = find_session(ctxdata, session); + if (sess && !sess->use_sys_thread) + sess->use_sys_thread = true; + + mutex_unlock(&ctxdata->mutex); + + return 0; +} + int optee_close_session_helper(struct tee_context *ctx, u32 session, bool system_thread) { diff --git a/drivers/tee/optee/ffa_abi.c b/drivers/tee/optee/ffa_abi.c index 5fde9d4100e3..0c9055691343 100644 --- a/drivers/tee/optee/ffa_abi.c +++ b/drivers/tee/optee/ffa_abi.c @@ -852,8 +852,7 @@ static int optee_ffa_probe(struct ffa_device *ffa_dev) if (rc) goto err_unreg_supp_teedev; mutex_init(&optee->ffa.mutex); - mutex_init(&optee->call_queue.mutex); - INIT_LIST_HEAD(&optee->call_queue.waiters); + optee_cq_init(&optee->call_queue, 0); optee_supp_init(&optee->supp); optee_shm_arg_cache_init(optee, arg_cache_flags); ffa_dev_set_drvdata(ffa_dev, optee); diff --git a/drivers/tee/optee/optee_private.h b/drivers/tee/optee/optee_private.h index b68273051454..6dcecb83c893 100644 --- a/drivers/tee/optee/optee_private.h +++ b/drivers/tee/optee/optee_private.h @@ -40,15 +40,29 @@ typedef void (optee_invoke_fn)(unsigned long, unsigned long, unsigned long, unsigned long, unsigned long, struct arm_smccc_res *); +/* + * struct optee_call_waiter - TEE entry may need to wait for a free TEE thread + * @list_node Reference in waiters list + * @c Waiting completion reference + */ struct optee_call_waiter { struct list_head list_node; struct completion c; }; +/* + * struct optee_call_queue - OP-TEE call queue management + * @mutex Serializes access to this struct + * @waiters List of threads waiting to enter OP-TEE + * @total_thread_count Overall number of thread context in OP-TEE or 0 + * @free_thread_count Number of threads context free in OP-TEE + */ struct optee_call_queue { /* Serializes access to this struct */ struct mutex mutex; struct list_head waiters; + int total_thread_count; + int free_thread_count; }; struct optee_notif { @@ -254,6 +268,7 @@ int optee_supp_send(struct tee_context *ctx, u32 ret, u32 num_params, int optee_open_session(struct tee_context *ctx, struct tee_ioctl_open_session_arg *arg, struct tee_param *param); +int optee_system_session(struct tee_context *ctx, u32 session); int optee_close_session_helper(struct tee_context *ctx, u32 session, bool system_thread); int optee_close_session(struct tee_context *ctx, u32 session); @@ -303,6 +318,7 @@ static inline void optee_to_msg_param_value(struct optee_msg_param *mp, mp->u.value.c = p->u.value.c; } +void optee_cq_init(struct optee_call_queue *cq, int thread_count); void optee_cq_wait_init(struct optee_call_queue *cq, struct optee_call_waiter *w, bool sys_thread); void optee_cq_wait_for_completion(struct optee_call_queue *cq, diff --git a/drivers/tee/optee/smc_abi.c b/drivers/tee/optee/smc_abi.c index e2763cdcf111..3314ffeb91c8 100644 --- a/drivers/tee/optee/smc_abi.c +++ b/drivers/tee/optee/smc_abi.c @@ -1209,6 +1209,7 @@ static const struct tee_driver_ops optee_clnt_ops = { .release = optee_release, .open_session = optee_open_session, .close_session = optee_close_session, + .system_session = optee_system_session, .invoke_func = optee_invoke_func, .cancel_req = optee_cancel_req, .shm_register = optee_shm_register, @@ -1356,6 +1357,16 @@ static bool optee_msg_exchange_capabilities(optee_invoke_fn *invoke_fn, return true; } +static unsigned int optee_msg_get_thread_count(optee_invoke_fn *invoke_fn) +{ + struct arm_smccc_res res; + + invoke_fn(OPTEE_SMC_GET_THREAD_COUNT, 0, 0, 0, 0, 0, 0, 0, &res); + if (res.a0) + return 0; + return res.a1; +} + static struct tee_shm_pool * optee_config_shm_memremap(optee_invoke_fn *invoke_fn, void **memremaped_shm) { @@ -1609,6 +1620,7 @@ static int optee_probe(struct platform_device *pdev) struct optee *optee = NULL; void *memremaped_shm = NULL; unsigned int rpc_param_count; + unsigned int thread_count; struct tee_device *teedev; struct tee_context *ctx; u32 max_notif_value; @@ -1636,6 +1648,7 @@ static int optee_probe(struct platform_device *pdev) return -EINVAL; } + thread_count = optee_msg_get_thread_count(invoke_fn); if (!optee_msg_exchange_capabilities(invoke_fn, &sec_caps, &max_notif_value, &rpc_param_count)) { @@ -1725,8 +1738,7 @@ static int optee_probe(struct platform_device *pdev) if (rc) goto err_unreg_supp_teedev; - mutex_init(&optee->call_queue.mutex); - INIT_LIST_HEAD(&optee->call_queue.waiters); + optee_cq_init(&optee->call_queue, thread_count); optee_supp_init(&optee->supp); optee->smc.memremaped_shm = memremaped_shm; optee->pool = pool; -- 2.34.1

1 year, 1 month

4
10
0 0

optee_benchmark pmccfiltr_el0

by 梅建强(禹夜)

Hi, Jens, Olivier, In case of that optee runs at sel1 and hafnium runs at sel2, we want to test benchmark by executing the following command at optee_benchmark path: ./out/benchmark ../optee_examples/out/ca/optee_example_hello_world After entering into the benchmark pta, the bm_timestamp function attempts to read the pmccfiltr_el0 register. In cold boot, the following code will be executed during hafnium initialization: vm->arch.trapped_features |= HF_FEATURE_PERFMON; This will prevent the secondary vm from accessing the performance counter registers. We remove the code, the bm_timestamp function can read pmccfiltr_el0 without trapping into hafnium. But the value of pmccfiltr_el0 remains unchanged and cannot be counted. We tried to read the register in hafnium and found that there was no change either. In contrast, in the normal world, pmccfiltr_el0 counts normally. Is it related to the pmu register configuration or does sel1 not support the pmccfiltr_el0 count at present? Thanks for the support. Regards, Yuye.

1 year, 2 months

1
0
0 0

[PATCH v4 0/3] introduce tee-based EFI Runtime Variable Service

by Masahisa Kojima

This series introduces the tee based EFI Runtime Variable Service. The eMMC device is typically owned by the non-secure world(linux in this case). There is an existing solution utilizing eMMC RPMB partition for EFI Variables, it is implemented by interacting with OP-TEE, StandaloneMM(as EFI Variable Service Pseudo TA), eMMC driver and tee-supplicant. The last piece is the tee-based variable access driver to interact with OP-TEE and StandaloneMM. Changelog: v3 -> v4: - replace the reference from EDK2 to PI Specification - remove EDK2 source code reference comments - prepare nonblocking variant of set_variable, it just returns EFI_UNSUPPORTED - remove redundant buffer size check - argument name change in mm_communicate - function interface changes in setup_mm_hdr to remove (void **) cast v2 -> v3: - add CONFIG_EFI dependency to TEE_STMM_EFI - add missing return code check for tee_client_invoke_func() - directly call efivars_register/unregister from tee_stmm_efi.c rfc v1 -> v2: - split patch into three patches, one for drivers/tee, one for include/linux/efi.h, and one for the driver/firmware/efi/stmm - context/session management into probe() and remove() same as other tee client driver - StMM variable driver is moved from driver/tee/optee to driver/firmware/efi - use "tee" prefix instead of "optee" in driver/firmware/efi/stmm/tee_stmm_efi.c, this file does not contain op-tee specific code, abstracted by tee layer and StMM variable driver will work on other tee implementation. - PTA_STMM_CMD_COMMUNICATE -> PTA_STMM_CMD_COMMUNICATE - implement query_variable_store() but currently not used - no use of TEEC_SUCCESS, it is defined in driver/tee/optee/optee_private.h. Other tee client drivers use 0 instead of using TEEC_SUCCESS - remove TEEC_ERROR_EXCESS_DATA status, it is referred just to output error message Masahisa Kojima (3): efi: expose efivar generic ops register function efi: Add EFI_ACCESS_DENIED status code efi: Add tee-based EFI variable driver drivers/firmware/efi/Kconfig | 15 + drivers/firmware/efi/Makefile | 1 + drivers/firmware/efi/efi.c | 12 + drivers/firmware/efi/stmm/mm_communication.h | 236 +++++++ drivers/firmware/efi/stmm/tee_stmm_efi.c | 637 +++++++++++++++++++ include/linux/efi.h | 4 + 6 files changed, 905 insertions(+) create mode 100644 drivers/firmware/efi/stmm/mm_communication.h create mode 100644 drivers/firmware/efi/stmm/tee_stmm_efi.c -- 2.30.2

1 year, 2 months

4
7
0 0

2024

2023

2022

2021

2020

OP-TEE May 2023