- OP-TEE - lists.trustedfirmware.org

[PATCH] tee: optee: fix build error caused by recent optee tracepoints feature

by Jisheng Zhang

If build kernel without "O=dir", below error will be seen: In file included from drivers/tee/optee/optee_trace.h:67, from drivers/tee/optee/call.c:18: ./include/trace/define_trace.h:95:42: fatal error: ./optee_trace.h: No such file or directory 95 | #include TRACE_INCLUDE(TRACE_INCLUDE_FILE) | ^ compilation terminated. Fix it by adding below line to Makefile: CFLAGS_call.o := -I$(src) Tested with and without "O=dir", both can build successfully. Reported-by: Guenter Roeck <linux(a)roeck-us.net> Suggested-by: Steven Rostedt <rostedt(a)goodmis.org> Signed-off-by: Jisheng Zhang <Jisheng.Zhang(a)synaptics.com> --- drivers/tee/optee/Makefile | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/tee/optee/Makefile b/drivers/tee/optee/Makefile index 56263ae3b1d7..3aa33ea9e6a6 100644 --- a/drivers/tee/optee/Makefile +++ b/drivers/tee/optee/Makefile @@ -6,3 +6,6 @@ optee-objs += rpc.o optee-objs += supp.o optee-objs += shm_pool.o optee-objs += device.o + +# for tracing framework to find optee_trace.h +CFLAGS_call.o := -I$(src) -- 2.31.0

4 years, 2 months

3
5
0 0

[PATCH] tee: amdtee: unload TA only when its refcount becomes 0

by Rijo Thomas

Same Trusted Application (TA) can be loaded in multiple TEE contexts. If it is a single instance TA, the TA should not get unloaded from AMD Secure Processor, while it is still in use in another TEE context. Therefore reference count TA and unload it when the count becomes zero. Fixes: 757cc3e9ff1d ("tee: add AMD-TEE driver") Reviewed-by: Devaraj Rangasamy <Devaraj.Rangasamy(a)amd.com> Signed-off-by: Rijo Thomas <Rijo-john.Thomas(a)amd.com> --- drivers/tee/amdtee/amdtee_private.h | 13 +++++ drivers/tee/amdtee/call.c | 73 +++++++++++++++++++++++++++-- drivers/tee/amdtee/core.c | 15 +++--- 3 files changed, 92 insertions(+), 9 deletions(-) diff --git a/drivers/tee/amdtee/amdtee_private.h b/drivers/tee/amdtee/amdtee_private.h index 337c8d82f74e..6d0f7062bb87 100644 --- a/drivers/tee/amdtee/amdtee_private.h +++ b/drivers/tee/amdtee/amdtee_private.h @@ -21,6 +21,7 @@ #define TEEC_SUCCESS 0x00000000 #define TEEC_ERROR_GENERIC 0xFFFF0000 #define TEEC_ERROR_BAD_PARAMETERS 0xFFFF0006 +#define TEEC_ERROR_OUT_OF_MEMORY 0xFFFF000C #define TEEC_ERROR_COMMUNICATION 0xFFFF000E #define TEEC_ORIGIN_COMMS 0x00000002 @@ -93,6 +94,18 @@ struct amdtee_shm_data { u32 buf_id; }; +/** + * struct amdtee_ta_data - Keeps track of all TAs loaded in AMD Secure + * Processor + * @ta_handle: Handle to TA loaded in TEE + * @refcount: Reference count for the loaded TA + */ +struct amdtee_ta_data { + struct list_head list_node; + u32 ta_handle; + u32 refcount; +}; + #define LOWER_TWO_BYTE_MASK 0x0000FFFF /** diff --git a/drivers/tee/amdtee/call.c b/drivers/tee/amdtee/call.c index 096dd4d92d39..e10601417ea3 100644 --- a/drivers/tee/amdtee/call.c +++ b/drivers/tee/amdtee/call.c @@ -121,15 +121,69 @@ static int amd_params_to_tee_params(struct tee_param *tee, u32 count, return ret; } +static DEFINE_MUTEX(ta_refcount_mutex); +static struct list_head ta_list = LIST_HEAD_INIT(ta_list); + +static u32 get_ta_refcount(u32 ta_handle) +{ + struct amdtee_ta_data *ta_data; + u32 count = 0; + + /* Caller must hold a mutex */ + list_for_each_entry(ta_data, &ta_list, list_node) + if (ta_data->ta_handle == ta_handle) + return ++ta_data->refcount; + + ta_data = kzalloc(sizeof(*ta_data), GFP_KERNEL); + if (ta_data) { + ta_data->ta_handle = ta_handle; + ta_data->refcount = 1; + count = ta_data->refcount; + list_add(&ta_data->list_node, &ta_list); + } + + return count; +} + +static u32 put_ta_refcount(u32 ta_handle) +{ + struct amdtee_ta_data *ta_data; + u32 count = 0; + + /* Caller must hold a mutex */ + list_for_each_entry(ta_data, &ta_list, list_node) + if (ta_data->ta_handle == ta_handle) { + count = --ta_data->refcount; + if (count == 0) { + list_del(&ta_data->list_node); + kfree(ta_data); + break; + } + } + + return count; +} + int handle_unload_ta(u32 ta_handle) { struct tee_cmd_unload_ta cmd = {0}; - u32 status; + u32 status, count; int ret; if (!ta_handle) return -EINVAL; + mutex_lock(&ta_refcount_mutex); + + count = put_ta_refcount(ta_handle); + + if (count) { + pr_debug("unload ta: not unloading %u count %u\n", + ta_handle, count); + ret = -EBUSY; + goto unlock; + } + cmd.ta_handle = ta_handle; ret = psp_tee_process_cmd(TEE_CMD_ID_UNLOAD_TA, (void *)&cmd, @@ -137,8 +191,12 @@ int handle_unload_ta(u32 ta_handle) if (!ret && status != 0) { pr_err("unload ta: status = 0x%x\n", status); ret = -EBUSY; + } else { + pr_debug("unloaded ta handle %u\n", ta_handle); } +unlock: + mutex_unlock(&ta_refcount_mutex); return ret; } @@ -357,14 +415,23 @@ int handle_load_ta(void *data, u32 size, struct tee_ioctl_open_session_arg *arg) cmd.low_addr = lower_32_bits(blob); cmd.size = size; + mutex_lock(&ta_refcount_mutex); + ret = psp_tee_process_cmd(TEE_CMD_ID_LOAD_TA, (void *)&cmd, sizeof(cmd), &arg->ret); if (ret) { arg->ret_origin = TEEC_ORIGIN_COMMS; arg->ret = TEEC_ERROR_COMMUNICATION; - } else { - set_session_id(cmd.ta_handle, 0, &arg->session); + } else if (arg->ret == TEEC_SUCCESS) { + ret = get_ta_refcount(cmd.ta_handle); + if (!ret) { + arg->ret_origin = TEEC_ORIGIN_COMMS; + arg->ret = TEEC_ERROR_OUT_OF_MEMORY; + } else { + set_session_id(cmd.ta_handle, 0, &arg->session); + } } + mutex_unlock(&ta_refcount_mutex); pr_debug("load TA: TA handle = 0x%x, RO = 0x%x, ret = 0x%x\n", cmd.ta_handle, arg->ret_origin, arg->ret); diff --git a/drivers/tee/amdtee/core.c b/drivers/tee/amdtee/core.c index 8a6a8f30bb42..da6b88e80dc0 100644 --- a/drivers/tee/amdtee/core.c +++ b/drivers/tee/amdtee/core.c @@ -59,10 +59,9 @@ static void release_session(struct amdtee_session *sess) continue; handle_close_session(sess->ta_handle, sess->session_info[i]); + handle_unload_ta(sess->ta_handle); } - /* Unload Trusted Application once all sessions are closed */ - handle_unload_ta(sess->ta_handle); kfree(sess); } @@ -224,8 +223,6 @@ static void destroy_session(struct kref *ref) struct amdtee_session *sess = container_of(ref, struct amdtee_session, refcount); - /* Unload the TA from TEE */ - handle_unload_ta(sess->ta_handle); mutex_lock(&session_list_mutex); list_del(&sess->list_node); mutex_unlock(&session_list_mutex); @@ -238,7 +235,7 @@ int amdtee_open_session(struct tee_context *ctx, { struct amdtee_context_data *ctxdata = ctx->data; struct amdtee_session *sess = NULL; - u32 session_info; + u32 session_info, ta_handle; size_t ta_size; int rc, i; void *ta; @@ -259,11 +256,14 @@ int amdtee_open_session(struct tee_context *ctx, if (arg->ret != TEEC_SUCCESS) goto out; + ta_handle = get_ta_handle(arg->session); + mutex_lock(&session_list_mutex); sess = alloc_session(ctxdata, arg->session); mutex_unlock(&session_list_mutex); if (!sess) { + handle_unload_ta(ta_handle); rc = -ENOMEM; goto out; } @@ -277,6 +277,7 @@ int amdtee_open_session(struct tee_context *ctx, if (i >= TEE_NUM_SESSIONS) { pr_err("reached maximum session count %d\n", TEE_NUM_SESSIONS); + handle_unload_ta(ta_handle); kref_put(&sess->refcount, destroy_session); rc = -ENOMEM; goto out; @@ -289,12 +290,13 @@ int amdtee_open_session(struct tee_context *ctx, spin_lock(&sess->lock); clear_bit(i, sess->sess_mask); spin_unlock(&sess->lock); + handle_unload_ta(ta_handle); kref_put(&sess->refcount, destroy_session); goto out; } sess->session_info[i] = session_info; - set_session_id(sess->ta_handle, i, &arg->session); + set_session_id(ta_handle, i, &arg->session); out: free_pages((u64)ta, get_order(ta_size)); return rc; @@ -329,6 +331,7 @@ int amdtee_close_session(struct tee_context *ctx, u32 session) /* Close the session */ handle_close_session(ta_handle, session_info); + handle_unload_ta(ta_handle); kref_put(&sess->refcount, destroy_session); -- 2.17.1

4 years, 2 months

2
2
0 0

[GIT PULL] OP-TEE memref size check for v5.13

by Jens Wiklander

Hello arm-soc maintainers, Please pull this small patch for the OP-TEE driver to remove the invalid size check of outgoing memref parameters. This code path is only activated for a certain configuration of OP-TEE in secure world (CFG_CORE_DYN_SHM=n) so this problem isn't always visible. Thanks, Jens The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15: Linux 5.12-rc2 (2021-03-05 17:33:41 -0800) are available in the Git repository at: git://git.linaro.org/people/jens.wiklander/linux-tee.git/ tags/optee-memref-size-for-v5.13 for you to fetch changes up to c650b8dc7a7910eb25af0aac1720f778b29e679d: tee: optee: do not check memref size on return from Secure World (2021-03-30 10:44:50 +0200) ---------------------------------------------------------------- OP-TEE skip check of returned memref size ---------------------------------------------------------------- Jerome Forissier (1): tee: optee: do not check memref size on return from Secure World drivers/tee/optee/core.c | 10 ---------- 1 file changed, 10 deletions(-)

4 years, 2 months

2
1
0 0

[GIT PULL] OP-TEE tracepoints fix for v5.13

by Jens Wiklander

Hello arm-soc maintainers, The previous pull request for OP-TEE tracepoints introduced a build error when building whithout O=..., apparently many regression builds uses that option. Please pull this small fix for the build error. Thanks, Jens The following changes since commit 0101947dbcc3204f08fb5b69a21dbd4b1535cad6: tee: optee: add invoke_fn tracepoints (2021-03-15 12:04:01 +0100) are available in the Git repository at: git://git.linaro.org/people/jens.wiklander/linux-tee.git/ tags/optee-tracepoints-fix-for-v5.13 for you to fetch changes up to 7ccdcaace80810175bd20b2ece856b42edd43991: tee: optee: fix build error caused by recent optee tracepoints feature (2021-03-30 09:33:33 +0200) ---------------------------------------------------------------- Fixes build error for recently added OP-TEE tracepoints ---------------------------------------------------------------- Jisheng Zhang (1): tee: optee: fix build error caused by recent optee tracepoints feature drivers/tee/optee/Makefile | 3 +++ 1 file changed, 3 insertions(+)

4 years, 2 months

2
3
0 0

Re: [PATCH 1/1] tee: optee: do not check memref size on return from Secure World

by Sumit Garg

On Mon, 22 Mar 2021 at 16:11, Jerome Forissier via OP-TEE <op-tee(a)lists.trustedfirmware.org> wrote: > > When Secure World returns, it may have changed the size attribute of the > memory references passed as [in/out] parameters. The GlobalPlatform TEE > Internal Core API specification does not restrict the values that this > size can take. In particular, Secure World may increase the value to be > larger than the size of the input buffer to indicate that it needs more. > > Therefore, the size check in optee_from_msg_param() is incorrect and > needs to be removed. This fixes a number of failed test cases in the > GlobalPlatform TEE Initial Configuratiom Test Suite v2_0_0_0-2017_06_09 > when OP-TEE is compiled without dynamic shared memory support > (CFG_CORE_DYN_SHM=n). > > Suggested-by: Jens Wiklander <jens.wiklander(a)linaro.org> > Signed-off-by: Jerome Forissier <jerome(a)forissier.org> > --- > drivers/tee/optee/core.c | 10 ---------- > 1 file changed, 10 deletions(-) > Looks good to me. Reviewed-by: Sumit Garg <sumit.garg(a)linaro.org> -Sumit > diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c > index 319a1e701163..ddb8f9ecf307 100644 > --- a/drivers/tee/optee/core.c > +++ b/drivers/tee/optee/core.c > @@ -79,16 +79,6 @@ int optee_from_msg_param(struct tee_param *params, size_t num_params, > return rc; > p->u.memref.shm_offs = mp->u.tmem.buf_ptr - pa; > p->u.memref.shm = shm; > - > - /* Check that the memref is covered by the shm object */ > - if (p->u.memref.size) { > - size_t o = p->u.memref.shm_offs + > - p->u.memref.size - 1; > - > - rc = tee_shm_get_pa(shm, o, NULL); > - if (rc) > - return rc; > - } > break; > case OPTEE_MSG_ATTR_TYPE_RMEM_INPUT: > case OPTEE_MSG_ATTR_TYPE_RMEM_OUTPUT: > -- > 2.25.1 >

4 years, 2 months

2
1
0 0

Build breakage in next-20210330 due to optee_trace.h

by Pratyush Yadav

Hi, I recently rebased a dev branch on top of next-20210330 (4143e05b7b17) and I notice a build error from the optee driver: In file included from drivers/tee/optee/call.c:18: In file included from drivers/tee/optee/optee_trace.h:67: ./include/trace/define_trace.h:95:10: fatal error: './optee_trace.h' file not found #include TRACE_INCLUDE(TRACE_INCLUDE_FILE) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./include/trace/define_trace.h:90:32: note: expanded from macro 'TRACE_INCLUDE' # define TRACE_INCLUDE(system) __TRACE_INCLUDE(system) ^~~~~~~~~~~~~~~~~~~~~~~ ./include/trace/define_trace.h:87:34: note: expanded from macro '__TRACE_INCLUDE' # define __TRACE_INCLUDE(system) __stringify(TRACE_INCLUDE_PATH/system.h) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./include/linux/stringify.h:10:27: note: expanded from macro '__stringify' #define __stringify(x...) __stringify_1(x) ^~~~~~~~~~~~~~~~ ./include/linux/stringify.h:9:29: note: expanded from macro '__stringify_1' #define __stringify_1(x...) #x ^~ <scratch space>:135:1: note: expanded from here "./optee_trace.h" ^~~~~~~~~~~~~~~~~ 1 error generated. The config is attached. I am building using clang. $ clang --version clang version 11.1.0 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/bin -- Regards, Pratyush Yadav

4 years, 2 months

2
1
0 0

RE: [TF-A] Firmware FuSa workshop

by Miklos Balint

To += op-tee(a)lists.trustedfirmware.org<mailto:op-tee@lists.trustedfirmware.org> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of François Ozog via TF-A Sent: 26 March 2021 19:08 To: Heinrich Schuchardt <xypron.glpk(a)gmx.de> Cc: tf-a(a)lists.trustedfirmware.org; Boot Architecture Mailman List <boot-architecture(a)lists.linaro.org>; Ilias Apalodimas <ilias.apalodimas(a)linaro.org> Subject: Re: [TF-A] Firmware FuSa workshop Le ven. 26 mars 2021 à 18:42, Heinrich Schuchardt <xypron.glpk(a)gmx.de<mailto:xypron.glpk@gmx.de>> a écrit : On 26.03.21 16:05, François Ozog wrote: > Hi, > > > Linaro is conducting an opportunity assessment to make OP-TEE ready for > functional safety sensitive environments. The goal is to present a plan to > Linaro members by the end of July 2021. > > The scope of the research is somewhat bigger because we can’t think of > OP-TEE without thinking of Trusted Firmware and Hafnium. The plan will > though not address those (unless we recognize we have to). We don’t think > U-Boot shall be part of the picture but we are welcoming contradictory > points of views. Hello François, Some boards boot via SPL->TF-A->U-Boot. Here U-Boot's SPL is relevant for OP-TEE's security. U-Boot can save variables via OP-TEE (implemented by Ilias). In this case OP-TEE has an implication on secure boot. I fully understand that these scenarios are not in the focus of the workshop. it may if companies have this particular flow in mind for safety certification. Our goal is not to make all boot flows safety ready but to identify which ones we need to consider. And the workshop may help in this identification. Best regards Heinrich > > We are organizing a 2 hours workshop on April 15th 9am CET to mostly hear > about use cases and ideas about Long Term Support requirements . We will > present the state of the research. > > The first use case is booting a safety certified type-1 hypervisor (open > source or commercial is irrelevant). > > But we know there are many more: please be ready to contribute. > > We think of more radical use cases: a safety payload is actually loaded as > a Secure Partition on top of Hafnium with OP-TEE or Zephyr used as a device > backends. In other words, Trust Zone hosts both safety and security worlds > , EL3 being the « software root of trust » pivot world. In those cases, > some cores never go out of secure state… > > > Agenda (to be refined) > > - > > Vision > - > > State of the research > <https://docs.google.com/presentation/u/0/d/1jWqu39gCF-5XzbFkodXsiVNJJLUN88B…> > - > > Use cases discussion > - > > What is the right scope? > - > > “Who do what” discussion (LTS, archiving...) > - > > Safety personnel (Linaro and contractors) discussion > - > > Other considerations from participants? > - > > Community organizations and funding? > - > > Closing and next steps > > > Should you want to participate and have not yet received an invite, please > contact me directly. > > Cordially, > > François-Frédéric > > PS: Please reach out should you want another date with a time compatible > with more time zones. This alternate date is not guaranteed though. > > -- [https://drive.google.com/a/linaro.org/uc?id=0BxTAygkus3RgQVhuNHMwUi1mYWc&ex…] François-Frédéric Ozog | Director Linaro Edge & Fog Computing Group T: +33.67221.6485 francois.ozog(a)linaro.org<mailto:francois.ozog@linaro.org> | Skype: ffozog

4 years, 2 months

1
0
0 0

Re: Possible OB1 bug in imx_csu.c

by Jerome Forissier

On 2/22/21 11:26 AM, Jerome Forissier via OP-TEE wrote: > Hi Robert, > > On 2/22/21 11:01 AM, Robert Delien via OP-TEE wrote: >> Hi, >> >> In imx_csu.c, the Central Security Unit's CSU_CSL*n* registers are set, >> configuring access privileges for different peripherals. These registers >> range from CSU_CSL0 (@ 0x021c0000) to CSU_CSL39 (@ 0x021c009c). >> >> The different i.MX6 platform variants each have their individual tables, >> filled with sets of CSL index and register value, terminated by a sentinel >> set with the index set to -1. (the reason for the parentheses around -1 >> espaces me) >> >> in .../core/arch/arm/plat-imx/drivers/imx_csu.c:csu_init()@115, a while >> loop runs through this aforementioned table, setting the CSL registers >> according to the table. However, this loop loops on CSL index values > 0: >> while (csu_setting->csu_index *>* 0) { >> io_write32(csu_base + (csu_setting->csu_index * 4), >> csu_setting->value); >> >> csu_setting++; >> } >> I think it should loop on CSL index values >= 0, because index 0 is a valid >> index, utilized for the PWM peripherals. (I also think csl_index is a more >> descriptive name, but that's besides the point). >> >> I have attached a patch for his. > > It does look like a genuine bug to me, but I will let the i.MX expert > comment further. Unfortunately, the OP-TEE ML strips attachments. Would > you mind creating a GitHub pull request [1] (preferred method), or send > the patch inline? > > [1] https://github.com/OP-TEE/optee_os/pulls > > Thanks, > https://github.com/OP-TEE/optee_os/pull/4511

4 years, 2 months

1
0
0 0

Re: [TF-A] EHF + OPTEE on ARM64

by Peng Fan

Hi Sandeep, I just noticed that your PR is abandoned. Will you resend your PR? Thanks, Peng. ________________________________ From: OP-TEE <op-tee-bounces(a)lists.trustedfirmware.org> on behalf of Peng Fan via OP-TEE <op-tee(a)lists.trustedfirmware.org> Sent: Tuesday, March 23, 2021 10:14 AM To: Sandeep Tripathy <sandeep.tripathy(a)broadcom.com> Cc: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org>; op-tee(a)lists.trustedfirmware.org <op-tee(a)lists.trustedfirmware.org> Subject: RE: [TF-A] EHF + OPTEE on ARM64 Hi Sandeep > Subject: Re: [TF-A] EHF + OPTEE on ARM64 > > Hi Peng, > > 1-Asynchronous preemption of SP: > The long route is to make changes in the dispatcher and the > corresponding SPD implementation to have synchronous preemption. > ie: OP-TEE dispatcher will implement a G1NS (fiq) handler and invoke > an entry of OP-TEE synchronously. OP-TEE will save the thread context > and return. > I did some POC but the complexity and effort to generalise was not > justified by our requirement at that point especially envisioning the > movement to SPMD in future. > > 2-Synchronous preemption of SP: > ref: > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr… > > I used this approach instead to unblock OP-TEE work alongside EHF. > This serves the purpose without changing the routing model with a > limitation that non yielding/fast SMC can > not be preempted. And ofcourse OP-TEE can mask G0 interrupt in > anycase. But I think this is sufficient for your purpose. > > Please feedback if the above patch works for you. I was trying using #ifndef SPD_opteed to wrap the secure stuff. Thanks for your patch. I test on i.MX8MM-EVK, it works well. Thanks, Peng. > > Thanks > Sandeep > > On Mon, Mar 22, 2021 at 2:43 PM Peng Fan via TF-A > <tf-a(a)lists.trustedfirmware.org> wrote: > > > > Hi Achin, > > > > > > > > We are using SDEI for Jailhouse hypervisor to minimize interrupt latency, > however we also wanna use OP-TEE when SDEI enabled. > > > > > > > > So I wanna how to make both work together. > > > > > > > > Thanks, > > > > Peng. > > > > > > > > From: Achin Gupta [mailto:Achin.Gupta@arm.com] > > Sent: 2021年3月17日 17:59 > > To: Peng Fan <peng.fan(a)nxp.com>; Jens Wiklander > <jens.wiklander(a)linaro.org> > > Cc: op-tee(a)lists.trustedfirmware.org; tf-a(a)lists.trustedfirmware.org > > Subject: Re: EHF + OPTEE on ARM64 > > > > > > > > Hi Peng, > > > > > > > > +TF-A folk. > > > > > > > > My 0.02$. > > > > > > > > What is the problem you are trying to solve? Why do you need to run > OP-TEE and EHF together? EHF was originally written to support a S-EL0 SP > that is managed directly by TF-A in EL3 (TF-A folk can chime in). > > > > > > > > The SP could perform RAS error handling for which it needs the EHF. The EHF > triages asynchronous exceptions and hands RAS errors to the SP for further > handling. > > > > > > > > This is just one use case but there is no Trusted OS in these configurations. > > > > > > > > So, it would help to understand the requirement. > > > > > > > > cheers, > > > > Achin > > > > > > > > ________________________________ > > > > From: OP-TEE <op-tee-bounces(a)lists.trustedfirmware.org> on behalf of > Jens Wiklander via OP-TEE <op-tee(a)lists.trustedfirmware.org> > > Sent: 17 March 2021 09:23 > > To: Peng Fan <peng.fan(a)nxp.com> > > Cc: op-tee(a)lists.trustedfirmware.org <op-tee(a)lists.trustedfirmware.org> > > Subject: Re: EHF + OPTEE on ARM64 > > > > > > > > On Wed, Mar 17, 2021 at 9:43 AM Peng Fan <peng.fan(a)nxp.com> wrote: > > > > > > > Subject: Re: EHF + OPTEE on ARM64 > > > > > > > > On Wed, Mar 17, 2021 at 9:02 AM Peng Fan <peng.fan(a)nxp.com> > wrote: > > > > > > > > > > > Subject: Re: EHF + OPTEE on ARM64 > > > > > > > > > > > > On Wed, Mar 17, 2021 at 8:41 AM Peng Fan <peng.fan(a)nxp.com> > wrote: > > > > > > > > > > > > > > > Subject: Re: EHF + OPTEE on ARM64 > > > > > > > > > > > > > > > > On Tue, Mar 16, 2021 at 11:08 AM Peng Fan > <peng.fan(a)nxp.com> > > > > wrote: > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > In bl31/ehf.c, there are following two lines, per my > > > > > > > > > understanding, when cpu is in secure world, the non-secure > > > > > > > > > interrupt as FIQ(GICv3) will be directly catched by EL3, not > S-EL1 > > > > > > > > > /* Route EL3 interrupts when in Secure and > Non-secure. > > > > */ > > > > > > > > > set_interrupt_rm_flag(flags, NON_SECURE); > > > > > > > > > set_interrupt_rm_flag(flags, SECURE); > > > > > > > > > > > > > > > > > > So this will conflict with OP-TEE, because OP-TEE needs catch > > > > > > > > > NS-interrupt as FIQ in S-EL1 world. > > > > > > > > > > > > > > > > In the case of GICv3, OP-TEE is configured to receive the > > > > > > > > non-secure interrupts as FIQ and secure interrupts as IRQ. See > > > > CFG_ARM_GICV3. > > > > > > > > > > > > > > But EHF needs NS-interrupt FIQ be catched by EL3 if I understand > > > > > > > correct, per " set_interrupt_rm_flag(flags, SECURE);" > > > > > > > > > > > > > > So currently EHF could not work together with OP-TEE, right? > > > > > > > > > > > > To be honest, I'm not completely sure what EHF does. From OP-TEE > > > > > > point of view we expect to receive the non-secure interrupts as a > > > > > > way of doing a controlled exit. This allows OP-TEE to resume > > > > > > execution with a different core on re-entry. If EL3 takes the > > > > > > non-secure interrupts directly it will have to make sure to only > re-enter > > > > OP-TEE on this core as a return from exception. > > > > > > > > > > Is this easy to be achieved? > > > > > > > > I don't know, it depends on what you intend to do with this non-secure > > > > interrupt. If it's handled at EL3 and then there's a return from exception > back > > > > to S-EL1 there's likely no harm done. But if there's a world switch > involved > > > > there might be trouble, OP-TEE might not be in a suitable state for a > world > > > > switch. > > > > > > > > > > > > > > Or by using opteed_sel1_interrupt_handler, could we have similar > > > > > behavior to allow the other core resume execution? > > > > > > > > Only OP-TEE itself can make a controlled exit as there's an internal state > to > > > > maintain. Currently that's signalled with a non-secure interrupt. > > > > > > > > > Per EHF, > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrustedfi… > andling.html?highlight=Exception%20Handling%20Framework > > > On GICv3 systems, when executing in S-EL1, pending Non-secure > interrupts of > > > sufficient priority are signalled as FIQs, and therefore will be routed to > EL3. > > > As a result, S-EL1 software cannot expect to handle Non-secure interrupts > at S-EL1. > > > Essentially, this deprecates the routing mode described as CSS=0, TEL3=0. > > > > > > In order for S-EL1 software to handle Non-secure interrupts while having > EHF enabled, > > > the dispatcher must adopt a model where Non-secure interrupts are > received at EL3, > > > but are then synchronously handled over to S-EL1. > > > > > > The issue to me here how to synchronously handled over to S-EL1 and not > break optee. > > > > I understand. OP-TEE is masking interrupts in some critical sections, > > while in such a state OP-TEE cannot handle any asynchronous interrupt. > > Temporarily masking interrupts is normally a quick operation so we do > > it in quite a few places. > > So the crux of the problem is to make sure that OP-TEE is in a state > > where it can make a controlled exit. I don't have any good ideas for > > this right now. > > > > Cheers, > > Jens > > > > -- > > TF-A mailing list > > TF-A(a)lists.trustedfirmware.org > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

4 years, 2 months

1
0
0 0

[PATCH 0/6] 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 v4 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/20210212154614.38604-1-sudeep.holl… [3] git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git v5.11/ffa Jens Wiklander (6): tee: add sec_world_id to struct tee_shm optee: simplify optee_release() optee: sync optee_msg.h and optee_rpc_cmd.h optee: refactor driver with internal callbacks optee: add a FF-A memory pool optee: add FF-A support drivers/tee/optee/call.c | 327 +++++++++++--- drivers/tee/optee/core.c | 698 +++++++++++++++++++++++++----- drivers/tee/optee/optee_ffa.h | 153 +++++++ drivers/tee/optee/optee_msg.h | 168 ++----- drivers/tee/optee/optee_private.h | 88 +++- drivers/tee/optee/optee_rpc_cmd.h | 333 ++++++++++++++ drivers/tee/optee/rpc.c | 169 +++++++- drivers/tee/optee/shm_pool.c | 65 ++- drivers/tee/optee/shm_pool.h | 1 + include/linux/tee_drv.h | 7 +- 10 files changed, 1685 insertions(+), 324 deletions(-) create mode 100644 drivers/tee/optee/optee_ffa.h create mode 100644 drivers/tee/optee/optee_rpc_cmd.h base-commit: 31ef391700953fb59ea8755ea38c6085bdec380e -- 2.25.1

4 years, 2 months

1
6
0 0

2025

2024

2023

2022

2021

2020

OP-TEE