- OP-TEE - lists.trustedfirmware.org

[GIT PULL] Fix uninitialized variable in OP-TEE driver for v6.3

by Jens Wiklander

Hello arm-soc maintainers, Please pull this small patch fixing an unintialized variable in the OP-TEE driver. The error has been reported recently by the kernel test robot. I realize that this is late for v6.3, please queue this for v6.4 instead if v6.3 isn't possible. Thanks, Jens The following changes since commit eeac8ede17557680855031c6f305ece2378af326: Linux 6.3-rc2 (2023-03-12 16:36:44 -0700) are available in the Git repository at: https://git.linaro.org/people/jens.wiklander/linux-tee.git tags/optee-async-notif-fix-for-v6.3 for you to fetch changes up to 654d0310007146fae87b0c1a68f81e53ad519b14: optee: fix uninited async notif value (2023-04-20 14:52:25 +0200) ---------------------------------------------------------------- Fixes an uninitialized variable in OP-TEE driver ---------------------------------------------------------------- Etienne Carriere (1): optee: fix uninited async notif value drivers/tee/optee/smc_abi.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)

3 years, 1 month

1
1
0 0

[PATCH v2 1/1] tee: amdtee: Add return_origin to 'struct tee_cmd_load_ta'

by Rijo Thomas

After TEE has completed processing of TEE_CMD_ID_LOAD_TA, set proper value in 'return_origin' argument passed by open_session() call. To do so, add 'return_origin' field to the structure tee_cmd_load_ta. The Trusted OS shall update return_origin as part of TEE processing. This change to 'struct tee_cmd_load_ta' interface requires a similar update in AMD-TEE Trusted OS's TEE_CMD_ID_LOAD_TA interface. This patch has been verified on Phoenix Birman setup. On older APUs, return_origin value will be 0. Cc: stable(a)vger.kernel.org Fixes: 757cc3e9ff1d ("tee: add AMD-TEE driver") Tested-by: Sourabh Das <sourabh.das(a)amd.com> Signed-off-by: Rijo Thomas <Rijo-john.Thomas(a)amd.com> --- v2: * Added Fixes tag. drivers/tee/amdtee/amdtee_if.h | 10 ++++++---- drivers/tee/amdtee/call.c | 30 +++++++++++++++++------------- 2 files changed, 23 insertions(+), 17 deletions(-) diff --git a/drivers/tee/amdtee/amdtee_if.h b/drivers/tee/amdtee/amdtee_if.h index ff48c3e47375..e2014e21530a 100644 --- a/drivers/tee/amdtee/amdtee_if.h +++ b/drivers/tee/amdtee/amdtee_if.h @@ -118,16 +118,18 @@ struct tee_cmd_unmap_shared_mem { /** * struct tee_cmd_load_ta - load Trusted Application (TA) binary into TEE - * @low_addr: [in] bits [31:0] of the physical address of the TA binary - * @hi_addr: [in] bits [63:32] of the physical address of the TA binary - * @size: [in] size of TA binary in bytes - * @ta_handle: [out] return handle of the loaded TA + * @low_addr: [in] bits [31:0] of the physical address of the TA binary + * @hi_addr: [in] bits [63:32] of the physical address of the TA binary + * @size: [in] size of TA binary in bytes + * @ta_handle: [out] return handle of the loaded TA + * @return_origin: [out] origin of return code after TEE processing */ struct tee_cmd_load_ta { u32 low_addr; u32 hi_addr; u32 size; u32 ta_handle; + u32 return_origin; }; /** diff --git a/drivers/tee/amdtee/call.c b/drivers/tee/amdtee/call.c index e8cd9aaa3467..e9b63dcb3194 100644 --- a/drivers/tee/amdtee/call.c +++ b/drivers/tee/amdtee/call.c @@ -423,19 +423,23 @@ int handle_load_ta(void *data, u32 size, struct tee_ioctl_open_session_arg *arg) if (ret) { arg->ret_origin = TEEC_ORIGIN_COMMS; arg->ret = TEEC_ERROR_COMMUNICATION; - } else if (arg->ret == TEEC_SUCCESS) { - ret = get_ta_refcount(load_cmd.ta_handle); - if (!ret) { - arg->ret_origin = TEEC_ORIGIN_COMMS; - arg->ret = TEEC_ERROR_OUT_OF_MEMORY; - - /* Unload the TA on error */ - unload_cmd.ta_handle = load_cmd.ta_handle; - psp_tee_process_cmd(TEE_CMD_ID_UNLOAD_TA, - (void *)&unload_cmd, - sizeof(unload_cmd), &ret); - } else { - set_session_id(load_cmd.ta_handle, 0, &arg->session); + } else { + arg->ret_origin = load_cmd.return_origin; + + if (arg->ret == TEEC_SUCCESS) { + ret = get_ta_refcount(load_cmd.ta_handle); + if (!ret) { + arg->ret_origin = TEEC_ORIGIN_COMMS; + arg->ret = TEEC_ERROR_OUT_OF_MEMORY; + + /* Unload the TA on error */ + unload_cmd.ta_handle = load_cmd.ta_handle; + psp_tee_process_cmd(TEE_CMD_ID_UNLOAD_TA, + (void *)&unload_cmd, + sizeof(unload_cmd), &ret); + } else { + set_session_id(load_cmd.ta_handle, 0, &arg->session); + } } } mutex_unlock(&ta_refcount_mutex); -- 2.25.1

3 years, 1 month

3
2
0 0

Linaro OP-TEE Contribution (LOC) monthly meeting May 23

by Jens Wiklander

Hi, Tomorrow it's time for another LOC monthly meeting. For time and connection details see the calendar at https://www.trustedfirmware.org/meetings/ We are considering bumping the major version number of OP-TEE to 4 and removing old and unused or not-so-frequently tested compatibility code. We'll switch to MbedTLS 3.4 instead of the old 2.x branch. Any other topics? Thanks, Jens

3 years, 1 month

1
0
0 0

Re: [PATCH] tee: add FOLL_LONGTERM for CMA case when alloc shm

by David Hildenbrand

On 18.05.23 08:40, Xiaoming Ding (丁晓明) wrote: > From 35fd062d5cbc4d182eee0183843cd6350d126788 Mon Sep 17 00:00:00 2001 > From: Xiaoming Ding <xiaoming.ding(a)mediatek.com> > Date: Wed, 10 May 2023 10:15:23 +0800 > Subject: [PATCH v2] tee: add FOLL_LONGTERM for CMA case when alloc shm > > CMA is widely used on insufficient memory platform for > secure media playback case, and FOLL_LONGTERM will > avoid tee_shm alloc pages from CMA region. > without FOLL_LONGTERM, CMA region may alloc failed since > tee_shm has a chance to use it in advance. > > modify is verified on OPTEE XTEST and kinds of secure + clear playback > > > Fixes: 033ddf12bcf5 ("tee: add register user memory") > Signed-off-by: Xiaoming Ding <xiaoming.ding(a)mediatek.com> > --- > v1 -> v2: take off the ifdef and apply FOLL_LONGTERM by default > > drivers/tee/tee_shm.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/tee/tee_shm.c b/drivers/tee/tee_shm.c > index 673cf0359494..38878e549ca4 100644 > --- a/drivers/tee/tee_shm.c > +++ b/drivers/tee/tee_shm.c > @@ -257,7 +257,7 @@ register_shm_helper(struct tee_context *ctx, > unsigned long addr, > } > > if (flags & TEE_SHM_USER_MAPPED) > - rc = pin_user_pages_fast(start, num_pages, FOLL_WRITE, > + rc = pin_user_pages_fast(start, num_pages, FOLL_WRITE | > FOLL_LONGTERM, > shm->pages); > else > rc = shm_get_kernel_pages(start, num_pages, shm- >> pages); I didn't dive deeply into that code, but I can spot that we can end up long-term pinning multiple pages -- possibly unbound or is there any sane limit on the number of pages? Take a look at io_uring/rsrc.c and how we account long-term pinned pages against user->locked_vm/ctx->mm_account->pinned_vm in io_account_mem(). If user space could only end up pinning one or two pages via that interface, ok. But it looks like this interface could be abused to create real real trouble by unprivileged users that should be able to long-term pin that many pages. Am I missing something important (i.e., interface is only accessible by privileged users) or should there be proper accounting and RLIMIT_MEMLOCK checks? -- Thanks, David / dhildenb

3 years, 1 month

2
1
0 0

[PATCH v8 0/4] tee: introduce TEE system session

by Etienne Carriere

This series introduces TEE system sessions for TEE service sessions that require TEE to provision resources to prevent deadlock when clients call the TEE. This deadlock situation can happen when a TEE service is used by low level system resources as for example when Linux kernel uses SCMI service embedded in TEE for clock, reset, regulator, etc... controls. This case is detailled in patch 3/4: > This feature is needed to prevent a system deadlock when several TEE > client applications invoke TEE, consuming all TEE thread contexts > available in the secure world. The deadlock can happen in the OP-TEE > driver for example if all these TEE threads issue an RPC call from TEE > to Linux OS to access an eMMC RPMB partition (TEE secure storage) which > device clock or regulator controller is accessed through an OP-TEE SCMI > services. In that case, Linux SCMI driver must reach OP-TEE SCMI > service without waiting until one of the consumed TEE threads is freed. Etienne Carriere (4): tee: optee: system call property tee: system session tee: optee: support tracking system threads firmware: arm_scmi: optee: use optee system invocation drivers/firmware/arm_scmi/optee.c | 4 + drivers/tee/optee/call.c | 155 +++++++++++++++++++++++++++--- drivers/tee/optee/core.c | 5 +- drivers/tee/optee/ffa_abi.c | 13 +-- drivers/tee/optee/optee_private.h | 39 +++++++- drivers/tee/optee/smc_abi.c | 31 ++++-- drivers/tee/tee_core.c | 8 ++ include/linux/tee_drv.h | 16 +++ 8 files changed, 235 insertions(+), 36 deletions(-) --- No change since v7 Changes since v6: - Added this cover letter missing in previous patch series revisions. -- 2.25.1

3 years, 1 month

2
7
0 0

[PATCH v6 1/4] tee: optee: system call property

by Etienne Carriere

Adds an argument to do_call_with_arg() handler to tell whether the call is a system call or nor. This change always sets this info to false hence no functional change. This change prepares management of system invocation proposed in a later change. 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> --- No changes since v5 Changes since v4: - New change, extracted from PATCH v4 1/2 (tee: system invocation") and revised to cover preparatory changes in optee driver for system session support with contribution from Jens. --- drivers/tee/optee/call.c | 22 ++++++++++++++++------ drivers/tee/optee/core.c | 5 +++-- drivers/tee/optee/ffa_abi.c | 3 ++- drivers/tee/optee/optee_private.h | 7 +++++-- drivers/tee/optee/smc_abi.c | 9 +++++---- 5 files changed, 31 insertions(+), 15 deletions(-) diff --git a/drivers/tee/optee/call.c b/drivers/tee/optee/call.c index df5fb5410b72..dba5339b61ae 100644 --- a/drivers/tee/optee/call.c +++ b/drivers/tee/optee/call.c @@ -328,7 +328,8 @@ int optee_open_session(struct tee_context *ctx, goto out; } - if (optee->ops->do_call_with_arg(ctx, shm, offs)) { + if (optee->ops->do_call_with_arg(ctx, shm, offs, + sess->use_sys_thread)) { msg_arg->ret = TEEC_ERROR_COMMUNICATION; msg_arg->ret_origin = TEEC_ORIGIN_COMMS; } @@ -360,7 +361,8 @@ int optee_open_session(struct tee_context *ctx, return rc; } -int optee_close_session_helper(struct tee_context *ctx, u32 session) +int optee_close_session_helper(struct tee_context *ctx, u32 session, + bool system_thread) { struct optee *optee = tee_get_drvdata(ctx->teedev); struct optee_shm_arg_entry *entry; @@ -374,7 +376,7 @@ int optee_close_session_helper(struct tee_context *ctx, u32 session) msg_arg->cmd = OPTEE_MSG_CMD_CLOSE_SESSION; msg_arg->session = session; - optee->ops->do_call_with_arg(ctx, shm, offs); + optee->ops->do_call_with_arg(ctx, shm, offs, system_thread); optee_free_msg_arg(ctx, entry, offs); @@ -385,6 +387,7 @@ int optee_close_session(struct tee_context *ctx, u32 session) { struct optee_context_data *ctxdata = ctx->data; struct optee_session *sess; + bool system_thread; /* Check that the session is valid and remove it from the list */ mutex_lock(&ctxdata->mutex); @@ -394,9 +397,10 @@ int optee_close_session(struct tee_context *ctx, u32 session) mutex_unlock(&ctxdata->mutex); if (!sess) return -EINVAL; + system_thread = sess->use_sys_thread; kfree(sess); - return optee_close_session_helper(ctx, session); + return optee_close_session_helper(ctx, session, system_thread); } int optee_invoke_func(struct tee_context *ctx, struct tee_ioctl_invoke_arg *arg, @@ -408,12 +412,15 @@ int optee_invoke_func(struct tee_context *ctx, struct tee_ioctl_invoke_arg *arg, struct optee_msg_arg *msg_arg; struct optee_session *sess; struct tee_shm *shm; + bool system_thread; u_int offs; int rc; /* Check that the session is valid */ mutex_lock(&ctxdata->mutex); sess = find_session(ctxdata, arg->session); + if (sess) + system_thread = sess->use_sys_thread; mutex_unlock(&ctxdata->mutex); if (!sess) return -EINVAL; @@ -432,7 +439,7 @@ int optee_invoke_func(struct tee_context *ctx, struct tee_ioctl_invoke_arg *arg, if (rc) goto out; - if (optee->ops->do_call_with_arg(ctx, shm, offs)) { + if (optee->ops->do_call_with_arg(ctx, shm, offs, system_thread)) { msg_arg->ret = TEEC_ERROR_COMMUNICATION; msg_arg->ret_origin = TEEC_ORIGIN_COMMS; } @@ -457,12 +464,15 @@ int optee_cancel_req(struct tee_context *ctx, u32 cancel_id, u32 session) struct optee_shm_arg_entry *entry; struct optee_msg_arg *msg_arg; struct optee_session *sess; + bool system_thread; struct tee_shm *shm; u_int offs; /* Check that the session is valid */ mutex_lock(&ctxdata->mutex); sess = find_session(ctxdata, session); + if (sess) + system_thread = sess->use_sys_thread; mutex_unlock(&ctxdata->mutex); if (!sess) return -EINVAL; @@ -474,7 +484,7 @@ int optee_cancel_req(struct tee_context *ctx, u32 cancel_id, u32 session) msg_arg->cmd = OPTEE_MSG_CMD_CANCEL; msg_arg->session = session; msg_arg->cancel_id = cancel_id; - optee->ops->do_call_with_arg(ctx, shm, offs); + optee->ops->do_call_with_arg(ctx, shm, offs, system_thread); optee_free_msg_arg(ctx, entry, offs); return 0; diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c index 2a258bd3b6b5..d01ca47f7bde 100644 --- a/drivers/tee/optee/core.c +++ b/drivers/tee/optee/core.c @@ -129,7 +129,8 @@ int optee_open(struct tee_context *ctx, bool cap_memref_null) static void optee_release_helper(struct tee_context *ctx, int (*close_session)(struct tee_context *ctx, - u32 session)) + u32 session, + bool system_thread)) { struct optee_context_data *ctxdata = ctx->data; struct optee_session *sess; @@ -141,7 +142,7 @@ static void optee_release_helper(struct tee_context *ctx, list_for_each_entry_safe(sess, sess_tmp, &ctxdata->sess_list, list_node) { list_del(&sess->list_node); - close_session(ctx, sess->session_id); + close_session(ctx, sess->session_id, sess->use_sys_thread); kfree(sess); } kfree(ctxdata); diff --git a/drivers/tee/optee/ffa_abi.c b/drivers/tee/optee/ffa_abi.c index 0828240f27e6..52cec9d06041 100644 --- a/drivers/tee/optee/ffa_abi.c +++ b/drivers/tee/optee/ffa_abi.c @@ -612,7 +612,8 @@ static int optee_ffa_yielding_call(struct tee_context *ctx, */ static int optee_ffa_do_call_with_arg(struct tee_context *ctx, - struct tee_shm *shm, u_int offs) + struct tee_shm *shm, u_int offs, + bool system_thread) { struct ffa_send_direct_data data = { .data0 = OPTEE_FFA_YIELDING_CALL_WITH_ARG, diff --git a/drivers/tee/optee/optee_private.h b/drivers/tee/optee/optee_private.h index 72685ee0d53f..3da7960ab34a 100644 --- a/drivers/tee/optee/optee_private.h +++ b/drivers/tee/optee/optee_private.h @@ -154,7 +154,8 @@ struct optee; */ struct optee_ops { int (*do_call_with_arg)(struct tee_context *ctx, - struct tee_shm *shm_arg, u_int offs); + struct tee_shm *shm_arg, u_int offs, + bool system_thread); int (*to_msg_param)(struct optee *optee, struct optee_msg_param *msg_params, size_t num_params, const struct tee_param *params); @@ -204,6 +205,7 @@ struct optee { struct optee_session { struct list_head list_node; u32 session_id; + bool use_sys_thread; }; struct optee_context_data { @@ -252,7 +254,8 @@ 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_close_session_helper(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); int optee_invoke_func(struct tee_context *ctx, struct tee_ioctl_invoke_arg *arg, struct tee_param *param); diff --git a/drivers/tee/optee/smc_abi.c b/drivers/tee/optee/smc_abi.c index 49702cb08f4f..56ebbb96ac97 100644 --- a/drivers/tee/optee/smc_abi.c +++ b/drivers/tee/optee/smc_abi.c @@ -507,7 +507,7 @@ static int optee_shm_register(struct tee_context *ctx, struct tee_shm *shm, msg_arg->params->u.tmem.buf_ptr = virt_to_phys(pages_list) | (tee_shm_get_page_offset(shm) & (OPTEE_MSG_NONCONTIG_PAGE_SIZE - 1)); - if (optee->ops->do_call_with_arg(ctx, shm_arg, 0) || + if (optee->ops->do_call_with_arg(ctx, shm_arg, 0, false) || msg_arg->ret != TEEC_SUCCESS) rc = -EINVAL; @@ -550,7 +550,7 @@ static int optee_shm_unregister(struct tee_context *ctx, struct tee_shm *shm) msg_arg->params[0].attr = OPTEE_MSG_ATTR_TYPE_RMEM_INPUT; msg_arg->params[0].u.rmem.shm_ref = (unsigned long)shm; - if (optee->ops->do_call_with_arg(ctx, shm_arg, 0) || + if (optee->ops->do_call_with_arg(ctx, shm_arg, 0, false) || msg_arg->ret != TEEC_SUCCESS) rc = -EINVAL; out: @@ -885,7 +885,8 @@ static void optee_handle_rpc(struct tee_context *ctx, * Returns return code from secure world, 0 is OK */ static int optee_smc_do_call_with_arg(struct tee_context *ctx, - struct tee_shm *shm, u_int offs) + struct tee_shm *shm, u_int offs, + bool system_thread) { struct optee *optee = tee_get_drvdata(ctx->teedev); struct optee_call_waiter w; @@ -977,7 +978,7 @@ static int simple_call_with_arg(struct tee_context *ctx, u32 cmd) return PTR_ERR(msg_arg); msg_arg->cmd = cmd; - optee_smc_do_call_with_arg(ctx, shm, offs); + optee_smc_do_call_with_arg(ctx, shm, offs, false); optee_free_msg_arg(ctx, entry, offs); return 0; -- 2.25.1

3 years, 1 month

2
22
0 0

[PATCH] plat-rzn1: increase DDR size to 1GB

by Ralph Siemsen

There are now some RZ/N1 devices with 1GB rather than 256MB. The first-stage bootloader does not support passing a DT to OP-TEE, so static values are set at compile time. Increase the DDR size so as to avoid OP-TEE calls failing with TEEC_ERROR_OUT_OF_MEMORY. Signed-off-by: Ralph Siemsen <ralph.siemsen(a)linaro.org> --- core/arch/arm/plat-rzn1/platform_config.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/core/arch/arm/plat-rzn1/platform_config.h b/core/arch/arm/plat-rzn1/platform_config.h index a6340bb33..eb709c62f 100644 --- a/core/arch/arm/plat-rzn1/platform_config.h +++ b/core/arch/arm/plat-rzn1/platform_config.h @@ -11,7 +11,7 @@ /* DRAM */ #define DRAM_BASE 0x80000000 -#define DRAM_SIZE 0x10000000 +#define DRAM_SIZE 0x40000000 /* GIC */ #define GIC_BASE 0x44100000 -- 2.25.1

3 years, 1 month

3
3
0 0

[PATCH v7 0/4] tee: introduce TEE system session

by Etienne Carriere

This series introduces TEE system sessions for TEE service sessions that require TEE to provision resources to prevent deadlock when clients call the TEE. This deadlock situation can happen when a TEE service is used by low level system resources as for example when Linux kernel uses SCMI service embedded in TEE for clock, reset, regulator, etc... controls. This case is detailled in patch 3/4: > This feature is needed to prevent a system deadlock when several TEE > client applications invoke TEE, consuming all TEE thread contexts > available in the secure world. The deadlock can happen in the OP-TEE > driver for example if all these TEE threads issue an RPC call from TEE > to Linux OS to access an eMMC RPMB partition (TEE secure storage) which > device clock or regulator controller is accessed through an OP-TEE SCMI > services. In that case, Linux SCMI driver must reach OP-TEE SCMI > service without waiting until one of the consumed TEE threads is freed. Etienne Carriere (4): tee: optee: system call property tee: system session tee: optee: support tracking system threads firmware: arm_scmi: optee: use optee system invocation drivers/firmware/arm_scmi/optee.c | 4 + drivers/tee/optee/call.c | 150 +++++++++++++++++++++++++++--- drivers/tee/optee/core.c | 5 +- drivers/tee/optee/ffa_abi.c | 13 +-- drivers/tee/optee/optee_private.h | 20 +++- drivers/tee/optee/smc_abi.c | 31 ++++-- drivers/tee/tee_core.c | 8 ++ include/linux/tee_drv.h | 16 ++++ 8 files changed, 211 insertions(+), 36 deletions(-) --- Changes since v6: - Added this cover letter missing in previous patch series revisions. -- 2.25.1

3 years, 1 month

1
4
0 0

[PATCH 1/1] tee: amdtee: Add return_origin to 'struct tee_cmd_load_ta'

by Rijo Thomas

After TEE has completed processing of TEE_CMD_ID_LOAD_TA, set proper value in 'return_origin' argument passed by open_session() call. To do so, add 'return_origin' field to the structure tee_cmd_load_ta. The Trusted OS shall update return_origin as part of TEE processing. This change to 'struct tee_cmd_load_ta' interface requires a similar update in AMD-TEE Trusted OS's TEE_CMD_ID_LOAD_TA interface. This patch has been verified on Phoenix Birman setup. On older APUs, return_origin value will be 0. Cc: stable(a)vger.kernel.org Tested-by: Sourabh Das <sourabh.das(a)amd.com> Signed-off-by: Rijo Thomas <Rijo-john.Thomas(a)amd.com> --- drivers/tee/amdtee/amdtee_if.h | 10 ++++++---- drivers/tee/amdtee/call.c | 30 +++++++++++++++++------------- 2 files changed, 23 insertions(+), 17 deletions(-) diff --git a/drivers/tee/amdtee/amdtee_if.h b/drivers/tee/amdtee/amdtee_if.h index ff48c3e47375..e2014e21530a 100644 --- a/drivers/tee/amdtee/amdtee_if.h +++ b/drivers/tee/amdtee/amdtee_if.h @@ -118,16 +118,18 @@ struct tee_cmd_unmap_shared_mem { /** * struct tee_cmd_load_ta - load Trusted Application (TA) binary into TEE - * @low_addr: [in] bits [31:0] of the physical address of the TA binary - * @hi_addr: [in] bits [63:32] of the physical address of the TA binary - * @size: [in] size of TA binary in bytes - * @ta_handle: [out] return handle of the loaded TA + * @low_addr: [in] bits [31:0] of the physical address of the TA binary + * @hi_addr: [in] bits [63:32] of the physical address of the TA binary + * @size: [in] size of TA binary in bytes + * @ta_handle: [out] return handle of the loaded TA + * @return_origin: [out] origin of return code after TEE processing */ struct tee_cmd_load_ta { u32 low_addr; u32 hi_addr; u32 size; u32 ta_handle; + u32 return_origin; }; /** diff --git a/drivers/tee/amdtee/call.c b/drivers/tee/amdtee/call.c index e8cd9aaa3467..e9b63dcb3194 100644 --- a/drivers/tee/amdtee/call.c +++ b/drivers/tee/amdtee/call.c @@ -423,19 +423,23 @@ int handle_load_ta(void *data, u32 size, struct tee_ioctl_open_session_arg *arg) if (ret) { arg->ret_origin = TEEC_ORIGIN_COMMS; arg->ret = TEEC_ERROR_COMMUNICATION; - } else if (arg->ret == TEEC_SUCCESS) { - ret = get_ta_refcount(load_cmd.ta_handle); - if (!ret) { - arg->ret_origin = TEEC_ORIGIN_COMMS; - arg->ret = TEEC_ERROR_OUT_OF_MEMORY; - - /* Unload the TA on error */ - unload_cmd.ta_handle = load_cmd.ta_handle; - psp_tee_process_cmd(TEE_CMD_ID_UNLOAD_TA, - (void *)&unload_cmd, - sizeof(unload_cmd), &ret); - } else { - set_session_id(load_cmd.ta_handle, 0, &arg->session); + } else { + arg->ret_origin = load_cmd.return_origin; + + if (arg->ret == TEEC_SUCCESS) { + ret = get_ta_refcount(load_cmd.ta_handle); + if (!ret) { + arg->ret_origin = TEEC_ORIGIN_COMMS; + arg->ret = TEEC_ERROR_OUT_OF_MEMORY; + + /* Unload the TA on error */ + unload_cmd.ta_handle = load_cmd.ta_handle; + psp_tee_process_cmd(TEE_CMD_ID_UNLOAD_TA, + (void *)&unload_cmd, + sizeof(unload_cmd), &ret); + } else { + set_session_id(load_cmd.ta_handle, 0, &arg->session); + } } } mutex_unlock(&ta_refcount_mutex); -- 2.25.1

3 years, 1 month

2
2
0 0

Calling tee_invoke_supp_plugin_rpc() with exceptions masked

by Jacob Kroon

Hi, I'm wondering if it is safe to call tee_invoke_supp_plugin_rpc() from within the OP-TEE kernel with both foreign and/or native exceptions masked ? Regards, Jacob

3 years, 1 month

3
3
0 0

Cannot upload changes for review

by Ruth Glushkin

Hi, bash-4.2$ git push Enumerating objects: 22, done. Counting objects: 100% (22/22), done. Delta compression using up to 40 threads Compressing objects: 100% (17/17), done. Writing objects: 100% (18/18), 5.66 KiB | 579.00 KiB/s, done. Total 18 (delta 3), reused 0 (delta 0), pack-reused 0 remote: Resolving deltas: 100% (3/3) remote: error: branch refs/heads/integration: remote: To push into this reference you need 'Push' rights. remote: User: rutigl remote: Contact an administrator to fix the permissions remote: Processing changes: refs: 1, done To https://review.trustedfirmware.org/OP-TEE/optee_os ! [remote rejected] integration -> integration (prohibited by Gerrit: not permitted: update) error: failed to push some refs to 'https://review.trustedfirmware.org/OP-TEE/optee_os' Thank you in advance for assistance. Margarita Glushkin

3 years, 1 month

2
1
0 0

[PATCH] optee: fix uninited async notif value

by Etienne Carriere

Fixes an uninitialized variable in irq_handler() that could lead to unpredictable behavior in case OP-TEE fails to handle SMC function ID OPTEE_SMC_GET_ASYNC_NOTIF_VALUE. This change ensures that in that case get_async_notif_value() properly reports there are no notification event. Reported-by: kernel test robot <lkp(a)intel.com> Link: https://lore.kernel.org/r/202304200755.OoiuclDZ-lkp@intel.com/ Reported-by: Dan Carpenter <error27(a)gmail.com> Link: https://lore.kernel.org/all/d9b7f69b-c737-4cb3-8e74-79fe00c934f9@kili.mount… Fixes: 6749e69c4dad ("optee: add asynchronous notifications") Signed-off-by: Etienne Carriere <etienne.carriere(a)linaro.org> --- drivers/tee/optee/smc_abi.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/tee/optee/smc_abi.c b/drivers/tee/optee/smc_abi.c index de7ac9a46354..6d3705770755 100644 --- a/drivers/tee/optee/smc_abi.c +++ b/drivers/tee/optee/smc_abi.c @@ -1001,8 +1001,10 @@ static u32 get_async_notif_value(optee_invoke_fn *invoke_fn, bool *value_valid, invoke_fn(OPTEE_SMC_GET_ASYNC_NOTIF_VALUE, 0, 0, 0, 0, 0, 0, 0, &res); - if (res.a0) + if (res.a0) { + *value_valid = false; return 0; + } *value_valid = (res.a2 & OPTEE_SMC_ASYNC_NOTIF_VALUE_VALID); *value_pending = (res.a2 & OPTEE_SMC_ASYNC_NOTIF_VALUE_PENDING); return res.a1; -- 2.25.1

3 years, 2 months

2
1
0 0

[linux-next:master] BUILD REGRESSION 3cdbc01c40e34c57697f8934f2727a88551696be

by kernel test robot

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master branch HEAD: 3cdbc01c40e34c57697f8934f2727a88551696be Add linux-next specific files for 20230419 Error/Warning reports: https://lore.kernel.org/oe-kbuild-all/202304102354.Q4VOXGTE-lkp@intel.com https://lore.kernel.org/oe-kbuild-all/202304200812.6UqNDVZy-lkp@intel.com https://lore.kernel.org/oe-kbuild-all/202304201027.2upm4i0C-lkp@intel.com https://lore.kernel.org/oe-kbuild-all/202304201216.YgbKeHUJ-lkp@intel.com Error/Warning: (recently discovered and may have been fixed) drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dmub_srv.c:184:19: warning: variable 'dmub' set but not used [-Wunused-but-set-variable] drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_abm.c:138:15: warning: variable 'feature_support' set but not used [-Wunused-but-set-variable] drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_abm_lcd.c:124:14: warning: no previous prototype for function 'dmub_abm_get_current_backlight' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_abm_lcd.c:135:14: warning: no previous prototype for function 'dmub_abm_get_target_backlight' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_abm_lcd.c:146:6: warning: no previous prototype for function 'dmub_abm_set_level' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_abm_lcd.c:167:6: warning: no previous prototype for function 'dmub_abm_set_ambient_level' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_abm_lcd.c:189:6: warning: no previous prototype for function 'dmub_abm_init_config' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_abm_lcd.c:221:6: warning: no previous prototype for function 'dmub_abm_set_pause' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_abm_lcd.c:241:6: warning: no previous prototype for function 'dmub_abm_set_pipe' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_abm_lcd.c:263:6: warning: no previous prototype for function 'dmub_abm_set_backlight_level' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_abm_lcd.c:83:6: warning: no previous prototype for function 'dmub_abm_init' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_validation.c:351:13: warning: variable 'bw_needed' set but not used [-Wunused-but-set-variable] drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_validation.c:352:25: warning: variable 'link' set but not used [-Wunused-but-set-variable] drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c:451:16: warning: variable 'j' set but not used [-Wunused-but-set-variable] drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c:1049:6: warning: no previous prototype for 'gfx_v9_4_3_disable_gpa_mode' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c:1049:6: warning: no previous prototype for function 'gfx_v9_4_3_disable_gpa_mode' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c:1072:6: warning: no previous prototype for 'gfx_v9_4_3_disable_gpa_mode' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c:48:38: warning: unused variable 'golden_settings_gc_9_4_3' [-Wunused-const-variable] drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:62: warning: wrong kernel-doc identifier on line: drivers/gpu/drm/i915/i915_pmu.h:41: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst drivers/gpu/drm/i915/i915_request.h:176: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst drivers/gpu/drm/i915/i915_vma.h:145: warning: expecting prototype for i915_vma_offset(). Prototype was for i915_vma_size() instead drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c:298:6: warning: variable 'ret' is uninitialized when used here [-Wuninitialized] ld.lld: error: .btf.vmlinux.bin.o: unknown file type phy-mtk-hdmi-mt8195.c:(.text+0x2e2): undefined reference to `__floatundidf' phy-mtk-hdmi-mt8195.c:(.text+0x2f4): undefined reference to `__ltdf2' phy-mtk-hdmi-mt8195.c:(.text+0x344): undefined reference to `__gedf2' riscv64-linux-ld: phy-mtk-hdmi-mt8195.c:(.text+0x312): undefined reference to `__gedf2' riscv64-linux-ld: phy-mtk-hdmi-mt8195.c:(.text+0x32c): undefined reference to `__ltdf2' Unverified Error/Warning (likely false positive, please contact us if interested): drivers/acpi/property.c:985 acpi_data_prop_read_single() error: potentially dereferencing uninitialized 'obj'. drivers/firmware/smccc/smccc.c:20:21: sparse: sparse: symbol 'smccc_soc_id_version' was not declared. Should it be static? drivers/firmware/smccc/smccc.c:21:21: sparse: sparse: symbol 'smccc_soc_id_revision' was not declared. Should it be static? drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c:240 mtk_hdmi_pll_calc() warn: impossible condition '(tmds_clk < 1.483500e+02 * 1000000) => (0.000000e+00-1.844674e+19 < -1.786711e-113)' drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c:242 mtk_hdmi_pll_calc() warn: always true condition '(tmds_clk >= 1.483500e+02 * 1000000) => (0-u64max >= -1.786711e-113)' drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c:242 mtk_hdmi_pll_calc() warn: impossible condition '(tmds_clk < 2.967000e+02 * 1000000) => (0.000000e+00-1.844674e+19 < -4.419080e+60)' drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c:244 mtk_hdmi_pll_calc() warn: always true condition '(tmds_clk >= 2.967000e+02 * 1000000) => (0-u64max >= -4.419080e+60)' drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c:298 mtk_hdmi_pll_calc() error: uninitialized symbol 'ret'. drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c:331 mtk_hdmi_pll_drv_setting() warn: always true condition '(pixel_clk >= 7.417500e+01 * 1000000) => (0-u32max >= -7.223985e-287)' drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c:336 mtk_hdmi_pll_drv_setting() warn: impossible condition '(pixel_clk < 7.417500e+01 * 1000000) => (0.000000e+00-4.294967e+09 < -7.223985e-287)' drivers/tee/optee/smc_abi.c:1021 irq_handler() error: uninitialized symbol 'value_valid'. drivers/tee/optee/smc_abi.c:1028 irq_handler() error: uninitialized symbol 'value_pending'. fs/xfs/scrub/refcount.c: xfs_mount.h is included more than once. fs/xfs/scrub/refcount.c: xfs_trans_resv.h is included more than once. Error/Warning ids grouped by kconfigs: gcc_recent_errors |-- alpha-allyesconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used |-- alpha-randconfig-r001-20230420 | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used |-- alpha-randconfig-r023-20230420 | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used |-- arc-allyesconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used |-- arc-buildonly-randconfig-r004-20230419 | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used |-- arc-randconfig-r043-20230420 | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used |-- arm-allmodconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used |-- arm-allyesconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used |-- arm64-allyesconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used |-- arm64-randconfig-m041-20230419 | |-- drivers-tee-optee-smc_abi.c-irq_handler()-error:uninitialized-symbol-value_pending-. | `-- drivers-tee-optee-smc_abi.c-irq_handler()-error:uninitialized-symbol-value_valid-. |-- arm64-randconfig-r003-20230417 | `-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used |-- arm64-randconfig-s031-20230416 | |-- drivers-firmware-smccc-smccc.c:sparse:sparse:symbol-smccc_soc_id_revision-was-not-declared.-Should-it-be-static | `-- drivers-firmware-smccc-smccc.c:sparse:sparse:symbol-smccc_soc_id_version-was-not-declared.-Should-it-be-static |-- csky-randconfig-m041-20230419 | |-- drivers-phy-mediatek-phy-mtk-hdmi-mt8195.c-mtk_hdmi_pll_calc()-error:uninitialized-symbol-ret-. | |-- drivers-phy-mediatek-phy-mtk-hdmi-mt8195.c-mtk_hdmi_pll_calc()-warn:always-true-condition-(tmds_clk-.483500e-)-(-u64max-.786711e-) | |-- drivers-phy-mediatek-phy-mtk-hdmi-mt8195.c-mtk_hdmi_pll_calc()-warn:always-true-condition-(tmds_clk-.967000e-)-(-u64max-.419080e-) | |-- drivers-phy-mediatek-phy-mtk-hdmi-mt8195.c-mtk_hdmi_pll_calc()-warn:impossible-condition-(tmds_clk-.483500e-)-(.000000e-.844674e-.786711e-) | |-- drivers-phy-mediatek-phy-mtk-hdmi-mt8195.c-mtk_hdmi_pll_calc()-warn:impossible-condition-(tmds_clk-.967000e-)-(.000000e-.844674e-.419080e-) | |-- drivers-phy-mediatek-phy-mtk-hdmi-mt8195.c-mtk_hdmi_pll_drv_setting()-warn:always-true-condition-(pixel_clk-.417500e-)-(-u32max-.223985e-) | `-- drivers-phy-mediatek-phy-mtk-hdmi-mt8195.c-mtk_hdmi_pll_drv_setting()-warn:impossible-condition-(pixel_clk-.417500e-)-(.000000e-.294967e-.223985e-) |-- csky-randconfig-r024-20230417 | `-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used |-- i386-allyesconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used |-- i386-randconfig-m021-20230417 | `-- drivers-acpi-property.c-acpi_data_prop_read_single()-error:potentially-dereferencing-uninitialized-obj-. |-- ia64-allmodconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used |-- ia64-randconfig-r034-20230416 | |-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-gfx_v9_4_3_disable_gpa_mode |-- ia64-randconfig-s043-20230416 | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used | |-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-gfx_v9_4_3_disable_gpa_mode |-- loongarch-allmodconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used |-- loongarch-defconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used |-- microblaze-randconfig-m041-20230416 | |-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-gfx_v9_4_3_disable_gpa_mode |-- microblaze-randconfig-r004-20230420 | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used |-- mips-allmodconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used |-- mips-allyesconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used |-- mips-randconfig-c003-20230420 | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used | |-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-gfx_v9_4_3_disable_gpa_mode |-- mips-randconfig-s041-20230416 | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-dce-dmub_abm_lcd.c:sparse:sparse:cast-truncates-bits-from-constant-value-(ffff-becomes-ff) | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used |-- openrisc-randconfig-c003-20230416 | `-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used |-- parisc-buildonly-randconfig-r003-20230419 | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used |-- powerpc-allmodconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used |-- riscv-allmodconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used |-- riscv-randconfig-r016-20230416 | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used |-- riscv-randconfig-s052-20230416 | |-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used | |-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-gfx_v9_4_3_disable_gpa_mode | |-- phy-mtk-hdmi-mt8195.c:(.text):undefined-reference-to-__floatundidf | |-- phy-mtk-hdmi-mt8195.c:(.text):undefined-reference-to-__gedf2 | |-- phy-mtk-hdmi-mt8195.c:(.text):undefined-reference-to-__ltdf2 | |-- riscv64-linux-ld:phy-mtk-hdmi-mt8195.c:(.text):undefined-reference-to-__gedf2 | `-- riscv64-linux-ld:phy-mtk-hdmi-mt8195.c:(.text):undefined-reference-to-__ltdf2 |-- s390-allyesconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used |-- sparc-allmodconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used | |-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-gfx_v9_4_3_disable_gpa_mode |-- sparc64-randconfig-s053-20230416 | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used | |-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-gfx_v9_4_3_disable_gpa_mode |-- x86_64-allnoconfig | |-- fs-xfs-scrub-refcount.c:xfs_mount.h-is-included-more-than-once. | `-- fs-xfs-scrub-refcount.c:xfs_trans_resv.h-is-included-more-than-once. |-- x86_64-allyesconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used `-- x86_64-randconfig-m001-20230417 `-- drivers-acpi-property.c-acpi_data_prop_read_single()-error:potentially-dereferencing-uninitialized-obj-. clang_recent_errors |-- arm64-buildonly-randconfig-r005-20230416 | `-- drivers-phy-mediatek-phy-mtk-hdmi-mt8195.c:warning:variable-ret-is-uninitialized-when-used-here |-- arm64-randconfig-r015-20230417 | `-- drivers-phy-mediatek-phy-mtk-hdmi-mt8195.c:warning:variable-ret-is-uninitialized-when-used-here |-- arm64-randconfig-r036-20230416 | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-dc_dmub_srv.c:warning:variable-dmub-set-but-not-used | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-dce-dmub_abm.c:warning:variable-feature_support-set-but-not-used | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-dce-dmub_abm_lcd.c:warning:no-previous-prototype-for-function-dmub_abm_get_current_backlight | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-dce-dmub_abm_lcd.c:warning:no-previous-prototype-for-function-dmub_abm_get_target_backlight | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-dce-dmub_abm_lcd.c:warning:no-previous-prototype-for-function-dmub_abm_init | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-dce-dmub_abm_lcd.c:warning:no-previous-prototype-for-function-dmub_abm_init_config | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-dce-dmub_abm_lcd.c:warning:no-previous-prototype-for-function-dmub_abm_set_ambient_level | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-dce-dmub_abm_lcd.c:warning:no-previous-prototype-for-function-dmub_abm_set_backlight_level | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-dce-dmub_abm_lcd.c:warning:no-previous-prototype-for-function-dmub_abm_set_level | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-dce-dmub_abm_lcd.c:warning:no-previous-prototype-for-function-dmub_abm_set_pause | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-dce-dmub_abm_lcd.c:warning:no-previous-prototype-for-function-dmub_abm_set_pipe | |-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-function-gfx_v9_4_3_disable_gpa_mode | `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:unused-variable-golden_settings_gc_9_4_3 |-- hexagon-randconfig-r023-20230417 | `-- ld.lld:error:.btf.vmlinux.bin.o:unknown-file-type |-- hexagon-randconfig-r045-20230420 | `-- drivers-phy-mediatek-phy-mtk-hdmi-mt8195.c:warning:variable-ret-is-uninitialized-when-used-here |-- mips-randconfig-r021-20230420 | `-- drivers-phy-mediatek-phy-mtk-hdmi-mt8195.c:warning:variable-ret-is-uninitialized-when-used-here |-- riscv-buildonly-randconfig-r006-20230419 | `-- drivers-phy-mediatek-phy-mtk-hdmi-mt8195.c:warning:variable-ret-is-uninitialized-when-used-here |-- riscv-randconfig-r032-20230416 | `-- drivers-phy-mediatek-phy-mtk-hdmi-mt8195.c:warning:variable-ret-is-uninitialized-when-used-here `-- x86_64-randconfig-a011-20230417 |-- drivers-gpu-drm-i915-gt-uc-guc_capture_fwif.h:warning:wrong-kernel-doc-identifier-on-line: |-- drivers-gpu-drm-i915-i915_pmu.h:warning:This-comment-starts-with-but-isn-t-a-kernel-doc-comment.-Refer-Documentation-doc-guide-kernel-doc.rst |-- drivers-gpu-drm-i915-i915_request.h:warning:This-comment-starts-with-but-isn-t-a-kernel-doc-comment.-Refer-Documentation-doc-guide-kernel-doc.rst `-- drivers-gpu-drm-i915-i915_vma.h:warning:expecting-prototype-for-i915_vma_offset().-Prototype-was-for-i915_vma_size()-instead elapsed time: 734m configs tested: 190 configs skipped: 20 tested configs: alpha allyesconfig gcc alpha buildonly-randconfig-r005-20230417 gcc alpha defconfig gcc alpha randconfig-r001-20230416 gcc alpha randconfig-r001-20230420 gcc alpha randconfig-r003-20230416 gcc alpha randconfig-r013-20230416 gcc alpha randconfig-r023-20230420 gcc arc allyesconfig gcc arc buildonly-randconfig-r002-20230418 gcc arc buildonly-randconfig-r004-20230417 gcc arc buildonly-randconfig-r004-20230419 gcc arc buildonly-randconfig-r006-20230416 gcc arc defconfig gcc arc randconfig-r043-20230416 gcc arc randconfig-r043-20230417 gcc arc randconfig-r043-20230419 gcc arc randconfig-r043-20230420 gcc arm allmodconfig gcc arm allyesconfig gcc arm at91_dt_defconfig gcc arm defconfig gcc arm ep93xx_defconfig clang arm hisi_defconfig gcc arm keystone_defconfig gcc arm omap1_defconfig clang arm randconfig-r006-20230416 gcc arm randconfig-r046-20230416 clang arm randconfig-r046-20230417 gcc arm randconfig-r046-20230419 gcc arm randconfig-r046-20230420 clang arm tegra_defconfig gcc arm64 allyesconfig gcc arm64 buildonly-randconfig-r004-20230418 clang arm64 buildonly-randconfig-r005-20230416 clang arm64 buildonly-randconfig-r005-20230419 gcc arm64 defconfig gcc arm64 randconfig-r003-20230417 gcc arm64 randconfig-r015-20230417 clang arm64 randconfig-r036-20230416 clang csky buildonly-randconfig-r004-20230416 gcc csky buildonly-randconfig-r006-20230418 gcc csky defconfig gcc csky randconfig-r024-20230417 gcc csky randconfig-r025-20230416 gcc csky randconfig-r026-20230420 gcc hexagon randconfig-r005-20230417 clang hexagon randconfig-r012-20230417 clang hexagon randconfig-r016-20230417 clang hexagon randconfig-r023-20230417 clang hexagon randconfig-r031-20230418 clang hexagon randconfig-r035-20230416 clang hexagon randconfig-r041-20230416 clang hexagon randconfig-r041-20230417 clang hexagon randconfig-r041-20230419 clang hexagon randconfig-r041-20230420 clang hexagon randconfig-r045-20230416 clang hexagon randconfig-r045-20230417 clang hexagon randconfig-r045-20230419 clang hexagon randconfig-r045-20230420 clang i386 allyesconfig gcc i386 debian-10.3 gcc i386 defconfig gcc i386 randconfig-a001-20230417 gcc i386 randconfig-a002-20230417 gcc i386 randconfig-a003-20230417 gcc i386 randconfig-a004-20230417 gcc i386 randconfig-a005-20230417 gcc i386 randconfig-a006-20230417 gcc i386 randconfig-a011-20230417 clang i386 randconfig-a012-20230417 clang i386 randconfig-a013-20230417 clang i386 randconfig-a014-20230417 clang i386 randconfig-a015-20230417 clang i386 randconfig-a016-20230417 clang i386 randconfig-r006-20230417 gcc ia64 allmodconfig gcc ia64 defconfig gcc ia64 randconfig-r022-20230416 gcc ia64 randconfig-r022-20230417 gcc ia64 randconfig-r026-20230416 gcc ia64 randconfig-r034-20230416 gcc ia64 randconfig-r036-20230418 gcc ia64 zx1_defconfig gcc loongarch allmodconfig gcc loongarch allnoconfig gcc loongarch defconfig gcc m68k allmodconfig gcc m68k atari_defconfig gcc m68k defconfig gcc m68k m5272c3_defconfig gcc microblaze buildonly-randconfig-r003-20230418 gcc microblaze randconfig-r004-20230420 gcc microblaze randconfig-r021-20230417 gcc mips allmodconfig gcc mips allyesconfig gcc mips cobalt_defconfig gcc mips decstation_64_defconfig gcc mips malta_qemu_32r6_defconfig clang mips omega2p_defconfig clang mips randconfig-r012-20230416 clang mips randconfig-r014-20230417 gcc mips randconfig-r021-20230420 clang mips randconfig-r034-20230418 gcc nios2 buildonly-randconfig-r006-20230417 gcc nios2 defconfig gcc nios2 randconfig-r002-20230417 gcc nios2 randconfig-r025-20230417 gcc openrisc buildonly-randconfig-r001-20230418 gcc openrisc buildonly-randconfig-r002-20230416 gcc openrisc randconfig-r011-20230417 gcc parisc buildonly-randconfig-r002-20230417 gcc parisc buildonly-randconfig-r003-20230419 gcc parisc defconfig gcc parisc randconfig-r021-20230416 gcc parisc randconfig-r023-20230416 gcc parisc randconfig-r024-20230416 gcc parisc64 defconfig gcc powerpc allmodconfig gcc powerpc allnoconfig gcc powerpc cm5200_defconfig gcc powerpc gamecube_defconfig clang powerpc klondike_defconfig gcc powerpc makalu_defconfig gcc powerpc mpc7448_hpc2_defconfig gcc powerpc rainier_defconfig gcc powerpc redwood_defconfig gcc powerpc skiroot_defconfig clang powerpc taishan_defconfig gcc powerpc wii_defconfig gcc riscv allmodconfig gcc riscv allnoconfig gcc riscv buildonly-randconfig-r003-20230416 gcc riscv buildonly-randconfig-r003-20230417 clang riscv buildonly-randconfig-r006-20230419 clang riscv defconfig gcc riscv randconfig-r005-20230416 clang riscv randconfig-r016-20230416 gcc riscv randconfig-r032-20230416 clang riscv randconfig-r032-20230418 clang riscv randconfig-r042-20230416 gcc riscv randconfig-r042-20230417 clang riscv randconfig-r042-20230419 clang riscv randconfig-r042-20230420 gcc riscv rv32_defconfig gcc s390 allmodconfig gcc s390 allyesconfig gcc s390 defconfig gcc s390 randconfig-r002-20230420 clang s390 randconfig-r003-20230420 clang s390 randconfig-r044-20230416 gcc s390 randconfig-r044-20230417 clang s390 randconfig-r044-20230419 clang s390 randconfig-r044-20230420 gcc sh allmodconfig gcc sh buildonly-randconfig-r001-20230416 gcc sh ecovec24_defconfig gcc sh r7785rp_defconfig gcc sh randconfig-r004-20230417 gcc sh randconfig-r011-20230416 gcc sh rsk7264_defconfig gcc sparc defconfig gcc sparc sparc32_defconfig gcc sparc64 buildonly-randconfig-r002-20230419 gcc sparc64 randconfig-r026-20230417 gcc um i386_defconfig gcc um x86_64_defconfig gcc x86_64 allnoconfig gcc x86_64 allyesconfig gcc x86_64 defconfig gcc x86_64 kexec gcc x86_64 randconfig-a001-20230417 gcc x86_64 randconfig-a002-20230417 gcc x86_64 randconfig-a003-20230417 gcc x86_64 randconfig-a004-20230417 gcc x86_64 randconfig-a005-20230417 gcc x86_64 randconfig-a006-20230417 gcc x86_64 randconfig-a011-20230417 clang x86_64 randconfig-a012-20230417 clang x86_64 randconfig-a013-20230417 clang x86_64 randconfig-a014-20230417 clang x86_64 randconfig-a015-20230417 clang x86_64 randconfig-a016-20230417 clang x86_64 rhel-8.3-bpf gcc x86_64 rhel-8.3-kunit gcc x86_64 rhel-8.3-kvm gcc x86_64 rhel-8.3-syz gcc x86_64 rhel-8.3 gcc xtensa randconfig-r015-20230416 gcc xtensa smp_lx200_defconfig gcc -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests

3 years, 2 months

1
0
0 0

fragment transmission while retrieving memory

by 梅建强(禹夜)

Hi, Jens, >The first is the descriptor passed with FFA_MEM_RETRIEVE_REQ_32, >this one is not likely to need fragmentation support soon. Could you tell me why? I'm a little unclear. Could you describe the difference between the retrieve process you mean and FFA-spec figure 18.4 in detail? I need to make sure that I really understand what you mean, so that I can implement the missing support for fragmented mem retrieve response as you said. Or do you mean that we just need to implement the action done by optee after it receives FFA_MEM_RETRIEVE_RESP_32? Regards, Yuye. ------------------------------------------------------------------ 发件人：Jens Wiklander <jens.wiklander(a)linaro.org> 发送时间：2023年4月14日(星期五) 14:23 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 抄　送：Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org>; op-tee <op-tee(a)lists.trustedfirmware.org> 主　题：Re: fragment transmission while retrieving memory Hi Yuye, On Fri, Apr 14, 2023 at 4:29 AM 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> wrote: > > > Hi, Jens, Olivier, > > If I understand properly, for this specific issue both optee and hafnium need to do further fix. > The following discussion and questions are based on figure 18.4 in the FFA spec. > > As I saw in the optee code, the retrieve mechanism would start with this code: > retrieve_desc = spmc_retrieve_req(cookie); > And in the function spmc_retrieve_req, > optee sets the total length to the same size as fragment0 length before sending FFA_MEM_FRAG_REQ to hafnium, > which means hafnium will only retrieve the fragment0 memory region. > > In the example process, > optee will determines the number of TX sized fragments of descriptor before sending FFA_MEM_FRAG_REQ to hafnium. > I have a question here. > How should optee calculate this quantity? > > Hafnium then receives the FFA_MEM_FRAG_REQ. > As I saw in the hafnium code, hafnium blocks the case that total length>fragment length. > if (fragment_length != length) { > dlog_verbose("Fragmentation not yet supported.\n"); > return ffa_error(FFA_INVALID_PARAMETERS); > } > Obviously it is not what we expected. > Then following the example process, hafnium should allocate handle and use it to associate fragments. > I didn't find the corresponding implementation in hafnium code for this step. > And I want to know how to implement the associate action here. > > After that, optee lacks the implementation of FFA_MEM_FRAG_RX and FFA_MEM_FRAG_TX ABI in CFG_CORE_SEL2_SPMC enable case. > Is there any support plan for the implementation of fragmented memory retrieve in the optee community? > Does the hafnium community have a plan to implement it cooperatively? If I've understood this correctly we have two different cases of eventual fragmentation of descriptors. The first is the descriptor passed with FFA_MEM_RETRIEVE_REQ_32, this one is not likely to need fragmentation support soon. The other is the descriptor received with FFA_MEM_RETRIEVE_RESP, I believe this is where you've run into trouble. From OP-TEE point of view, it would make sense if you took lead on implementing this. I can help with review etc. Thanks, Jens > > Thanks a lot for your support. > > Regards, > Yuye. > > > > > > ------------------------------------------------------------------ > 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> > 发送时间：2023年4月13日(星期四) 15:52 > 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > 抄送：hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > 主题：Re: fragment transmission while retrieving memory > > Hi Yuye, Jens, > > For the record, and If I understand properly the last comment in the github issue: > OP-TEE is missing the implementation for receipt of a fragmented retrieve response > There is no further fix to be done in Hafnium for this specific issue at this moment, please let me know otherwise. > > Thanks, Olivier. > > > ________________________________ > From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > Sent: 12 April 2023 09:27 > To: Olivier Deprez <Olivier.Deprez(a)arm.com> > Cc: hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > Subject: Re: fragment transmission while retrieving memory > > > > > Hi, Olivier, > > In our setup, > Hafnium commit: 997476a74571aec4f1a23590d45edf516f3934f4 > optee version: 3.20.0 > Thanks. > > Regards, > Yuye. > > ------------------------------------------------------------------ > 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> > 发送时间：2023年4月12日(星期三) 15:22 > 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > 抄送：hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > 主题：Re: fragment transmission while retrieving memory > > Hi Yuye, > > AFAIK concerning Hafnium, fragmented mem sharing is supported for FFA_MEM_SHARE/LEND/DONATE and FFA_MEM_RETRIEVE_RESP. > (For the sake of clarity, this isn't supported for FFA_MEM_RETRIEVE_REQ but this shouldn't be a concern as this limitation only exists in the case of mem sharing to multiple borrowers. In your case of a single borrower the mem retrieve req. shouldn't have to be fragmented). > > Can you tell which hafnium commit hash is used in your setup? > > At the moment, I cannot tell if the issue described concern a miss in Hafnium or OP-TEE. > I need to dig a bit further into both implementations and I'll let you know. > > Regards, > Olivier. > > > ________________________________ > From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > Sent: 12 April 2023 08:21 > To: Olivier Deprez <Olivier.Deprez(a)arm.com> > Cc: hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > Subject: fragment transmission while retrieving memory > > > > > Hi, Olivier, > > Recently, I've been working on this issue. > https://github.com/OP-TEE/optee_os/issues/5943 <https://github.com/OP-TEE/optee_os/issues/5943 > > Do you know any differences between hafnium's current implementation of fragment transmission while retrieving memory and the example process described in FF-A 1.1 Figure 18.4? > > Regards, > Yuye. > >

3 years, 2 months

2
1
0 0

fragment transmission while retrieving memory

by 梅建强(禹夜)

Hi, Jens, Olivier, update for optee: https://github.com/OP-TEE/optee_os/pull/5966 <https://github.com/OP-TEE/optee_os/pull/5966 > update for hafnium: diff --git a/src/api.c b/src/api.c index 5f699478..7e43e305 100644 --- a/src/api.c +++ b/src/api.c @@ -3191,7 +3191,8 @@ struct ffa_value api_ffa_mem_frag_rx(ffa_memory_handle_t handle, return ffa_error(FFA_INVALID_PARAMETERS); } } - + if (to->id==0x8001 && to->mailbox.state != MAILBOX_STATE_EMPTY) + to->mailbox.state = MAILBOX_STATE_EMPTY; to_locked = vm_lock(to); if (vm_is_mailbox_busy(to_locked)) { diff --git a/src/ffa_memory.c b/src/ffa_memory.c index 3e978d23..59e71ff3 100644 --- a/src/ffa_memory.c +++ b/src/ffa_memory.c @@ -2385,7 +2385,7 @@ struct ffa_value ffa_memory_retrieve_continue(struct vm_locked to_locked, &fragment_length); CHECK(remaining_constituent_count == 0); to_locked.vm->mailbox.recv_size = fragment_length; - to_locked.vm->mailbox.recv_sender = HF_HYPERVISOR_VM_ID; + to_locked.vm->mailbox.recv_sender = to_locked.vm->id; to_locked.vm->mailbox.recv_func = FFA_MEM_FRAG_TX_32; to_locked.vm->mailbox.state = MAILBOX_STATE_FULL; It seems that to->mailbox.state needs to be set to MAILBOX_STATE_EMPTY firstly. I have not figured out why, but large TA could be loaded successfully with above fix now. Regards, Yuye. ------------------------------------------------------------------ 发件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 发送时间：2023年4月17日(星期一) 02:16 收件人：Jens Wiklander <jens.wiklander(a)linaro.org> 抄　送：Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org>; op-tee <op-tee(a)lists.trustedfirmware.org> 主　题：fragment transmission while retrieving memory Hi, Jens, I have implement the missing support for fragmented mem retrieve response as you suggested. I will push fix into the community code soon and please help review it later. Thanks. Regards, Yuye. ------------------------------------------------------------------ 发件人：Jens Wiklander <jens.wiklander(a)linaro.org> 发送时间：2023年4月14日(星期五) 14:23 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 抄　送：Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org>; op-tee <op-tee(a)lists.trustedfirmware.org> 主　题：Re: fragment transmission while retrieving memory Hi Yuye, On Fri, Apr 14, 2023 at 4:29 AM 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> wrote: > > > Hi, Jens, Olivier, > > If I understand properly, for this specific issue both optee and hafnium need to do further fix. > The following discussion and questions are based on figure 18.4 in the FFA spec. > > As I saw in the optee code, the retrieve mechanism would start with this code: > retrieve_desc = spmc_retrieve_req(cookie); > And in the function spmc_retrieve_req, > optee sets the total length to the same size as fragment0 length before sending FFA_MEM_FRAG_REQ to hafnium, > which means hafnium will only retrieve the fragment0 memory region. > > In the example process, > optee will determines the number of TX sized fragments of descriptor before sending FFA_MEM_FRAG_REQ to hafnium. > I have a question here. > How should optee calculate this quantity? > > Hafnium then receives the FFA_MEM_FRAG_REQ. > As I saw in the hafnium code, hafnium blocks the case that total length>fragment length. > if (fragment_length != length) { > dlog_verbose("Fragmentation not yet supported.\n"); > return ffa_error(FFA_INVALID_PARAMETERS); > } > Obviously it is not what we expected. > Then following the example process, hafnium should allocate handle and use it to associate fragments. > I didn't find the corresponding implementation in hafnium code for this step. > And I want to know how to implement the associate action here. > > After that, optee lacks the implementation of FFA_MEM_FRAG_RX and FFA_MEM_FRAG_TX ABI in CFG_CORE_SEL2_SPMC enable case. > Is there any support plan for the implementation of fragmented memory retrieve in the optee community? > Does the hafnium community have a plan to implement it cooperatively? If I've understood this correctly we have two different cases of eventual fragmentation of descriptors. The first is the descriptor passed with FFA_MEM_RETRIEVE_REQ_32, this one is not likely to need fragmentation support soon. The other is the descriptor received with FFA_MEM_RETRIEVE_RESP, I believe this is where you've run into trouble. From OP-TEE point of view, it would make sense if you took lead on implementing this. I can help with review etc. Thanks, Jens > > Thanks a lot for your support. > > Regards, > Yuye. > > > > > > ------------------------------------------------------------------ > 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> > 发送时间：2023年4月13日(星期四) 15:52 > 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > 抄送：hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > 主题：Re: fragment transmission while retrieving memory > > Hi Yuye, Jens, > > For the record, and If I understand properly the last comment in the github issue: > OP-TEE is missing the implementation for receipt of a fragmented retrieve response > There is no further fix to be done in Hafnium for this specific issue at this moment, please let me know otherwise. > > Thanks, Olivier. > > > ________________________________ > From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > Sent: 12 April 2023 09:27 > To: Olivier Deprez <Olivier.Deprez(a)arm.com> > Cc: hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > Subject: Re: fragment transmission while retrieving memory > > > > > Hi, Olivier, > > In our setup, > Hafnium commit: 997476a74571aec4f1a23590d45edf516f3934f4 > optee version: 3.20.0 > Thanks. > > Regards, > Yuye. > > ------------------------------------------------------------------ > 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> > 发送时间：2023年4月12日(星期三) 15:22 > 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > 抄送：hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > 主题：Re: fragment transmission while retrieving memory > > Hi Yuye, > > AFAIK concerning Hafnium, fragmented mem sharing is supported for FFA_MEM_SHARE/LEND/DONATE and FFA_MEM_RETRIEVE_RESP. > (For the sake of clarity, this isn't supported for FFA_MEM_RETRIEVE_REQ but this shouldn't be a concern as this limitation only exists in the case of mem sharing to multiple borrowers. In your case of a single borrower the mem retrieve req. shouldn't have to be fragmented). > > Can you tell which hafnium commit hash is used in your setup? > > At the moment, I cannot tell if the issue described concern a miss in Hafnium or OP-TEE. > I need to dig a bit further into both implementations and I'll let you know. > > Regards, > Olivier. > > > ________________________________ > From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > Sent: 12 April 2023 08:21 > To: Olivier Deprez <Olivier.Deprez(a)arm.com> > Cc: hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > Subject: fragment transmission while retrieving memory > > > > > Hi, Olivier, > > Recently, I've been working on this issue. > https://github.com/OP-TEE/optee_os/issues/5943 <https://github.com/OP-TEE/optee_os/issues/5943 > > Do you know any differences between hafnium's current implementation of fragment transmission while retrieving memory and the example process described in FF-A 1.1 Figure 18.4? > > Regards, > Yuye. > >

3 years, 2 months

1
0
0 0

fragment transmission while retrieving memory

by 梅建强(禹夜)

Hi, Jens, I have implement the missing support for fragmented mem retrieve response as you suggested. I will push fix into the community code soon and please help review it later. Thanks. Regards, Yuye. ------------------------------------------------------------------ 发件人：Jens Wiklander <jens.wiklander(a)linaro.org> 发送时间：2023年4月14日(星期五) 14:23 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 抄　送：Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org>; op-tee <op-tee(a)lists.trustedfirmware.org> 主　题：Re: fragment transmission while retrieving memory Hi Yuye, On Fri, Apr 14, 2023 at 4:29 AM 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> wrote: > > > Hi, Jens, Olivier, > > If I understand properly, for this specific issue both optee and hafnium need to do further fix. > The following discussion and questions are based on figure 18.4 in the FFA spec. > > As I saw in the optee code, the retrieve mechanism would start with this code: > retrieve_desc = spmc_retrieve_req(cookie); > And in the function spmc_retrieve_req, > optee sets the total length to the same size as fragment0 length before sending FFA_MEM_FRAG_REQ to hafnium, > which means hafnium will only retrieve the fragment0 memory region. > > In the example process, > optee will determines the number of TX sized fragments of descriptor before sending FFA_MEM_FRAG_REQ to hafnium. > I have a question here. > How should optee calculate this quantity? > > Hafnium then receives the FFA_MEM_FRAG_REQ. > As I saw in the hafnium code, hafnium blocks the case that total length>fragment length. > if (fragment_length != length) { > dlog_verbose("Fragmentation not yet supported.\n"); > return ffa_error(FFA_INVALID_PARAMETERS); > } > Obviously it is not what we expected. > Then following the example process, hafnium should allocate handle and use it to associate fragments. > I didn't find the corresponding implementation in hafnium code for this step. > And I want to know how to implement the associate action here. > > After that, optee lacks the implementation of FFA_MEM_FRAG_RX and FFA_MEM_FRAG_TX ABI in CFG_CORE_SEL2_SPMC enable case. > Is there any support plan for the implementation of fragmented memory retrieve in the optee community? > Does the hafnium community have a plan to implement it cooperatively? If I've understood this correctly we have two different cases of eventual fragmentation of descriptors. The first is the descriptor passed with FFA_MEM_RETRIEVE_REQ_32, this one is not likely to need fragmentation support soon. The other is the descriptor received with FFA_MEM_RETRIEVE_RESP, I believe this is where you've run into trouble. From OP-TEE point of view, it would make sense if you took lead on implementing this. I can help with review etc. Thanks, Jens > > Thanks a lot for your support. > > Regards, > Yuye. > > > > > > ------------------------------------------------------------------ > 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> > 发送时间：2023年4月13日(星期四) 15:52 > 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > 抄送：hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > 主题：Re: fragment transmission while retrieving memory > > Hi Yuye, Jens, > > For the record, and If I understand properly the last comment in the github issue: > OP-TEE is missing the implementation for receipt of a fragmented retrieve response > There is no further fix to be done in Hafnium for this specific issue at this moment, please let me know otherwise. > > Thanks, Olivier. > > > ________________________________ > From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > Sent: 12 April 2023 09:27 > To: Olivier Deprez <Olivier.Deprez(a)arm.com> > Cc: hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > Subject: Re: fragment transmission while retrieving memory > > > > > Hi, Olivier, > > In our setup, > Hafnium commit: 997476a74571aec4f1a23590d45edf516f3934f4 > optee version: 3.20.0 > Thanks. > > Regards, > Yuye. > > ------------------------------------------------------------------ > 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> > 发送时间：2023年4月12日(星期三) 15:22 > 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > 抄送：hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > 主题：Re: fragment transmission while retrieving memory > > Hi Yuye, > > AFAIK concerning Hafnium, fragmented mem sharing is supported for FFA_MEM_SHARE/LEND/DONATE and FFA_MEM_RETRIEVE_RESP. > (For the sake of clarity, this isn't supported for FFA_MEM_RETRIEVE_REQ but this shouldn't be a concern as this limitation only exists in the case of mem sharing to multiple borrowers. In your case of a single borrower the mem retrieve req. shouldn't have to be fragmented). > > Can you tell which hafnium commit hash is used in your setup? > > At the moment, I cannot tell if the issue described concern a miss in Hafnium or OP-TEE. > I need to dig a bit further into both implementations and I'll let you know. > > Regards, > Olivier. > > > ________________________________ > From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > Sent: 12 April 2023 08:21 > To: Olivier Deprez <Olivier.Deprez(a)arm.com> > Cc: hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > Subject: fragment transmission while retrieving memory > > > > > Hi, Olivier, > > Recently, I've been working on this issue. > https://github.com/OP-TEE/optee_os/issues/5943 <https://github.com/OP-TEE/optee_os/issues/5943 > > Do you know any differences between hafnium's current implementation of fragment transmission while retrieving memory and the example process described in FF-A 1.1 Figure 18.4? > > Regards, > Yuye. > >

3 years, 2 months

1
0
0 0

OP-TEE 3.21.0 has been released

by Jérôme Forissier

Hi, I'm pleased to announce that OP-TEE version 3.21.0 is now available. The list of changes can be found in the changelog [1]. A blog post will be published soon on trustedfirmware.org [2]. A big thank you to everyone who participated with contributions and helping out with testing the release [3]. [1] https://github.com/OP-TEE/optee_os/blob/master/CHANGELOG.md [2] https://www.trustedfirmware.org/blog/ [3] https://github.com/OP-TEE/optee_os/commit/e8abbcfbdf63437a640d5fd87b7e191ca… Regards, -- Jerome

3 years, 2 months

1
0
0 0

fragment transmission while retrieving memory

by 梅建强(禹夜)

Hi, Jens, Olivier, Is it possible to solve this problem by increasing the buffer size such as 64k? We plan to adopt this temporary scheme first and then implement the standard retrieve process later. If this scheme is feasible, I have a few questions. 1. Should the RXTX buffer between tee driver and hafnium the same as the one between hafnium and optee? 2. Which FFA instance is currently allocating these buffers? 3. For Hafnium, I want to increase the HF_MAILBOX_SIZE in Hafnium, but there seem to be two restrictions: static_assert(HF_MAILBOX_SIZE == PAGE_SIZE, "Currently, a page is mapped for the send and receive buffers so " "the maximum request is the size of a page."); static_assert(MM_PPOOL_ENTRY_SIZE >= HF_MAILBOX_SIZE, "The page pool entry size must be at least as big as the mailbox " "size, so that memory region descriptors can be copied from the " "mailbox for memory sharing."); I tried to increase the MM_PPOOL_ENTRY_SIZE, but optee doesn't seem to be booted properly. Do you know how to avoid the impact of these restrictions? Regards, Yuye. ------------------------------------------------------------------ 发件人：Jens Wiklander via Hafnium <hafnium(a)lists.trustedfirmware.org> 发送时间：2023年4月14日(星期五) 14:23 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 抄　送：Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org>; op-tee <op-tee(a)lists.trustedfirmware.org> 主　题：[Hafnium] Re: fragment transmission while retrieving memory Hi Yuye, On Fri, Apr 14, 2023 at 4:29 AM 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> wrote: > > > Hi, Jens, Olivier, > > If I understand properly, for this specific issue both optee and hafnium need to do further fix. > The following discussion and questions are based on figure 18.4 in the FFA spec. > > As I saw in the optee code, the retrieve mechanism would start with this code: > retrieve_desc = spmc_retrieve_req(cookie); > And in the function spmc_retrieve_req, > optee sets the total length to the same size as fragment0 length before sending FFA_MEM_FRAG_REQ to hafnium, > which means hafnium will only retrieve the fragment0 memory region. > > In the example process, > optee will determines the number of TX sized fragments of descriptor before sending FFA_MEM_FRAG_REQ to hafnium. > I have a question here. > How should optee calculate this quantity? > > Hafnium then receives the FFA_MEM_FRAG_REQ. > As I saw in the hafnium code, hafnium blocks the case that total length>fragment length. > if (fragment_length != length) { > dlog_verbose("Fragmentation not yet supported.\n"); > return ffa_error(FFA_INVALID_PARAMETERS); > } > Obviously it is not what we expected. > Then following the example process, hafnium should allocate handle and use it to associate fragments. > I didn't find the corresponding implementation in hafnium code for this step. > And I want to know how to implement the associate action here. > > After that, optee lacks the implementation of FFA_MEM_FRAG_RX and FFA_MEM_FRAG_TX ABI in CFG_CORE_SEL2_SPMC enable case. > Is there any support plan for the implementation of fragmented memory retrieve in the optee community? > Does the hafnium community have a plan to implement it cooperatively? If I've understood this correctly we have two different cases of eventual fragmentation of descriptors. The first is the descriptor passed with FFA_MEM_RETRIEVE_REQ_32, this one is not likely to need fragmentation support soon. The other is the descriptor received with FFA_MEM_RETRIEVE_RESP, I believe this is where you've run into trouble. From OP-TEE point of view, it would make sense if you took lead on implementing this. I can help with review etc. Thanks, Jens > > Thanks a lot for your support. > > Regards, > Yuye. > > > > > > ------------------------------------------------------------------ > 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> > 发送时间：2023年4月13日(星期四) 15:52 > 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > 抄送：hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > 主题：Re: fragment transmission while retrieving memory > > Hi Yuye, Jens, > > For the record, and If I understand properly the last comment in the github issue: > OP-TEE is missing the implementation for receipt of a fragmented retrieve response > There is no further fix to be done in Hafnium for this specific issue at this moment, please let me know otherwise. > > Thanks, Olivier. > > > ________________________________ > From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > Sent: 12 April 2023 09:27 > To: Olivier Deprez <Olivier.Deprez(a)arm.com> > Cc: hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > Subject: Re: fragment transmission while retrieving memory > > > > > Hi, Olivier, > > In our setup, > Hafnium commit: 997476a74571aec4f1a23590d45edf516f3934f4 > optee version: 3.20.0 > Thanks. > > Regards, > Yuye. > > ------------------------------------------------------------------ > 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> > 发送时间：2023年4月12日(星期三) 15:22 > 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > 抄送：hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > 主题：Re: fragment transmission while retrieving memory > > Hi Yuye, > > AFAIK concerning Hafnium, fragmented mem sharing is supported for FFA_MEM_SHARE/LEND/DONATE and FFA_MEM_RETRIEVE_RESP. > (For the sake of clarity, this isn't supported for FFA_MEM_RETRIEVE_REQ but this shouldn't be a concern as this limitation only exists in the case of mem sharing to multiple borrowers. In your case of a single borrower the mem retrieve req. shouldn't have to be fragmented). > > Can you tell which hafnium commit hash is used in your setup? > > At the moment, I cannot tell if the issue described concern a miss in Hafnium or OP-TEE. > I need to dig a bit further into both implementations and I'll let you know. > > Regards, > Olivier. > > > ________________________________ > From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > Sent: 12 April 2023 08:21 > To: Olivier Deprez <Olivier.Deprez(a)arm.com> > Cc: hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> > Subject: fragment transmission while retrieving memory > > > > > Hi, Olivier, > > Recently, I've been working on this issue. > https://github.com/OP-TEE/optee_os/issues/5943 <https://github.com/OP-TEE/optee_os/issues/5943 > > Do you know any differences between hafnium's current implementation of fragment transmission while retrieving memory and the example process described in FF-A 1.1 Figure 18.4? > > Regards, > Yuye. > > -- Hafnium mailing list -- hafnium(a)lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave(a)lists.trustedfirmware.org

3 years, 2 months

2
1
0 0

Re: fragment transmission while retrieving memory

by 梅建强(禹夜)

Hi, Jens, Olivier, If I understand properly, for this specific issue both optee and hafnium need to do further fix. The following discussion and questions are based on figure 18.4 in the FFA spec. As I saw in the optee code, the retrieve mechanism would start with this code: retrieve_desc = spmc_retrieve_req(cookie); And in the function spmc_retrieve_req, optee sets the total length to the same size as fragment0 length before sending FFA_MEM_FRAG_REQ to hafnium, which means hafnium will only retrieve the fragment0 memory region. In the example process, optee will determines the number of TX sized fragments of descriptor before sending FFA_MEM_FRAG_REQ to hafnium. I have a question here. How should optee calculate this quantity? Hafnium then receives the FFA_MEM_FRAG_REQ. As I saw in the hafnium code, hafnium blocks the case that total length>fragment length. if (fragment_length != length) { dlog_verbose("Fragmentation not yet supported.\n"); return ffa_error(FFA_INVALID_PARAMETERS); } Obviously it is not what we expected. Then following the example process, hafnium should allocate handle and use it to associate fragments. I didn't find the corresponding implementation in hafnium code for this step. And I want to know how to implement the associate action here. After that, optee lacks the implementation of FFA_MEM_FRAG_RX and FFA_MEM_FRAG_TX ABI in CFG_CORE_SEL2_SPMC enable case. Is there any support plan for the implementation of fragmented memory retrieve in the optee community? Does the hafnium community have a plan to implement it cooperatively? Thanks a lot for your support. Regards, Yuye. ------------------------------------------------------------------ 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> 发送时间：2023年4月13日(星期四) 15:52 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 抄　送：hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> 主　题：Re: fragment transmission while retrieving memory Hi Yuye, Jens, For the record, and If I understand properly the last comment in the github issue: OP-TEE is missing the implementation for receipt of a fragmented retrieve response There is no further fix to be done in Hafnium for this specific issue at this moment, please let me know otherwise. Thanks, Olivier. From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> Sent: 12 April 2023 09:27 To: Olivier Deprez <Olivier.Deprez(a)arm.com> Cc: hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> Subject: Re: fragment transmission while retrieving memory Hi, Olivier, In our setup, Hafnium commit: 997476a74571aec4f1a23590d45edf516f3934f4 optee version: 3.20.0 Thanks. Regards, Yuye. ------------------------------------------------------------------ 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> 发送时间：2023年4月12日(星期三) 15:22 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 抄　送：hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> 主　题：Re: fragment transmission while retrieving memory Hi Yuye, AFAIK concerning Hafnium, fragmented mem sharing is supported for FFA_MEM_SHARE/LEND/DONATE and FFA_MEM_RETRIEVE_RESP. (For the sake of clarity, this isn't supported for FFA_MEM_RETRIEVE_REQ but this shouldn't be a concern as this limitation only exists in the case of mem sharing to multiple borrowers. In your case of a single borrower the mem retrieve req. shouldn't have to be fragmented). Can you tell which hafnium commit hash is used in your setup? At the moment, I cannot tell if the issue described concern a miss in Hafnium or OP-TEE. I need to dig a bit further into both implementations and I'll let you know. Regards, Olivier. From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> Sent: 12 April 2023 08:21 To: Olivier Deprez <Olivier.Deprez(a)arm.com> Cc: hafnium <hafnium(a)lists.trustedfirmware.org>; Jens Wiklander <jens.wiklander(a)linaro.org> Subject: fragment transmission while retrieving memory Hi, Olivier, Recently, I've been working on this issue. https://github.com/OP-TEE/optee_os/issues/5943 <https://github.com/OP-TEE/optee_os/issues/5943 > Do you know any differences between hafnium's current implementation of fragment transmission while retrieving memory and the example process described in FF-A 1.1 Figure 18.4? Regards, Yuye.

3 years, 2 months

2
1
0 0

Preparing for OP-TEE 3.21.0

by Jérôme Forissier

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

3 years, 2 months

1
1
0 0

Linaro OP-TEE Contribution (LOC) monthly meeting in April is cancelled

by Joakim Bech

Hi, April's LOC meeting overlaps with Linaro Connect [1], hence we're unable to run the meeting and therefore the meeting will be cancelled. For people attending Linaro Connect. Jens, Jerome and myself will host an OP-TEE Open Hour where we encourage anyone who would like to discuss OP-TEE to show up in person. The OP-TEE Open Hour takes place Thursday 27th, 12.00-1:00 UK time in meeting room 2. [1] https://www.linaro.org/connect -- Regards, Joakim on behalf of the OP-TEE team

3 years, 2 months

1
0
0 0

[GIT PULL] OP-TEE load for v6.4

by Jens Wiklander

Hello arm-soc maintainers, Please pull this patch to enable loading of OP-TEE by the kernel. This feature is by default disabled and should probably always be so since it requires a quite specific security model to be secure. Thanks, Jens The following changes since commit eeac8ede17557680855031c6f305ece2378af326: Linux 6.3-rc2 (2023-03-12 16:36:44 -0700) are available in the Git repository at: https://git.linaro.org/people/jens.wiklander/linux-tee.git tags/optee-load-for-v6.4 for you to fetch changes up to f3040daab8104ac68e2b241bc93288f63b88a3c7: tee: optee: Add SMC for loading OP-TEE image (2023-04-03 08:57:49 +0200) ---------------------------------------------------------------- Add SMC for OP-TEE image loading Adds an SMC call for loading OP-TEE by the kernel. ---------------------------------------------------------------- Jeffrey Kardatzke (1): tee: optee: Add SMC for loading OP-TEE image Documentation/staging/tee.rst | 53 ++++++++++++++++ drivers/tee/optee/Kconfig | 17 ++++++ drivers/tee/optee/optee_msg.h | 12 ++++ drivers/tee/optee/optee_smc.h | 24 ++++++++ drivers/tee/optee/smc_abi.c | 137 ++++++++++++++++++++++++++++++++++++++++++ 5 files changed, 243 insertions(+)

3 years, 2 months

1
0
0 0

[PATCH v13] tee: optee: Add SMC for loading OP-TEE image

by Jeffrey Kardatzke

Adds an SMC call that will pass an OP-TEE binary image to EL3 and instruct it to load it as the BL32 payload. This works in conjunction with a feature added to Trusted Firmware for ARMv8 and above architectures that supports this. The main purpose of this change is to facilitate updating the OP-TEE component on devices via a rootfs change rather than having to do a firmware update. Further details are linked to in the Kconfig file. Signed-off-by: Jeffrey Kardatzke <jkardatzke(a)chromium.org> Reviewed-by: Sumit Garg <sumit.garg(a)linaro.org> Signed-off-by: Jeffrey Kardatzke <jkardatzke(a)google.com> --- Changes in v13: - Documentation formatting changes Changes in v12: - Fixed checkpatch strict issues Changes in v11: - Fixed typo in tee.rst documentation Changes in v10: - Fixed tee.rst documentation formatting Changes in v9: - Add CPU hotplug callback to init on all cores at startup Changes in v8: - Renamed params and fixed alignment issue Changes in v7: - Added documentation to Documentation/staging/tee.rst Changes in v6: - Expanded Kconfig documentation Changes in v5: - Renamed config option - Added runtime warning when config is used Changes in v4: - Update commit message - Added more documentation - Renamed config option, added ARM64 dependency Changes in v3: - Removed state tracking for driver reload - Check UID of service to verify it needs image load Changes in v2: - Fixed compile issue when feature is disabled - Addressed minor comments - Added state tracking for driver reload Documentation/staging/tee.rst | 53 +++++++++++++ drivers/tee/optee/Kconfig | 17 +++++ drivers/tee/optee/optee_msg.h | 12 +++ drivers/tee/optee/optee_smc.h | 24 ++++++ drivers/tee/optee/smc_abi.c | 137 ++++++++++++++++++++++++++++++++++ 5 files changed, 243 insertions(+) diff --git a/Documentation/staging/tee.rst b/Documentation/staging/tee.rst index 498343c7ab08..22baa077a3b9 100644 --- a/Documentation/staging/tee.rst +++ b/Documentation/staging/tee.rst @@ -214,6 +214,57 @@ call is done from the thread assisting the interrupt handler. This is a building block for OP-TEE OS in secure world to implement the top half and bottom half style of device drivers. +OPTEE_INSECURE_LOAD_IMAGE Kconfig option +---------------------------------------- + +The OPTEE_INSECURE_LOAD_IMAGE Kconfig option enables the ability to load the +BL32 OP-TEE image from the kernel after the kernel boots, rather than loading +it from the firmware before the kernel boots. This also requires enabling the +corresponding option in Trusted Firmware for Arm. The Trusted Firmware for Arm +documentation [8] explains the security threat associated with enabling this as +well as mitigations at the firmware and platform level. + +There are additional attack vectors/mitigations for the kernel that should be +addressed when using this option. + +1. Boot chain security. + + * Attack vector: Replace the OP-TEE OS image in the rootfs to gain control of + the system. + + * Mitigation: There must be boot chain security that verifies the kernel and + rootfs, otherwise an attacker can modify the loaded OP-TEE binary by + modifying it in the rootfs. + +2. Alternate boot modes. + + * Attack vector: Using an alternate boot mode (i.e. recovery mode), the + OP-TEE driver isn't loaded, leaving the SMC hole open. + + * Mitigation: If there are alternate methods of booting the device, such as a + recovery mode, it should be ensured that the same mitigations are applied + in that mode. + +3. Attacks prior to SMC invocation. + + * Attack vector: Code that is executed prior to issuing the SMC call to load + OP-TEE can be exploited to then load an alternate OS image. + + * Mitigation: The OP-TEE driver must be loaded before any potential attack + vectors are opened up. This should include mounting of any modifiable + filesystems, opening of network ports or communicating with external + devices (e.g. USB). + +4. Blocking SMC call to load OP-TEE. + + * Attack vector: Prevent the driver from being probed, so the SMC call to + load OP-TEE isn't executed when desired, leaving it open to being executed + later and loading a modified OS. + + * Mitigation: It is recommended to build the OP-TEE driver as builtin driver + rather than as a module to prevent exploits that may cause the module to + not be loaded. + AMD-TEE driver ============== @@ -309,3 +360,5 @@ References [6] include/linux/psp-tee.h [7] drivers/tee/amdtee/amdtee_if.h + +[8] https://trustedfirmware-a.readthedocs.io/en/latest/threat_model/threat_mode… diff --git a/drivers/tee/optee/Kconfig b/drivers/tee/optee/Kconfig index f121c224e682..70898bbd5809 100644 --- a/drivers/tee/optee/Kconfig +++ b/drivers/tee/optee/Kconfig @@ -7,3 +7,20 @@ config OPTEE help This implements the OP-TEE Trusted Execution Environment (TEE) driver. + +config OPTEE_INSECURE_LOAD_IMAGE + bool "Load OP-TEE image as firmware" + default n + depends on OPTEE && ARM64 + help + This loads the BL32 image for OP-TEE as firmware when the driver is + probed. This returns -EPROBE_DEFER until the firmware is loadable from + the filesystem which is determined by checking the system_state until + it is in SYSTEM_RUNNING. This also requires enabling the corresponding + option in Trusted Firmware for Arm. The documentation there explains + the security threat associated with enabling this as well as + mitigations at the firmware and platform level. + https://trustedfirmware-a.readthedocs.io/en/latest/threat_model/threat_mode… + + Additional documentation on kernel security risks are at + Documentation/staging/tee.rst. diff --git a/drivers/tee/optee/optee_msg.h b/drivers/tee/optee/optee_msg.h index 70e9cc2ee96b..e8840a82b983 100644 --- a/drivers/tee/optee/optee_msg.h +++ b/drivers/tee/optee/optee_msg.h @@ -241,11 +241,23 @@ struct optee_msg_arg { * 384fb3e0-e7f8-11e3-af63-0002a5d5c51b. * Represented in 4 32-bit words in OPTEE_MSG_UID_0, OPTEE_MSG_UID_1, * OPTEE_MSG_UID_2, OPTEE_MSG_UID_3. + * + * In the case where the OP-TEE image is loaded by the kernel, this will + * initially return an alternate UID to reflect that we are communicating with + * the TF-A image loading service at that time instead of OP-TEE. That UID is: + * a3fbeab1-1246-315d-c7c4-06b9c03cbea4. + * Represented in 4 32-bit words in OPTEE_MSG_IMAGE_LOAD_UID_0, + * OPTEE_MSG_IMAGE_LOAD_UID_1, OPTEE_MSG_IMAGE_LOAD_UID_2, + * OPTEE_MSG_IMAGE_LOAD_UID_3. */ #define OPTEE_MSG_UID_0 0x384fb3e0 #define OPTEE_MSG_UID_1 0xe7f811e3 #define OPTEE_MSG_UID_2 0xaf630002 #define OPTEE_MSG_UID_3 0xa5d5c51b +#define OPTEE_MSG_IMAGE_LOAD_UID_0 0xa3fbeab1 +#define OPTEE_MSG_IMAGE_LOAD_UID_1 0x1246315d +#define OPTEE_MSG_IMAGE_LOAD_UID_2 0xc7c406b9 +#define OPTEE_MSG_IMAGE_LOAD_UID_3 0xc03cbea4 #define OPTEE_MSG_FUNCID_CALLS_UID 0xFF01 /* diff --git a/drivers/tee/optee/optee_smc.h b/drivers/tee/optee/optee_smc.h index 73b5e7760d10..7d9fa426505b 100644 --- a/drivers/tee/optee/optee_smc.h +++ b/drivers/tee/optee/optee_smc.h @@ -104,6 +104,30 @@ struct optee_smc_call_get_os_revision_result { unsigned long reserved1; }; +/* + * Load Trusted OS from optee/tee.bin in the Linux firmware. + * + * WARNING: Use this cautiously as it could lead to insecure loading of the + * Trusted OS. + * This SMC instructs EL3 to load a binary and execute it as the Trusted OS. + * + * Call register usage: + * a0 SMC Function ID, OPTEE_SMC_CALL_LOAD_IMAGE + * a1 Upper 32bit of a 64bit size for the payload + * a2 Lower 32bit of a 64bit size for the payload + * a3 Upper 32bit of the physical address for the payload + * a4 Lower 32bit of the physical address for the payload + * + * The payload is in the OP-TEE image format. + * + * Returns result in a0, 0 on success and an error code otherwise. + */ +#define OPTEE_SMC_FUNCID_LOAD_IMAGE 2 +#define OPTEE_SMC_CALL_LOAD_IMAGE \ + ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, ARM_SMCCC_SMC_32, \ + ARM_SMCCC_OWNER_TRUSTED_OS_END, \ + OPTEE_SMC_FUNCID_LOAD_IMAGE) + /* * Call with struct optee_msg_arg as argument * diff --git a/drivers/tee/optee/smc_abi.c b/drivers/tee/optee/smc_abi.c index a1c1fa1a9c28..6e1f023d50c6 100644 --- a/drivers/tee/optee/smc_abi.c +++ b/drivers/tee/optee/smc_abi.c @@ -7,10 +7,13 @@ #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt #include <linux/arm-smccc.h> +#include <linux/cpuhotplug.h> #include <linux/errno.h> +#include <linux/firmware.h> #include <linux/interrupt.h> #include <linux/io.h> #include <linux/irqdomain.h> +#include <linux/kernel.h> #include <linux/mm.h> #include <linux/module.h> #include <linux/of.h> @@ -1149,6 +1152,22 @@ static bool optee_msg_api_uid_is_optee_api(optee_invoke_fn *invoke_fn) return false; } +#ifdef CONFIG_OPTEE_INSECURE_LOAD_IMAGE +static bool optee_msg_api_uid_is_optee_image_load(optee_invoke_fn *invoke_fn) +{ + struct arm_smccc_res res; + + invoke_fn(OPTEE_SMC_CALLS_UID, 0, 0, 0, 0, 0, 0, 0, &res); + + if (res.a0 == OPTEE_MSG_IMAGE_LOAD_UID_0 && + res.a1 == OPTEE_MSG_IMAGE_LOAD_UID_1 && + res.a2 == OPTEE_MSG_IMAGE_LOAD_UID_2 && + res.a3 == OPTEE_MSG_IMAGE_LOAD_UID_3) + return true; + return false; +} +#endif + static void optee_msg_get_os_revision(optee_invoke_fn *invoke_fn) { union { @@ -1354,6 +1373,120 @@ static void optee_shutdown(struct platform_device *pdev) optee_disable_shm_cache(optee); } +#ifdef CONFIG_OPTEE_INSECURE_LOAD_IMAGE + +#define OPTEE_FW_IMAGE "optee/tee.bin" + +static optee_invoke_fn *cpuhp_invoke_fn; + +static int optee_cpuhp_probe(unsigned int cpu) +{ + /* + * Invoking a call on a CPU will cause OP-TEE to perform the required + * setup for that CPU. Just invoke the call to get the UID since that + * has no side effects. + */ + if (optee_msg_api_uid_is_optee_api(cpuhp_invoke_fn)) + return 0; + else + return -EINVAL; +} + +static int optee_load_fw(struct platform_device *pdev, + optee_invoke_fn *invoke_fn) +{ + const struct firmware *fw = NULL; + struct arm_smccc_res res; + phys_addr_t data_pa; + u8 *data_buf = NULL; + u64 data_size; + u32 data_pa_high, data_pa_low; + u32 data_size_high, data_size_low; + int rc; + int hp_state; + + if (!optee_msg_api_uid_is_optee_image_load(invoke_fn)) + return 0; + + rc = request_firmware(&fw, OPTEE_FW_IMAGE, &pdev->dev); + if (rc) { + /* + * The firmware in the rootfs will not be accessible until we + * are in the SYSTEM_RUNNING state, so return EPROBE_DEFER until + * that point. + */ + if (system_state < SYSTEM_RUNNING) + return -EPROBE_DEFER; + goto fw_err; + } + + data_size = fw->size; + /* + * This uses the GFP_DMA flag to ensure we are allocated memory in the + * 32-bit space since TF-A cannot map memory beyond the 32-bit boundary. + */ + data_buf = kmalloc(fw->size, GFP_KERNEL | GFP_DMA); + if (!data_buf) { + rc = -ENOMEM; + goto fw_err; + } + memcpy(data_buf, fw->data, fw->size); + data_pa = virt_to_phys(data_buf); + reg_pair_from_64(&data_pa_high, &data_pa_low, data_pa); + reg_pair_from_64(&data_size_high, &data_size_low, data_size); + goto fw_load; + +fw_err: + pr_warn("image loading failed\n"); + data_pa_high = 0; + data_pa_low = 0; + data_size_high = 0; + data_size_low = 0; + +fw_load: + /* + * Always invoke the SMC, even if loading the image fails, to indicate + * to EL3 that we have passed the point where it should allow invoking + * this SMC. + */ + pr_warn("OP-TEE image loaded from kernel, this can be insecure"); + invoke_fn(OPTEE_SMC_CALL_LOAD_IMAGE, data_size_high, data_size_low, + data_pa_high, data_pa_low, 0, 0, 0, &res); + if (!rc) + rc = res.a0; + if (fw) + release_firmware(fw); + kfree(data_buf); + + if (!rc) { + /* + * We need to initialize OP-TEE on all other running cores as + * well. Any cores that aren't running yet will get initialized + * when they are brought up by the power management functions in + * TF-A which are registered by the OP-TEE SPD. Due to that we + * can un-register the callback right after registering it. + */ + cpuhp_invoke_fn = invoke_fn; + hp_state = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "optee:probe", + optee_cpuhp_probe, NULL); + if (hp_state < 0) { + pr_warn("Failed with CPU hotplug setup for OP-TEE"); + return -EINVAL; + } + cpuhp_remove_state(hp_state); + cpuhp_invoke_fn = NULL; + } + + return rc; +} +#else +static inline int optee_load_fw(struct platform_device *pdev, + optee_invoke_fn *invoke_fn) +{ + return 0; +} +#endif + static int optee_probe(struct platform_device *pdev) { optee_invoke_fn *invoke_fn; @@ -1372,6 +1505,10 @@ static int optee_probe(struct platform_device *pdev) if (IS_ERR(invoke_fn)) return PTR_ERR(invoke_fn); + rc = optee_load_fw(pdev, invoke_fn); + if (rc) + return rc; + if (!optee_msg_api_uid_is_optee_api(invoke_fn)) { pr_warn("api uid mismatch\n"); return -EINVAL; -- 2.40.0.348.gf938b09366-goog

3 years, 2 months

3
2
0 0

[GIT PULL] OP-TEE per-cpu irq for v6.4.

by Jens Wiklander

Hello arm-soc maintainers, Please pull these patches which add support for using per-cpu interrutps to signal asynchronous notifications from OP-TEE in secure world to the OP-TEE driver. Thanks, Jens The following changes since commit eeac8ede17557680855031c6f305ece2378af326: Linux 6.3-rc2 (2023-03-12 16:36:44 -0700) are available in the Git repository at: https://git.linaro.org/people/jens.wiklander/linux-tee.git/ tags/optee-per-cpu-irq-for-v6.4 for you to fetch changes up to b3b4ced12c1bc829888803ce07fff317e590ec1c: optee: add per cpu asynchronous notification (2023-03-30 08:27:05 +0200) ---------------------------------------------------------------- Add OP-TEE per cpu asynchronous notification Adds support for signalling from secure world with per-cpu interrupts in addition to edge-triggered peripheral interrupts. ---------------------------------------------------------------- Etienne Carriere (2): dt-bindings: optee driver interrupt can be a per-cpu interrupt optee: add per cpu asynchronous notification .../bindings/arm/firmware/linaro,optee-tz.yaml | 3 +- drivers/tee/optee/optee_private.h | 24 ++++ drivers/tee/optee/smc_abi.c | 122 ++++++++++++++++++++- 3 files changed, 144 insertions(+), 5 deletions(-)

3 years, 2 months

1
0
0 0

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

by chf.fritz＠googlemail.com

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

3 years, 2 months

1
0
0 0

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

by linux＠armlinux.org.uk

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

3 years, 2 months

1
0
0 0

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

by chf.fritz＠googlemail.com

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

3 years, 2 months

1
0
0 0

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

by chf.fritz＠googlemail.com

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

3 years, 2 months

1
0
0 0

[PATCH v12] tee: optee: Add SMC for loading OP-TEE image

by Jeffrey Kardatzke

Adds an SMC call that will pass an OP-TEE binary image to EL3 and instruct it to load it as the BL32 payload. This works in conjunction with a feature added to Trusted Firmware for ARMv8 and above architectures that supports this. The main purpose of this change is to facilitate updating the OP-TEE component on devices via a rootfs change rather than having to do a firmware update. Further details are linked to in the Kconfig file. Signed-off-by: Jeffrey Kardatzke <jkardatzke(a)chromium.org> Reviewed-by: Sumit Garg <sumit.garg(a)linaro.org> Signed-off-by: Jeffrey Kardatzke <jkardatzke(a)google.com> --- Changes in v12: - Fixed checkpatch strict issues Changes in v11: - Fixed typo in tee.rst documentation Changes in v10: - Fixed tee.rst documentation formatting Changes in v9: - Add CPU hotplug callback to init on all cores at startup Changes in v8: - Renamed params and fixed alignment issue Changes in v7: - Added documentation to Documentation/staging/tee.rst Changes in v6: - Expanded Kconfig documentation Changes in v5: - Renamed config option - Added runtime warning when config is used Changes in v4: - Update commit message - Added more documentation - Renamed config option, added ARM64 dependency Changes in v3: - Removed state tracking for driver reload - Check UID of service to verify it needs image load Changes in v2: - Fixed compile issue when feature is disabled - Addressed minor comments - Added state tracking for driver reload Documentation/staging/tee.rst | 41 ++++++++++ drivers/tee/optee/Kconfig | 17 +++++ drivers/tee/optee/optee_msg.h | 12 +++ drivers/tee/optee/optee_smc.h | 24 ++++++ drivers/tee/optee/smc_abi.c | 137 ++++++++++++++++++++++++++++++++++ 5 files changed, 231 insertions(+) diff --git a/Documentation/staging/tee.rst b/Documentation/staging/tee.rst index 498343c7ab08..b11e9053bc99 100644 --- a/Documentation/staging/tee.rst +++ b/Documentation/staging/tee.rst @@ -214,6 +214,47 @@ call is done from the thread assisting the interrupt handler. This is a building block for OP-TEE OS in secure world to implement the top half and bottom half style of device drivers. +OPTEE_INSECURE_LOAD_IMAGE Kconfig option +---------------------------------------- + +The OPTEE_INSECURE_LOAD_IMAGE Kconfig option enables the ability to load the +BL32 OP-TEE image from the kernel after the kernel boots, rather than loading +it from the firmware before the kernel boots. This also requires enabling the +corresponding option in Trusted Firmware for Arm. The documentation there +explains the security threat associated with enabling this as well as +mitigations at the firmware and platform level. +https://trustedfirmware-a.readthedocs.io/en/latest/threat_model/threat_model.html + +There are additional attack vectors/mitigations for the kernel that should be +addressed when using this option. + +1. Boot chain security. + Attack vector: Replace the OP-TEE OS image in the rootfs to gain control of + the system. + Mitigation: There must be boot chain security that verifies the kernel and + rootfs, otherwise an attacker can modify the loaded OP-TEE binary by + modifying it in the rootfs. +2. Alternate boot modes. + Attack vector: Using an alternate boot mode (i.e. recovery mode), the OP-TEE + driver isn't loaded, leaving the SMC hole open. + Mitigation: If there are alternate methods of booting the device, such as a + recovery mode, it should be ensured that the same mitigations are applied in + that mode. +3. Attacks prior to SMC invocation. + Attack vector: Code that is executed prior to issuing the SMC call to load + OP-TEE can be exploited to then load an alternate OS image. + Mitigation: The OP-TEE driver must be loaded before any potential attack + vectors are opened up. This should include mounting of any modifiable + filesystems, opening of network ports or communicating with external devices + (e.g. USB). +4. Blocking SMC call to load OP-TEE. + Attack vector: Prevent the driver from being probed, so the SMC call to load + OP-TEE isn't executed when desired, leaving it open to being executed later + and loading a modified OS. + Mitigation: It is recommended to build the OP-TEE driver as an included + driver rather than a module to prevent exploits that may cause the module to + not be loaded. + AMD-TEE driver ============== diff --git a/drivers/tee/optee/Kconfig b/drivers/tee/optee/Kconfig index f121c224e682..70898bbd5809 100644 --- a/drivers/tee/optee/Kconfig +++ b/drivers/tee/optee/Kconfig @@ -7,3 +7,20 @@ config OPTEE help This implements the OP-TEE Trusted Execution Environment (TEE) driver. + +config OPTEE_INSECURE_LOAD_IMAGE + bool "Load OP-TEE image as firmware" + default n + depends on OPTEE && ARM64 + help + This loads the BL32 image for OP-TEE as firmware when the driver is + probed. This returns -EPROBE_DEFER until the firmware is loadable from + the filesystem which is determined by checking the system_state until + it is in SYSTEM_RUNNING. This also requires enabling the corresponding + option in Trusted Firmware for Arm. The documentation there explains + the security threat associated with enabling this as well as + mitigations at the firmware and platform level. + https://trustedfirmware-a.readthedocs.io/en/latest/threat_model/threat_mode… + + Additional documentation on kernel security risks are at + Documentation/staging/tee.rst. diff --git a/drivers/tee/optee/optee_msg.h b/drivers/tee/optee/optee_msg.h index 70e9cc2ee96b..e8840a82b983 100644 --- a/drivers/tee/optee/optee_msg.h +++ b/drivers/tee/optee/optee_msg.h @@ -241,11 +241,23 @@ struct optee_msg_arg { * 384fb3e0-e7f8-11e3-af63-0002a5d5c51b. * Represented in 4 32-bit words in OPTEE_MSG_UID_0, OPTEE_MSG_UID_1, * OPTEE_MSG_UID_2, OPTEE_MSG_UID_3. + * + * In the case where the OP-TEE image is loaded by the kernel, this will + * initially return an alternate UID to reflect that we are communicating with + * the TF-A image loading service at that time instead of OP-TEE. That UID is: + * a3fbeab1-1246-315d-c7c4-06b9c03cbea4. + * Represented in 4 32-bit words in OPTEE_MSG_IMAGE_LOAD_UID_0, + * OPTEE_MSG_IMAGE_LOAD_UID_1, OPTEE_MSG_IMAGE_LOAD_UID_2, + * OPTEE_MSG_IMAGE_LOAD_UID_3. */ #define OPTEE_MSG_UID_0 0x384fb3e0 #define OPTEE_MSG_UID_1 0xe7f811e3 #define OPTEE_MSG_UID_2 0xaf630002 #define OPTEE_MSG_UID_3 0xa5d5c51b +#define OPTEE_MSG_IMAGE_LOAD_UID_0 0xa3fbeab1 +#define OPTEE_MSG_IMAGE_LOAD_UID_1 0x1246315d +#define OPTEE_MSG_IMAGE_LOAD_UID_2 0xc7c406b9 +#define OPTEE_MSG_IMAGE_LOAD_UID_3 0xc03cbea4 #define OPTEE_MSG_FUNCID_CALLS_UID 0xFF01 /* diff --git a/drivers/tee/optee/optee_smc.h b/drivers/tee/optee/optee_smc.h index 73b5e7760d10..7d9fa426505b 100644 --- a/drivers/tee/optee/optee_smc.h +++ b/drivers/tee/optee/optee_smc.h @@ -104,6 +104,30 @@ struct optee_smc_call_get_os_revision_result { unsigned long reserved1; }; +/* + * Load Trusted OS from optee/tee.bin in the Linux firmware. + * + * WARNING: Use this cautiously as it could lead to insecure loading of the + * Trusted OS. + * This SMC instructs EL3 to load a binary and execute it as the Trusted OS. + * + * Call register usage: + * a0 SMC Function ID, OPTEE_SMC_CALL_LOAD_IMAGE + * a1 Upper 32bit of a 64bit size for the payload + * a2 Lower 32bit of a 64bit size for the payload + * a3 Upper 32bit of the physical address for the payload + * a4 Lower 32bit of the physical address for the payload + * + * The payload is in the OP-TEE image format. + * + * Returns result in a0, 0 on success and an error code otherwise. + */ +#define OPTEE_SMC_FUNCID_LOAD_IMAGE 2 +#define OPTEE_SMC_CALL_LOAD_IMAGE \ + ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, ARM_SMCCC_SMC_32, \ + ARM_SMCCC_OWNER_TRUSTED_OS_END, \ + OPTEE_SMC_FUNCID_LOAD_IMAGE) + /* * Call with struct optee_msg_arg as argument * diff --git a/drivers/tee/optee/smc_abi.c b/drivers/tee/optee/smc_abi.c index a1c1fa1a9c28..6e1f023d50c6 100644 --- a/drivers/tee/optee/smc_abi.c +++ b/drivers/tee/optee/smc_abi.c @@ -7,10 +7,13 @@ #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt #include <linux/arm-smccc.h> +#include <linux/cpuhotplug.h> #include <linux/errno.h> +#include <linux/firmware.h> #include <linux/interrupt.h> #include <linux/io.h> #include <linux/irqdomain.h> +#include <linux/kernel.h> #include <linux/mm.h> #include <linux/module.h> #include <linux/of.h> @@ -1149,6 +1152,22 @@ static bool optee_msg_api_uid_is_optee_api(optee_invoke_fn *invoke_fn) return false; } +#ifdef CONFIG_OPTEE_INSECURE_LOAD_IMAGE +static bool optee_msg_api_uid_is_optee_image_load(optee_invoke_fn *invoke_fn) +{ + struct arm_smccc_res res; + + invoke_fn(OPTEE_SMC_CALLS_UID, 0, 0, 0, 0, 0, 0, 0, &res); + + if (res.a0 == OPTEE_MSG_IMAGE_LOAD_UID_0 && + res.a1 == OPTEE_MSG_IMAGE_LOAD_UID_1 && + res.a2 == OPTEE_MSG_IMAGE_LOAD_UID_2 && + res.a3 == OPTEE_MSG_IMAGE_LOAD_UID_3) + return true; + return false; +} +#endif + static void optee_msg_get_os_revision(optee_invoke_fn *invoke_fn) { union { @@ -1354,6 +1373,120 @@ static void optee_shutdown(struct platform_device *pdev) optee_disable_shm_cache(optee); } +#ifdef CONFIG_OPTEE_INSECURE_LOAD_IMAGE + +#define OPTEE_FW_IMAGE "optee/tee.bin" + +static optee_invoke_fn *cpuhp_invoke_fn; + +static int optee_cpuhp_probe(unsigned int cpu) +{ + /* + * Invoking a call on a CPU will cause OP-TEE to perform the required + * setup for that CPU. Just invoke the call to get the UID since that + * has no side effects. + */ + if (optee_msg_api_uid_is_optee_api(cpuhp_invoke_fn)) + return 0; + else + return -EINVAL; +} + +static int optee_load_fw(struct platform_device *pdev, + optee_invoke_fn *invoke_fn) +{ + const struct firmware *fw = NULL; + struct arm_smccc_res res; + phys_addr_t data_pa; + u8 *data_buf = NULL; + u64 data_size; + u32 data_pa_high, data_pa_low; + u32 data_size_high, data_size_low; + int rc; + int hp_state; + + if (!optee_msg_api_uid_is_optee_image_load(invoke_fn)) + return 0; + + rc = request_firmware(&fw, OPTEE_FW_IMAGE, &pdev->dev); + if (rc) { + /* + * The firmware in the rootfs will not be accessible until we + * are in the SYSTEM_RUNNING state, so return EPROBE_DEFER until + * that point. + */ + if (system_state < SYSTEM_RUNNING) + return -EPROBE_DEFER; + goto fw_err; + } + + data_size = fw->size; + /* + * This uses the GFP_DMA flag to ensure we are allocated memory in the + * 32-bit space since TF-A cannot map memory beyond the 32-bit boundary. + */ + data_buf = kmalloc(fw->size, GFP_KERNEL | GFP_DMA); + if (!data_buf) { + rc = -ENOMEM; + goto fw_err; + } + memcpy(data_buf, fw->data, fw->size); + data_pa = virt_to_phys(data_buf); + reg_pair_from_64(&data_pa_high, &data_pa_low, data_pa); + reg_pair_from_64(&data_size_high, &data_size_low, data_size); + goto fw_load; + +fw_err: + pr_warn("image loading failed\n"); + data_pa_high = 0; + data_pa_low = 0; + data_size_high = 0; + data_size_low = 0; + +fw_load: + /* + * Always invoke the SMC, even if loading the image fails, to indicate + * to EL3 that we have passed the point where it should allow invoking + * this SMC. + */ + pr_warn("OP-TEE image loaded from kernel, this can be insecure"); + invoke_fn(OPTEE_SMC_CALL_LOAD_IMAGE, data_size_high, data_size_low, + data_pa_high, data_pa_low, 0, 0, 0, &res); + if (!rc) + rc = res.a0; + if (fw) + release_firmware(fw); + kfree(data_buf); + + if (!rc) { + /* + * We need to initialize OP-TEE on all other running cores as + * well. Any cores that aren't running yet will get initialized + * when they are brought up by the power management functions in + * TF-A which are registered by the OP-TEE SPD. Due to that we + * can un-register the callback right after registering it. + */ + cpuhp_invoke_fn = invoke_fn; + hp_state = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "optee:probe", + optee_cpuhp_probe, NULL); + if (hp_state < 0) { + pr_warn("Failed with CPU hotplug setup for OP-TEE"); + return -EINVAL; + } + cpuhp_remove_state(hp_state); + cpuhp_invoke_fn = NULL; + } + + return rc; +} +#else +static inline int optee_load_fw(struct platform_device *pdev, + optee_invoke_fn *invoke_fn) +{ + return 0; +} +#endif + static int optee_probe(struct platform_device *pdev) { optee_invoke_fn *invoke_fn; @@ -1372,6 +1505,10 @@ static int optee_probe(struct platform_device *pdev) if (IS_ERR(invoke_fn)) return PTR_ERR(invoke_fn); + rc = optee_load_fw(pdev, invoke_fn); + if (rc) + return rc; + if (!optee_msg_api_uid_is_optee_api(invoke_fn)) { pr_warn("api uid mismatch\n"); return -EINVAL; -- 2.40.0.348.gf938b09366-goog

3 years, 2 months

2
2
0 0

[GIT PULL] TEE fix for v6.3

by Jens Wiklander

Hello arm-soc maintainers, Please pull this small fix of a call to virt_to_page() in the TEE subsystem. Thanks, Jens The following changes since commit eeac8ede17557680855031c6f305ece2378af326: Linux 6.3-rc2 (2023-03-12 16:36:44 -0700) are available in the Git repository at: https://git.linaro.org/people/jens.wiklander/linux-tee.git/ tags/tee-fix-for-v6.3 for you to fetch changes up to 8671133082176d1388e20ac33d61cf7e3b05adf5: tee: Pass a pointer to virt_to_page() (2023-03-30 08:34:52 +0200) ---------------------------------------------------------------- Add explicit cast to (void *) for virt_to_page() argument ---------------------------------------------------------------- Linus Walleij (1): tee: Pass a pointer to virt_to_page() drivers/tee/tee_shm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

3 years, 2 months

1
0
0 0

[PATCH] tee: Pass a pointer to virt_to_page()

by Linus Walleij

Like the other calls in this function virt_to_page() expects a pointer, not an integer. However since many architectures implement virt_to_pfn() as a macro, this function becomes polymorphic and accepts both a (unsigned long) and a (void *). Fix this up with an explicit cast. Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org> --- drivers/tee/tee_shm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tee/tee_shm.c b/drivers/tee/tee_shm.c index b1c6231defad..673cf0359494 100644 --- a/drivers/tee/tee_shm.c +++ b/drivers/tee/tee_shm.c @@ -32,7 +32,7 @@ static int shm_get_kernel_pages(unsigned long start, size_t page_count, is_kmap_addr((void *)start))) return -EINVAL; - page = virt_to_page(start); + page = virt_to_page((void *)start); for (n = 0; n < page_count; n++) { pages[n] = page + n; get_page(pages[n]); -- 2.34.1

3 years, 2 months

2
1
0 0

[PATCH v6 1/2] dt-bindings: optee driver interrupt can be a per-cpu interrupt

by Etienne Carriere

Explicit in optee firmware device tree bindings that the interrupt used by optee driver for async notification can be a peripheral interrupt or a per-cpu interrupt. Signed-off-by: Etienne Carriere <etienne.carriere(a)linaro.org> --- No change since v5 No change since v4 Changes since v3: - Patch added in this v4 to address review comments. --- .../devicetree/bindings/arm/firmware/linaro,optee-tz.yaml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml index d4dc0749f9fd..5d033570b57b 100644 --- a/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml +++ b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml @@ -28,7 +28,8 @@ properties: maxItems: 1 description: | This interrupt which is used to signal an event by the secure world - software is expected to be edge-triggered. + software is expected to be either a per-cpu interrupt or an + edge-triggered peripheral interrupt. method: enum: [smc, hvc] -- 2.25.1

3 years, 2 months

3
5
0 0

[PATCH][next] optee: Fix spelling mistake "Unuspported" -> "Unsupported"

by Colin Ian King

There is a spelling mistake in a #error message. Fix it. Signed-off-by: Colin Ian King <colin.i.king(a)gmail.com> --- drivers/tee/optee/call.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tee/optee/call.c b/drivers/tee/optee/call.c index 290b1bb0e9cd..df5fb5410b72 100644 --- a/drivers/tee/optee/call.c +++ b/drivers/tee/optee/call.c @@ -488,7 +488,7 @@ static bool is_normal_memory(pgprot_t p) #elif defined(CONFIG_ARM64) return (pgprot_val(p) & PTE_ATTRINDX_MASK) == PTE_ATTRINDX(MT_NORMAL); #else -#error "Unuspported architecture" +#error "Unsupported architecture" #endif } -- 2.30.2

3 years, 2 months

2
1
0 0

[Hafnium] Boot arguments for S-EL1 with SPMC at S-EL2

by 梅建强(禹夜)

Hi, Olivier, Whether Boot Information Blob is a file similar to manifest.dtb or sp.pkg? How do I generate this blob? Does it need to be packaged into atf firmware at compile phase？ Thanks. Regards, Yuye. ------------------------------------------------------------------ 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> 发送时间：2023年3月21日(星期二) 22:37 收件人：Jens Wiklander <jens.wiklander(a)linaro.org> 抄　送：hafnium(a)lists.trustedfirmware.org <hafnium(a)lists.trustedfirmware.org>; OP-TEE TrustedFirmware <op-tee(a)lists.trustedfirmware.org> 主　题：Re: [Hafnium] Boot arguments for S-EL1 with SPMC at S-EL2 Hi Jens, See comments inline [OD]. Regards, Olivier. ________________________________ From: Jens Wiklander via Hafnium <hafnium(a)lists.trustedfirmware.org> Sent: 21 March 2023 09:30 To: Olivier Deprez <Olivier.Deprez(a)arm.com> Cc: hafnium(a)lists.trustedfirmware.org <hafnium(a)lists.trustedfirmware.org>; OP-TEE TrustedFirmware <op-tee(a)lists.trustedfirmware.org> Subject: [Hafnium] Boot arguments for S-EL1 with SPMC at S-EL2 Hi Olivier, I'm trying to implement a relocatable OP-TEE binary so it can be loaded at different physical addresses without the need to recompile it. This means that in the case with Hafnium when changing "load-address" or "entrypoint-offset" in the OP-TEE SP manifest there's no need to recompile OP-TEE. For this to work OP-TEE must be able to figure out which memory range it's supposed to reside in. [OD] Fair enough, I believe that would conflate into some generic PIE support? I can see how this helps with the multi OP-TEE instances use case, perhaps? Currently, OP-TEE knows the entry point address from PC and "memory size" from X0. However, the "memory size" is from the "load-address" so "entrypoint-offset" must be subtracted from PC in order to know the allocated memory range. Do you have ideas on how OP-TEE at runtime can determine the allocated memory range? [OD] The standard way would be to use the FF-A boot protocol e.g. if you add this to OP-TEE's SP manifest: + /* Boot protocol */ + gp-register-num = <0x0>; + + /* Boot Info */ + boot-info { + compatible = "arm,ffa-manifest-boot-info"; + ffa_manifest; + }; See https://trustedfirmware-a.readthedocs.io/en/latest/components/secure-partit… <https://trustedfirmware-a.readthedocs.io/en/latest/components/secure-partit… > At SP entry, x0 contains the address of a 'Boot Information Blob' (FF-A v1.1 REL0 section 5.4.2) starting with a Boot Information Header (Table 5.9). The SP manifest DT address can be extracted from a Boot Information Descriptor (Table 5.8). Eventually the SP is able to parse its own SP manifest, into which it finds FF-A standard fields (load-address...) in addition to any impdef field added. Note the partition size is not standarded (it should probably be), so for starters you can add your own memsize field. There is some sample usage in TF-a-tests: https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tree/spm/cactus/cactus_… <https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tree/spm/cactus/cactus_… > and also in context of EDKII/StMM: https://github.com/odeprez/edk2/commit/7066c913cb227056d68ea99de5e92f2067fe… <https://github.com/odeprez/edk2/commit/7066c913cb227056d68ea99de5e92f2067fe… > Thanks, Jens -- Hafnium mailing list -- hafnium(a)lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave(a)lists.trustedfirmware.org

3 years, 2 months

2
1
0 0

[PATCH v11] tee: optee: Add SMC for loading OP-TEE image

by Jeffrey Kardatzke

Adds an SMC call that will pass an OP-TEE binary image to EL3 and instruct it to load it as the BL32 payload. This works in conjunction with a feature added to Trusted Firmware for ARMv8 and above architectures that supports this. The main purpose of this change is to facilitate updating the OP-TEE component on devices via a rootfs change rather than having to do a firmware update. Further details are linked to in the Kconfig file. Signed-off-by: Jeffrey Kardatzke <jkardatzke(a)chromium.org> Reviewed-by: Sumit Garg <sumit.garg(a)linaro.org> Signed-off-by: Jeffrey Kardatzke <jkardatzke(a)google.com> --- Changes in v11: - Fixed typo in tee.rst documentation Changes in v10: - Fixed tee.rst documentation formatting Changes in v9: - Add CPU hotplug callback to init on all cores at startup Changes in v8: - Renamed params and fixed alignment issue Changes in v7: - Added documentation to Documentation/staging/tee.rst Changes in v6: - Expanded Kconfig documentation Changes in v5: - Renamed config option - Added runtime warning when config is used Changes in v4: - Update commit message - Added more documentation - Renamed config option, added ARM64 dependency Changes in v3: - Removed state tracking for driver reload - Check UID of service to verify it needs image load Changes in v2: - Fixed compile issue when feature is disabled - Addressed minor comments - Added state tracking for driver reload Documentation/staging/tee.rst | 41 +++++++++++ drivers/tee/optee/Kconfig | 17 +++++ drivers/tee/optee/optee_msg.h | 12 +++ drivers/tee/optee/optee_smc.h | 24 ++++++ drivers/tee/optee/smc_abi.c | 134 ++++++++++++++++++++++++++++++++++ 5 files changed, 228 insertions(+) diff --git a/Documentation/staging/tee.rst b/Documentation/staging/tee.rst index 498343c7ab08..b11e9053bc99 100644 --- a/Documentation/staging/tee.rst +++ b/Documentation/staging/tee.rst @@ -214,6 +214,47 @@ call is done from the thread assisting the interrupt handler. This is a building block for OP-TEE OS in secure world to implement the top half and bottom half style of device drivers. +OPTEE_INSECURE_LOAD_IMAGE Kconfig option +---------------------------------------- + +The OPTEE_INSECURE_LOAD_IMAGE Kconfig option enables the ability to load the +BL32 OP-TEE image from the kernel after the kernel boots, rather than loading +it from the firmware before the kernel boots. This also requires enabling the +corresponding option in Trusted Firmware for Arm. The documentation there +explains the security threat associated with enabling this as well as +mitigations at the firmware and platform level. +https://trustedfirmware-a.readthedocs.io/en/latest/threat_model/threat_model.html + +There are additional attack vectors/mitigations for the kernel that should be +addressed when using this option. + +1. Boot chain security. + Attack vector: Replace the OP-TEE OS image in the rootfs to gain control of + the system. + Mitigation: There must be boot chain security that verifies the kernel and + rootfs, otherwise an attacker can modify the loaded OP-TEE binary by + modifying it in the rootfs. +2. Alternate boot modes. + Attack vector: Using an alternate boot mode (i.e. recovery mode), the OP-TEE + driver isn't loaded, leaving the SMC hole open. + Mitigation: If there are alternate methods of booting the device, such as a + recovery mode, it should be ensured that the same mitigations are applied in + that mode. +3. Attacks prior to SMC invocation. + Attack vector: Code that is executed prior to issuing the SMC call to load + OP-TEE can be exploited to then load an alternate OS image. + Mitigation: The OP-TEE driver must be loaded before any potential attack + vectors are opened up. This should include mounting of any modifiable + filesystems, opening of network ports or communicating with external devices + (e.g. USB). +4. Blocking SMC call to load OP-TEE. + Attack vector: Prevent the driver from being probed, so the SMC call to load + OP-TEE isn't executed when desired, leaving it open to being executed later + and loading a modified OS. + Mitigation: It is recommended to build the OP-TEE driver as an included + driver rather than a module to prevent exploits that may cause the module to + not be loaded. + AMD-TEE driver ============== diff --git a/drivers/tee/optee/Kconfig b/drivers/tee/optee/Kconfig index f121c224e682..70898bbd5809 100644 --- a/drivers/tee/optee/Kconfig +++ b/drivers/tee/optee/Kconfig @@ -7,3 +7,20 @@ config OPTEE help This implements the OP-TEE Trusted Execution Environment (TEE) driver. + +config OPTEE_INSECURE_LOAD_IMAGE + bool "Load OP-TEE image as firmware" + default n + depends on OPTEE && ARM64 + help + This loads the BL32 image for OP-TEE as firmware when the driver is + probed. This returns -EPROBE_DEFER until the firmware is loadable from + the filesystem which is determined by checking the system_state until + it is in SYSTEM_RUNNING. This also requires enabling the corresponding + option in Trusted Firmware for Arm. The documentation there explains + the security threat associated with enabling this as well as + mitigations at the firmware and platform level. + https://trustedfirmware-a.readthedocs.io/en/latest/threat_model/threat_mode… + + Additional documentation on kernel security risks are at + Documentation/staging/tee.rst. diff --git a/drivers/tee/optee/optee_msg.h b/drivers/tee/optee/optee_msg.h index 70e9cc2ee96b..e8840a82b983 100644 --- a/drivers/tee/optee/optee_msg.h +++ b/drivers/tee/optee/optee_msg.h @@ -241,11 +241,23 @@ struct optee_msg_arg { * 384fb3e0-e7f8-11e3-af63-0002a5d5c51b. * Represented in 4 32-bit words in OPTEE_MSG_UID_0, OPTEE_MSG_UID_1, * OPTEE_MSG_UID_2, OPTEE_MSG_UID_3. + * + * In the case where the OP-TEE image is loaded by the kernel, this will + * initially return an alternate UID to reflect that we are communicating with + * the TF-A image loading service at that time instead of OP-TEE. That UID is: + * a3fbeab1-1246-315d-c7c4-06b9c03cbea4. + * Represented in 4 32-bit words in OPTEE_MSG_IMAGE_LOAD_UID_0, + * OPTEE_MSG_IMAGE_LOAD_UID_1, OPTEE_MSG_IMAGE_LOAD_UID_2, + * OPTEE_MSG_IMAGE_LOAD_UID_3. */ #define OPTEE_MSG_UID_0 0x384fb3e0 #define OPTEE_MSG_UID_1 0xe7f811e3 #define OPTEE_MSG_UID_2 0xaf630002 #define OPTEE_MSG_UID_3 0xa5d5c51b +#define OPTEE_MSG_IMAGE_LOAD_UID_0 0xa3fbeab1 +#define OPTEE_MSG_IMAGE_LOAD_UID_1 0x1246315d +#define OPTEE_MSG_IMAGE_LOAD_UID_2 0xc7c406b9 +#define OPTEE_MSG_IMAGE_LOAD_UID_3 0xc03cbea4 #define OPTEE_MSG_FUNCID_CALLS_UID 0xFF01 /* diff --git a/drivers/tee/optee/optee_smc.h b/drivers/tee/optee/optee_smc.h index 73b5e7760d10..7d9fa426505b 100644 --- a/drivers/tee/optee/optee_smc.h +++ b/drivers/tee/optee/optee_smc.h @@ -104,6 +104,30 @@ struct optee_smc_call_get_os_revision_result { unsigned long reserved1; }; +/* + * Load Trusted OS from optee/tee.bin in the Linux firmware. + * + * WARNING: Use this cautiously as it could lead to insecure loading of the + * Trusted OS. + * This SMC instructs EL3 to load a binary and execute it as the Trusted OS. + * + * Call register usage: + * a0 SMC Function ID, OPTEE_SMC_CALL_LOAD_IMAGE + * a1 Upper 32bit of a 64bit size for the payload + * a2 Lower 32bit of a 64bit size for the payload + * a3 Upper 32bit of the physical address for the payload + * a4 Lower 32bit of the physical address for the payload + * + * The payload is in the OP-TEE image format. + * + * Returns result in a0, 0 on success and an error code otherwise. + */ +#define OPTEE_SMC_FUNCID_LOAD_IMAGE 2 +#define OPTEE_SMC_CALL_LOAD_IMAGE \ + ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, ARM_SMCCC_SMC_32, \ + ARM_SMCCC_OWNER_TRUSTED_OS_END, \ + OPTEE_SMC_FUNCID_LOAD_IMAGE) + /* * Call with struct optee_msg_arg as argument * diff --git a/drivers/tee/optee/smc_abi.c b/drivers/tee/optee/smc_abi.c index a1c1fa1a9c28..fcbcd0c0c3aa 100644 --- a/drivers/tee/optee/smc_abi.c +++ b/drivers/tee/optee/smc_abi.c @@ -7,10 +7,13 @@ #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt #include <linux/arm-smccc.h> +#include <linux/cpuhotplug.h> #include <linux/errno.h> +#include <linux/firmware.h> #include <linux/interrupt.h> #include <linux/io.h> #include <linux/irqdomain.h> +#include <linux/kernel.h> #include <linux/mm.h> #include <linux/module.h> #include <linux/of.h> @@ -1149,6 +1152,22 @@ static bool optee_msg_api_uid_is_optee_api(optee_invoke_fn *invoke_fn) return false; } +#ifdef CONFIG_OPTEE_INSECURE_LOAD_IMAGE +static bool optee_msg_api_uid_is_optee_image_load(optee_invoke_fn *invoke_fn) +{ + struct arm_smccc_res res; + + invoke_fn(OPTEE_SMC_CALLS_UID, 0, 0, 0, 0, 0, 0, 0, &res); + + if (res.a0 == OPTEE_MSG_IMAGE_LOAD_UID_0 && + res.a1 == OPTEE_MSG_IMAGE_LOAD_UID_1 && + res.a2 == OPTEE_MSG_IMAGE_LOAD_UID_2 && + res.a3 == OPTEE_MSG_IMAGE_LOAD_UID_3) + return true; + return false; +} +#endif + static void optee_msg_get_os_revision(optee_invoke_fn *invoke_fn) { union { @@ -1354,6 +1373,117 @@ static void optee_shutdown(struct platform_device *pdev) optee_disable_shm_cache(optee); } +#ifdef CONFIG_OPTEE_INSECURE_LOAD_IMAGE + +#define OPTEE_FW_IMAGE "optee/tee.bin" + +static optee_invoke_fn *cpuhp_invoke_fn; + +static int optee_cpuhp_probe(unsigned int cpu) +{ + /* + * Invoking a call on a CPU will cause OP-TEE to perform the required + * setup for that CPU. Just invoke the call to get the UID since that + * has no side effects. + */ + if (optee_msg_api_uid_is_optee_api(cpuhp_invoke_fn)) + return 0; + else + return -EINVAL; +} + +static int optee_load_fw(struct platform_device *pdev, + optee_invoke_fn *invoke_fn) +{ + const struct firmware *fw = NULL; + struct arm_smccc_res res; + phys_addr_t data_pa; + u8 *data_buf = NULL; + u64 data_size; + u32 data_pa_high, data_pa_low; + u32 data_size_high, data_size_low; + int rc; + int hp_state; + + if (!optee_msg_api_uid_is_optee_image_load(invoke_fn)) + return 0; + + rc = request_firmware(&fw, OPTEE_FW_IMAGE, &pdev->dev); + if (rc) { + /* + * The firmware in the rootfs will not be accessible until we + * are in the SYSTEM_RUNNING state, so return EPROBE_DEFER until + * that point. + */ + if (system_state < SYSTEM_RUNNING) + return -EPROBE_DEFER; + goto fw_err; + } + + data_size = fw->size; + /* + * This uses the GFP_DMA flag to ensure we are allocated memory in the + * 32-bit space since TF-A cannot map memory beyond the 32-bit boundary. + */ + data_buf = kmalloc(fw->size, GFP_KERNEL | GFP_DMA); + if (!data_buf) { + rc = -ENOMEM; + goto fw_err; + } + memcpy(data_buf, fw->data, fw->size); + data_pa = virt_to_phys(data_buf); + reg_pair_from_64(&data_pa_high, &data_pa_low, data_pa); + reg_pair_from_64(&data_size_high, &data_size_low, data_size); + goto fw_load; + +fw_err: + pr_warn("image loading failed\n"); + data_pa_high = data_pa_low = data_size_high = data_size_low = 0; + +fw_load: + /* + * Always invoke the SMC, even if loading the image fails, to indicate + * to EL3 that we have passed the point where it should allow invoking + * this SMC. + */ + pr_warn("OP-TEE image loaded from kernel, this can be insecure"); + invoke_fn(OPTEE_SMC_CALL_LOAD_IMAGE, data_size_high, data_size_low, + data_pa_high, data_pa_low, 0, 0, 0, &res); + if (!rc) + rc = res.a0; + if (fw) + release_firmware(fw); + kfree(data_buf); + + if (!rc) { + /* + * We need to initialize OP-TEE on all other running cores as + * well. Any cores that aren't running yet will get initialized + * when they are brought up by the power management functions in + * TF-A which are registered by the OP-TEE SPD. Due to that we + * can un-register the callback right after registering it. + */ + cpuhp_invoke_fn = invoke_fn; + hp_state = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "optee:probe", + optee_cpuhp_probe, NULL); + if (hp_state < 0) { + pr_warn("Failed with CPU hotplug setup for OP-TEE"); + return -EINVAL; + } + cpuhp_remove_state(hp_state); + cpuhp_invoke_fn = NULL; + } + + return rc; +} +#else +static inline int optee_load_fw(struct platform_device *pdev, + optee_invoke_fn *invoke_fn) +{ + return 0; +} +#endif + static int optee_probe(struct platform_device *pdev) { optee_invoke_fn *invoke_fn; @@ -1372,6 +1502,10 @@ static int optee_probe(struct platform_device *pdev) if (IS_ERR(invoke_fn)) return PTR_ERR(invoke_fn); + rc = optee_load_fw(pdev, invoke_fn); + if (rc) + return rc; + if (!optee_msg_api_uid_is_optee_api(invoke_fn)) { pr_warn("api uid mismatch\n"); return -EINVAL; -- 2.40.0.rc1.284.g88254d51c5-goog

3 years, 2 months

3
3
0 0

Linaro OP-TEE Contribution (LOC) monthly meeting March 28

by Jens Wiklander

Hi, It's soon time for another LOC monthly meeting. For time and connection details see the calendar at https://www.trustedfirmware.org/meetings/ If you have any topics you'd like to discuss, please let us know and we can schedule them. Thanks, Jens

3 years, 3 months

1
0
0 0

load optee at 36bit address

by 梅建强(禹夜)

Hi, experts, We seem to have solved the problem. This problem is not caused by the load_address of optee, but by the security space configured in the ATF. It seems that the security space we have configured is too large. And why will it causes the problem needs to be further identified. Regards, Yuye. ------------------------------------------------------------------ 发件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 发送时间：2023年3月22日(星期三) 11:50 收件人：Olivier Deprez <Olivier.Deprez(a)arm.com>; Jens Wiklander <jens.wiklander(a)linaro.org> 抄　送：hafnium <hafnium(a)lists.trustedfirmware.org>; op-tee <op-tee(a)lists.trustedfirmware.org> 主　题：load optee at 36bit address Hi, experts, We are currently moving optee to a 36bit address to boot with environment that hafnium runs at sel2 as spmc and optee runs at sel1 as sp. Now we have moved hafnium to 0x880000000 and run successfully. Then we tried moving optee to a 36bit address (0x89000000) as well. Although hafnium and optee were successfully initialized on the primary cpu, psci_cpu_on does not seem to be entered into when the secondary cpu is started. The error is as follows: https://github.com/OP-TEE/optee_os/issues/5895 <https://github.com/OP-TEE/optee_os/issues/5895 > Is there any difference between the two cases where hafnium and optee initialize the secondary cpu with different load_address? The log print shows that the secondary cpu has not entered hafnium. Could Hafnium be affected by the 36bit address when dealing with psci related transactions? Regards, Yuye.

3 years, 3 months

1
0
0 0

load optee at 36bit address

by 梅建强(禹夜)

Hi, experts, We are currently moving optee to a 36bit address to boot with environment that hafnium runs at sel2 as spmc and optee runs at sel1 as sp. Now we have moved hafnium to 0x880000000 and run successfully. Then we tried moving optee to a 36bit address (0x89000000) as well. Although hafnium and optee were successfully initialized on the primary cpu, psci_cpu_on does not seem to be entered into when the secondary cpu is started. The error is as follows: https://github.com/OP-TEE/optee_os/issues/5895 <https://github.com/OP-TEE/optee_os/issues/5895 > Is there any difference between the two cases where hafnium and optee initialize the secondary cpu with different load_address? The log print shows that the secondary cpu has not entered hafnium. Could Hafnium be affected by the 36bit address when dealing with psci related transactions? Regards, Yuye.

3 years, 3 months

1
1
0 0

[PATCH v5 1/4] tee: optee: system call property

by Etienne Carriere

Adds an argument to do_call_with_arg() handler to tell whether the call is a system call or nor. This change always sets this info to false hence no functional change. This change prepares management of system invocation proposed in a later change. 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> --- Changes since v4: - New change, extracted from PATCH v4 1/2 (tee: system invocation") and revised to cover preparatory changes in optee driver for system session support with contribution from Jens. --- drivers/tee/optee/call.c | 22 ++++++++++++++++------ drivers/tee/optee/core.c | 5 +++-- drivers/tee/optee/ffa_abi.c | 3 ++- drivers/tee/optee/optee_private.h | 7 +++++-- drivers/tee/optee/smc_abi.c | 9 +++++---- 5 files changed, 31 insertions(+), 15 deletions(-) diff --git a/drivers/tee/optee/call.c b/drivers/tee/optee/call.c index 290b1bb0e9cd..844d2bdc68db 100644 --- a/drivers/tee/optee/call.c +++ b/drivers/tee/optee/call.c @@ -328,7 +328,8 @@ int optee_open_session(struct tee_context *ctx, goto out; } - if (optee->ops->do_call_with_arg(ctx, shm, offs)) { + if (optee->ops->do_call_with_arg(ctx, shm, offs, + sess->use_sys_thread)) { msg_arg->ret = TEEC_ERROR_COMMUNICATION; msg_arg->ret_origin = TEEC_ORIGIN_COMMS; } @@ -360,7 +361,8 @@ int optee_open_session(struct tee_context *ctx, return rc; } -int optee_close_session_helper(struct tee_context *ctx, u32 session) +int optee_close_session_helper(struct tee_context *ctx, u32 session, + bool system_thread) { struct optee *optee = tee_get_drvdata(ctx->teedev); struct optee_shm_arg_entry *entry; @@ -374,7 +376,7 @@ int optee_close_session_helper(struct tee_context *ctx, u32 session) msg_arg->cmd = OPTEE_MSG_CMD_CLOSE_SESSION; msg_arg->session = session; - optee->ops->do_call_with_arg(ctx, shm, offs); + optee->ops->do_call_with_arg(ctx, shm, offs, system_thread); optee_free_msg_arg(ctx, entry, offs); @@ -385,6 +387,7 @@ int optee_close_session(struct tee_context *ctx, u32 session) { struct optee_context_data *ctxdata = ctx->data; struct optee_session *sess; + bool system_thread; /* Check that the session is valid and remove it from the list */ mutex_lock(&ctxdata->mutex); @@ -394,9 +397,10 @@ int optee_close_session(struct tee_context *ctx, u32 session) mutex_unlock(&ctxdata->mutex); if (!sess) return -EINVAL; + system_thread = sess->use_sys_thread; kfree(sess); - return optee_close_session_helper(ctx, session); + return optee_close_session_helper(ctx, session, system_thread); } int optee_invoke_func(struct tee_context *ctx, struct tee_ioctl_invoke_arg *arg, @@ -408,12 +412,15 @@ int optee_invoke_func(struct tee_context *ctx, struct tee_ioctl_invoke_arg *arg, struct optee_msg_arg *msg_arg; struct optee_session *sess; struct tee_shm *shm; + bool system_thread; u_int offs; int rc; /* Check that the session is valid */ mutex_lock(&ctxdata->mutex); sess = find_session(ctxdata, arg->session); + if (sess) + system_thread = sess->use_sys_thread; mutex_unlock(&ctxdata->mutex); if (!sess) return -EINVAL; @@ -432,7 +439,7 @@ int optee_invoke_func(struct tee_context *ctx, struct tee_ioctl_invoke_arg *arg, if (rc) goto out; - if (optee->ops->do_call_with_arg(ctx, shm, offs)) { + if (optee->ops->do_call_with_arg(ctx, shm, offs, system_thread)) { msg_arg->ret = TEEC_ERROR_COMMUNICATION; msg_arg->ret_origin = TEEC_ORIGIN_COMMS; } @@ -457,12 +464,15 @@ int optee_cancel_req(struct tee_context *ctx, u32 cancel_id, u32 session) struct optee_shm_arg_entry *entry; struct optee_msg_arg *msg_arg; struct optee_session *sess; + bool system_thread; struct tee_shm *shm; u_int offs; /* Check that the session is valid */ mutex_lock(&ctxdata->mutex); sess = find_session(ctxdata, session); + if (sess) + system_thread = sess->use_sys_thread; mutex_unlock(&ctxdata->mutex); if (!sess) return -EINVAL; @@ -474,7 +484,7 @@ int optee_cancel_req(struct tee_context *ctx, u32 cancel_id, u32 session) msg_arg->cmd = OPTEE_MSG_CMD_CANCEL; msg_arg->session = session; msg_arg->cancel_id = cancel_id; - optee->ops->do_call_with_arg(ctx, shm, offs); + optee->ops->do_call_with_arg(ctx, shm, offs, system_thread); optee_free_msg_arg(ctx, entry, offs); return 0; diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c index 2a258bd3b6b5..d01ca47f7bde 100644 --- a/drivers/tee/optee/core.c +++ b/drivers/tee/optee/core.c @@ -129,7 +129,8 @@ int optee_open(struct tee_context *ctx, bool cap_memref_null) static void optee_release_helper(struct tee_context *ctx, int (*close_session)(struct tee_context *ctx, - u32 session)) + u32 session, + bool system_thread)) { struct optee_context_data *ctxdata = ctx->data; struct optee_session *sess; @@ -141,7 +142,7 @@ static void optee_release_helper(struct tee_context *ctx, list_for_each_entry_safe(sess, sess_tmp, &ctxdata->sess_list, list_node) { list_del(&sess->list_node); - close_session(ctx, sess->session_id); + close_session(ctx, sess->session_id, sess->use_sys_thread); kfree(sess); } kfree(ctxdata); diff --git a/drivers/tee/optee/ffa_abi.c b/drivers/tee/optee/ffa_abi.c index 0828240f27e6..52cec9d06041 100644 --- a/drivers/tee/optee/ffa_abi.c +++ b/drivers/tee/optee/ffa_abi.c @@ -612,7 +612,8 @@ static int optee_ffa_yielding_call(struct tee_context *ctx, */ static int optee_ffa_do_call_with_arg(struct tee_context *ctx, - struct tee_shm *shm, u_int offs) + struct tee_shm *shm, u_int offs, + bool system_thread) { struct ffa_send_direct_data data = { .data0 = OPTEE_FFA_YIELDING_CALL_WITH_ARG, diff --git a/drivers/tee/optee/optee_private.h b/drivers/tee/optee/optee_private.h index 04ae58892608..bdbc0dc293bb 100644 --- a/drivers/tee/optee/optee_private.h +++ b/drivers/tee/optee/optee_private.h @@ -130,7 +130,8 @@ struct optee; */ struct optee_ops { int (*do_call_with_arg)(struct tee_context *ctx, - struct tee_shm *shm_arg, u_int offs); + struct tee_shm *shm_arg, u_int offs, + bool system_thread); int (*to_msg_param)(struct optee *optee, struct optee_msg_param *msg_params, size_t num_params, const struct tee_param *params); @@ -180,6 +181,7 @@ struct optee { struct optee_session { struct list_head list_node; u32 session_id; + bool use_sys_thread; }; struct optee_context_data { @@ -228,7 +230,8 @@ 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_close_session_helper(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); int optee_invoke_func(struct tee_context *ctx, struct tee_ioctl_invoke_arg *arg, struct tee_param *param); diff --git a/drivers/tee/optee/smc_abi.c b/drivers/tee/optee/smc_abi.c index a1c1fa1a9c28..df77700804e5 100644 --- a/drivers/tee/optee/smc_abi.c +++ b/drivers/tee/optee/smc_abi.c @@ -487,7 +487,7 @@ static int optee_shm_register(struct tee_context *ctx, struct tee_shm *shm, msg_arg->params->u.tmem.buf_ptr = virt_to_phys(pages_list) | (tee_shm_get_page_offset(shm) & (OPTEE_MSG_NONCONTIG_PAGE_SIZE - 1)); - if (optee->ops->do_call_with_arg(ctx, shm_arg, 0) || + if (optee->ops->do_call_with_arg(ctx, shm_arg, 0, false) || msg_arg->ret != TEEC_SUCCESS) rc = -EINVAL; @@ -530,7 +530,7 @@ static int optee_shm_unregister(struct tee_context *ctx, struct tee_shm *shm) msg_arg->params[0].attr = OPTEE_MSG_ATTR_TYPE_RMEM_INPUT; msg_arg->params[0].u.rmem.shm_ref = (unsigned long)shm; - if (optee->ops->do_call_with_arg(ctx, shm_arg, 0) || + if (optee->ops->do_call_with_arg(ctx, shm_arg, 0, false) || msg_arg->ret != TEEC_SUCCESS) rc = -EINVAL; out: @@ -865,7 +865,8 @@ static void optee_handle_rpc(struct tee_context *ctx, * Returns return code from secure world, 0 is OK */ static int optee_smc_do_call_with_arg(struct tee_context *ctx, - struct tee_shm *shm, u_int offs) + struct tee_shm *shm, u_int offs, + bool system_thread) { struct optee *optee = tee_get_drvdata(ctx->teedev); struct optee_call_waiter w; @@ -957,7 +958,7 @@ static int simple_call_with_arg(struct tee_context *ctx, u32 cmd) return PTR_ERR(msg_arg); msg_arg->cmd = cmd; - optee_smc_do_call_with_arg(ctx, shm, offs); + optee_smc_do_call_with_arg(ctx, shm, offs, false); optee_free_msg_arg(ctx, entry, offs); return 0; -- 2.25.1

3 years, 3 months

2
4
0 0

Boot arguments for S-EL1 with SPMC at S-EL2

by Jens Wiklander

Hi Olivier, I'm trying to implement a relocatable OP-TEE binary so it can be loaded at different physical addresses without the need to recompile it. This means that in the case with Hafnium when changing "load-address" or "entrypoint-offset" in the OP-TEE SP manifest there's no need to recompile OP-TEE. For this to work OP-TEE must be able to figure out which memory range it's supposed to reside in. Currently, OP-TEE knows the entry point address from PC and "memory size" from X0. However, the "memory size" is from the "load-address" so "entrypoint-offset" must be subtracted from PC in order to know the allocated memory range. Do you have ideas on how OP-TEE at runtime can determine the allocated memory range? Thanks, Jens

3 years, 3 months

2
2
0 0

Needing some help with OPTEE API and possible support

by Stroble, Matthew Scott

Hi OPTEE Developers, I am writing this email to you because we need some assistance with working with OPTEE OS in both QEMU v7 and a hardware implementation (rock pi 4b). We are currently able to get some aspects of our project working in the QEMU environment and need some assistance with OPTEE OS API documentation and possibly some help implementing a protocol we have developed to work with OPTEE OS. If possible we would like to schedule a Microsoft Teams meeting. Thank you for our time, Matthew

3 years, 3 months

3
2
0 0

Re: optee xtest cannot run success stably

by 梅建强(禹夜)

Hi, Jens, We seem to have found the answer following the comment you gave in the issue: https://github.com/OP-TEE/optee_os/issues/5877 <https://github.com/OP-TEE/optee_os/issues/5877 > The reason seems to be that the system has more non-secure memory than what OP-TEE is aware of. When our system memory DRAM size is 32GB, optee has the following configuration for non-secure state memory: #define DRAM1_BASE 0x880000000UL #define DRAM1_SIZE 0x780000000UL On another device, our system memory DRAM size is 64G, optee uses the above configuration for non-secure memory. And xtest will not run stably. In addition, I would like to ask you a few questions in order to understand the problem better. 1. System has more non-secure memory than what OP-TEE is aware of, and optee will not run stably. Why? What is the root cause of TEEC_ERROR_OUT_OF_MEMORY on the issue? I'll do some research on it myself, meanwhile I hope you could give us some insights. 2. When I execute the following command, for i in {1.. 10}; do ./xtest&; done; xtest prints out of order, And the following error is reported: E/TC:032 002 mobj_ffa_get_by_cookie:356 possible spinlock deadlock reminder 1 E/TC:070 mobj_ffa_unregister_by_cookie:310 possible spinlock deadlock reminder 1 E/TC:004 003 mobj_ffa_get_by_cookie:356 possible spinlock deadlock reminder 1 E/TC:058 001 mobj_ffa_get_by_cookie:356 possible spinlock deadlock reminder 1 Then the system hangs and restarts automatically. Does optee currently support running multiple TAs in parallel? Is the maximum number of TAs running in parallel equal to the number of vcpus? 3. The values of MAX_XLAT_TABLES and CFG_CORE_HEAP_SIZE also seem to affect the stability of the system. What configurations, such as the number of cores, should I pay attention to if I want to configure appropriate values for these options? Thanks a lot. Regards, Yuye. ------------------------------------------------------------------ 发件人：Jens Wiklander <jens.wiklander(a)linaro.org> 发送时间：2023年3月20日(星期一) 15:05 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 抄　送：Olivier Deprez <Olivier.Deprez(a)arm.com>; hafnium <hafnium(a)lists.trustedfirmware.org>; op-tee <op-tee(a)lists.trustedfirmware.org> 主　题：Re: optee xtest cannot run success stably Hi Yuye, Comment below. On Mon, Mar 20, 2023 at 4:43 AM 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> wrote: > Hi, experts > > Recently, we are testing the stability for running optee xtest with environment that hafnium runs as SPMC and optee runs on SPMC as SP. > When we reboot the system, xtest failed on some cases with TEEC_ERROR_OUT_OF_MEMORY. > It seems to be that there is an insufficient memory allocation somewhere in the chain. > We tried the following: > Using Single core startup, > Increased optee MAX_XLAT_TABLES size to 16, > Increased optee CFG_CORE_HEAP_SIZE to 0x2000000, > Increasing the size of optee CFG_TEE_RAM_VA_SIZE to 0x4000000, > Increasing the size of hafnium heap_pages to 8192, > But nothing seems to be working. > Can you offer any help or suggestions? It would help if you could pinpoint the source of the out-of-memory error. I guess it happens somewhere during mobj_ffa_get_by_cookie(), where especially thread_spmc_populate_mobj_from_rx() is interesting. It could also be worth setting CFG_CORE_DUMP_OOM=y, it's easy to enable but I'm afraid it's more of a long shot. Cheers, Jens > Some other configuration for optee is attached in the issue: > https://github.com/OP-TEE/optee_os/issues/5893 <https://github.com/OP-TEE/optee_os/issues/5893 > > > Regards, > Yuye. >

3 years, 3 months

2
1
0 0

optee xtest cannot run success stably

by 梅建强(禹夜)

Hi, experts Recently, we are testing the stability for running optee xtest with environment that hafnium runs as SPMC and optee runs on SPMC as SP. When we reboot the system, xtest failed on some cases with TEEC_ERROR_OUT_OF_MEMORY. It seems to be that there is an insufficient memory allocation somewhere in the chain. We tried the following: Using Single core startup, Increased optee MAX_XLAT_TABLES size to 16, Increased optee CFG_CORE_HEAP_SIZE to 0x2000000, Increasing the size of optee CFG_TEE_RAM_VA_SIZE to 0x4000000, Increasing the size of hafnium heap_pages to 8192, But nothing seems to be working. Can you offer any help or suggestions? Some other configuration for optee is attached in the issue: https://github.com/OP-TEE/optee_os/issues/5893 <https://github.com/OP-TEE/optee_os/issues/5893 > Regards, Yuye.

3 years, 3 months

2
1
0 0

[PATCH v10] tee: optee: Add SMC for loading OP-TEE image

by Jeffrey Kardatzke

Adds an SMC call that will pass an OP-TEE binary image to EL3 and instruct it to load it as the BL32 payload. This works in conjunction with a feature added to Trusted Firmware for ARMv8 and above architectures that supports this. The main purpose of this change is to facilitate updating the OP-TEE component on devices via a rootfs change rather than having to do a firmware update. Further details are linked to in the Kconfig file. Signed-off-by: Jeffrey Kardatzke <jkardatzke(a)chromium.org> Signed-off-by: Jeffrey Kardatzke <jkardatzke(a)google.com> --- Changes in v10: - Fixed tee.rst documentation formatting Changes in v9: - Add CPU hotplug callback to init on all cores at startup Changes in v8: - Renamed params and fixed alignment issue Changes in v7: - Added documentation to Documentation/staging/tee.rst Changes in v6: - Expanded Kconfig documentation Changes in v5: - Renamed config option - Added runtime warning when config is used Changes in v4: - Update commit message - Added more documentation - Renamed config option, added ARM64 dependency Changes in v3: - Removed state tracking for driver reload - Check UID of service to verify it needs image load Changes in v2: - Fixed compile issue when feature is disabled - Addressed minor comments - Added state tracking for driver reload Documentation/staging/tee.rst | 41 +++++++++++ drivers/tee/optee/Kconfig | 17 +++++ drivers/tee/optee/optee_msg.h | 12 +++ drivers/tee/optee/optee_smc.h | 24 ++++++ drivers/tee/optee/smc_abi.c | 134 ++++++++++++++++++++++++++++++++++ 5 files changed, 228 insertions(+) diff --git a/Documentation/staging/tee.rst b/Documentation/staging/tee.rst index 498343c7ab08..6e90ee726880 100644 --- a/Documentation/staging/tee.rst +++ b/Documentation/staging/tee.rst @@ -214,6 +214,47 @@ call is done from the thread assisting the interrupt handler. This is a building block for OP-TEE OS in secure world to implement the top half and bottom half style of device drivers. +OPTEE_INSECURE_LOAD_IMAGE Kconfig option +---------------------------------------- + +The OPTEE_INSECURE_LOAD_IMAGE Kconfig option enables the ability to load the +BL32 OP-TEE image from the kernel after the kernel boots, rather than loading +it from the firmware before the kernel boots. This also requires enabling the +corresponding option in Trusted Firmware for Arm. The documentation there +explains the security threat associated with enabling this as well as +mitigations at the firmware and platform level. +https://trustedfirmware-a.readthedocs.io/en/latest/threat_model/threat_model.html + +There are additional attack vectors/mitigations for the kernel that should be +addressed when using this option. + +1. Boot chain security. + Attack vector: Replace the OP-TEE OS image in the rootfs to gain control of + the system. + Migitation: There must be boot chain security that verifies the kernel and + rootfs, otherwise an attacker can modify the loaded OP-TEE binary by + modifying it in the rootfs. +2. Alternate boot modes. + Attack vector: Using an alternate boot mode (i.e. recovery mode), the OP-TEE + driver isn't loaded, leaving the SMC hole open. + Mitigation: If there are alternate methods of booting the device, such as a + recovery mode, it should be ensured that the same mitigations are applied in + that mode. +3. Attacks prior to SMC invocation. + Attack vector: Code that is executed prior to issuing the SMC call to load + OP-TEE can be exploited to then load an alternate OS image. + Mitigation: The OP-TEE driver must be loaded before any potential attack + vectors are opened up. This should include mounting of any modifiable + filesystems, opening of network ports or communicating with external devices + (e.g. USB). +4. Blocking SMC call to load OP-TEE. + Attack vector: Prevent the driver from being probed, so the SMC call to load + OP-TEE isn't executed when desired, leaving it open to being executed later + and loading a modified OS. + Mitigation: It is recommended to build the OP-TEE driver as an included + driver rather than a module to prevent exploits that may cause the module to + not be loaded. + AMD-TEE driver ============== diff --git a/drivers/tee/optee/Kconfig b/drivers/tee/optee/Kconfig index f121c224e682..70898bbd5809 100644 --- a/drivers/tee/optee/Kconfig +++ b/drivers/tee/optee/Kconfig @@ -7,3 +7,20 @@ config OPTEE help This implements the OP-TEE Trusted Execution Environment (TEE) driver. + +config OPTEE_INSECURE_LOAD_IMAGE + bool "Load OP-TEE image as firmware" + default n + depends on OPTEE && ARM64 + help + This loads the BL32 image for OP-TEE as firmware when the driver is + probed. This returns -EPROBE_DEFER until the firmware is loadable from + the filesystem which is determined by checking the system_state until + it is in SYSTEM_RUNNING. This also requires enabling the corresponding + option in Trusted Firmware for Arm. The documentation there explains + the security threat associated with enabling this as well as + mitigations at the firmware and platform level. + https://trustedfirmware-a.readthedocs.io/en/latest/threat_model/threat_mode… + + Additional documentation on kernel security risks are at + Documentation/staging/tee.rst. diff --git a/drivers/tee/optee/optee_msg.h b/drivers/tee/optee/optee_msg.h index 70e9cc2ee96b..e8840a82b983 100644 --- a/drivers/tee/optee/optee_msg.h +++ b/drivers/tee/optee/optee_msg.h @@ -241,11 +241,23 @@ struct optee_msg_arg { * 384fb3e0-e7f8-11e3-af63-0002a5d5c51b. * Represented in 4 32-bit words in OPTEE_MSG_UID_0, OPTEE_MSG_UID_1, * OPTEE_MSG_UID_2, OPTEE_MSG_UID_3. + * + * In the case where the OP-TEE image is loaded by the kernel, this will + * initially return an alternate UID to reflect that we are communicating with + * the TF-A image loading service at that time instead of OP-TEE. That UID is: + * a3fbeab1-1246-315d-c7c4-06b9c03cbea4. + * Represented in 4 32-bit words in OPTEE_MSG_IMAGE_LOAD_UID_0, + * OPTEE_MSG_IMAGE_LOAD_UID_1, OPTEE_MSG_IMAGE_LOAD_UID_2, + * OPTEE_MSG_IMAGE_LOAD_UID_3. */ #define OPTEE_MSG_UID_0 0x384fb3e0 #define OPTEE_MSG_UID_1 0xe7f811e3 #define OPTEE_MSG_UID_2 0xaf630002 #define OPTEE_MSG_UID_3 0xa5d5c51b +#define OPTEE_MSG_IMAGE_LOAD_UID_0 0xa3fbeab1 +#define OPTEE_MSG_IMAGE_LOAD_UID_1 0x1246315d +#define OPTEE_MSG_IMAGE_LOAD_UID_2 0xc7c406b9 +#define OPTEE_MSG_IMAGE_LOAD_UID_3 0xc03cbea4 #define OPTEE_MSG_FUNCID_CALLS_UID 0xFF01 /* diff --git a/drivers/tee/optee/optee_smc.h b/drivers/tee/optee/optee_smc.h index 73b5e7760d10..7d9fa426505b 100644 --- a/drivers/tee/optee/optee_smc.h +++ b/drivers/tee/optee/optee_smc.h @@ -104,6 +104,30 @@ struct optee_smc_call_get_os_revision_result { unsigned long reserved1; }; +/* + * Load Trusted OS from optee/tee.bin in the Linux firmware. + * + * WARNING: Use this cautiously as it could lead to insecure loading of the + * Trusted OS. + * This SMC instructs EL3 to load a binary and execute it as the Trusted OS. + * + * Call register usage: + * a0 SMC Function ID, OPTEE_SMC_CALL_LOAD_IMAGE + * a1 Upper 32bit of a 64bit size for the payload + * a2 Lower 32bit of a 64bit size for the payload + * a3 Upper 32bit of the physical address for the payload + * a4 Lower 32bit of the physical address for the payload + * + * The payload is in the OP-TEE image format. + * + * Returns result in a0, 0 on success and an error code otherwise. + */ +#define OPTEE_SMC_FUNCID_LOAD_IMAGE 2 +#define OPTEE_SMC_CALL_LOAD_IMAGE \ + ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, ARM_SMCCC_SMC_32, \ + ARM_SMCCC_OWNER_TRUSTED_OS_END, \ + OPTEE_SMC_FUNCID_LOAD_IMAGE) + /* * Call with struct optee_msg_arg as argument * diff --git a/drivers/tee/optee/smc_abi.c b/drivers/tee/optee/smc_abi.c index a1c1fa1a9c28..fcbcd0c0c3aa 100644 --- a/drivers/tee/optee/smc_abi.c +++ b/drivers/tee/optee/smc_abi.c @@ -7,10 +7,13 @@ #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt #include <linux/arm-smccc.h> +#include <linux/cpuhotplug.h> #include <linux/errno.h> +#include <linux/firmware.h> #include <linux/interrupt.h> #include <linux/io.h> #include <linux/irqdomain.h> +#include <linux/kernel.h> #include <linux/mm.h> #include <linux/module.h> #include <linux/of.h> @@ -1149,6 +1152,22 @@ static bool optee_msg_api_uid_is_optee_api(optee_invoke_fn *invoke_fn) return false; } +#ifdef CONFIG_OPTEE_INSECURE_LOAD_IMAGE +static bool optee_msg_api_uid_is_optee_image_load(optee_invoke_fn *invoke_fn) +{ + struct arm_smccc_res res; + + invoke_fn(OPTEE_SMC_CALLS_UID, 0, 0, 0, 0, 0, 0, 0, &res); + + if (res.a0 == OPTEE_MSG_IMAGE_LOAD_UID_0 && + res.a1 == OPTEE_MSG_IMAGE_LOAD_UID_1 && + res.a2 == OPTEE_MSG_IMAGE_LOAD_UID_2 && + res.a3 == OPTEE_MSG_IMAGE_LOAD_UID_3) + return true; + return false; +} +#endif + static void optee_msg_get_os_revision(optee_invoke_fn *invoke_fn) { union { @@ -1354,6 +1373,117 @@ static void optee_shutdown(struct platform_device *pdev) optee_disable_shm_cache(optee); } +#ifdef CONFIG_OPTEE_INSECURE_LOAD_IMAGE + +#define OPTEE_FW_IMAGE "optee/tee.bin" + +static optee_invoke_fn *cpuhp_invoke_fn; + +static int optee_cpuhp_probe(unsigned int cpu) +{ + /* + * Invoking a call on a CPU will cause OP-TEE to perform the required + * setup for that CPU. Just invoke the call to get the UID since that + * has no side effects. + */ + if (optee_msg_api_uid_is_optee_api(cpuhp_invoke_fn)) + return 0; + else + return -EINVAL; +} + +static int optee_load_fw(struct platform_device *pdev, + optee_invoke_fn *invoke_fn) +{ + const struct firmware *fw = NULL; + struct arm_smccc_res res; + phys_addr_t data_pa; + u8 *data_buf = NULL; + u64 data_size; + u32 data_pa_high, data_pa_low; + u32 data_size_high, data_size_low; + int rc; + int hp_state; + + if (!optee_msg_api_uid_is_optee_image_load(invoke_fn)) + return 0; + + rc = request_firmware(&fw, OPTEE_FW_IMAGE, &pdev->dev); + if (rc) { + /* + * The firmware in the rootfs will not be accessible until we + * are in the SYSTEM_RUNNING state, so return EPROBE_DEFER until + * that point. + */ + if (system_state < SYSTEM_RUNNING) + return -EPROBE_DEFER; + goto fw_err; + } + + data_size = fw->size; + /* + * This uses the GFP_DMA flag to ensure we are allocated memory in the + * 32-bit space since TF-A cannot map memory beyond the 32-bit boundary. + */ + data_buf = kmalloc(fw->size, GFP_KERNEL | GFP_DMA); + if (!data_buf) { + rc = -ENOMEM; + goto fw_err; + } + memcpy(data_buf, fw->data, fw->size); + data_pa = virt_to_phys(data_buf); + reg_pair_from_64(&data_pa_high, &data_pa_low, data_pa); + reg_pair_from_64(&data_size_high, &data_size_low, data_size); + goto fw_load; + +fw_err: + pr_warn("image loading failed\n"); + data_pa_high = data_pa_low = data_size_high = data_size_low = 0; + +fw_load: + /* + * Always invoke the SMC, even if loading the image fails, to indicate + * to EL3 that we have passed the point where it should allow invoking + * this SMC. + */ + pr_warn("OP-TEE image loaded from kernel, this can be insecure"); + invoke_fn(OPTEE_SMC_CALL_LOAD_IMAGE, data_size_high, data_size_low, + data_pa_high, data_pa_low, 0, 0, 0, &res); + if (!rc) + rc = res.a0; + if (fw) + release_firmware(fw); + kfree(data_buf); + + if (!rc) { + /* + * We need to initialize OP-TEE on all other running cores as + * well. Any cores that aren't running yet will get initialized + * when they are brought up by the power management functions in + * TF-A which are registered by the OP-TEE SPD. Due to that we + * can un-register the callback right after registering it. + */ + cpuhp_invoke_fn = invoke_fn; + hp_state = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "optee:probe", + optee_cpuhp_probe, NULL); + if (hp_state < 0) { + pr_warn("Failed with CPU hotplug setup for OP-TEE"); + return -EINVAL; + } + cpuhp_remove_state(hp_state); + cpuhp_invoke_fn = NULL; + } + + return rc; +} +#else +static inline int optee_load_fw(struct platform_device *pdev, + optee_invoke_fn *invoke_fn) +{ + return 0; +} +#endif + static int optee_probe(struct platform_device *pdev) { optee_invoke_fn *invoke_fn; @@ -1372,6 +1502,10 @@ static int optee_probe(struct platform_device *pdev) if (IS_ERR(invoke_fn)) return PTR_ERR(invoke_fn); + rc = optee_load_fw(pdev, invoke_fn); + if (rc) + return rc; + if (!optee_msg_api_uid_is_optee_api(invoke_fn)) { pr_warn("api uid mismatch\n"); return -EINVAL; -- 2.40.0.rc1.284.g88254d51c5-goog

3 years, 3 months

2
1
0 0

[PATCH v4 0/8] Export platform features from ccp driver

by Mario Limonciello

The i2c-designware-amdpsp driver communicates with a platform features mailbox provided by the PSP. The address used for communication is discovered via a non-architecturally guaranteed mechanism. To better scale, export a feature for communication with platform features directly from the ccp driver. v3->v4 Drop the ACPI ID as result of confirmation with internal team. Future platforms should use doorbell, so will treat Cezanne as quirk and assume doorbell going forward. Mario Limonciello (8): crypto: ccp: Drop TEE support for IRQ handler crypto: ccp: Add a header for multiple drivers to use `__psp_pa` crypto: ccp: Move some PSP mailbox bit definitions into common header crypto: ccp: Add support for an interface for platform features crypto: ccp: Enable platform access interface on client PSP parts i2c: designware: Use PCI PSP driver for communication crypto: ccp: Add support for ringing a platform doorbell i2c: designware: Add doorbell support for Skyrim arch/x86/kvm/svm/sev.c | 1 + drivers/crypto/ccp/Makefile | 3 +- drivers/crypto/ccp/platform-access.c | 232 ++++++++++++++++++++ drivers/crypto/ccp/platform-access.h | 35 +++ drivers/crypto/ccp/psp-dev.c | 32 +-- drivers/crypto/ccp/psp-dev.h | 11 +- drivers/crypto/ccp/sev-dev.c | 16 +- drivers/crypto/ccp/sev-dev.h | 2 +- drivers/crypto/ccp/sp-dev.h | 10 + drivers/crypto/ccp/sp-pci.c | 9 + drivers/crypto/ccp/tee-dev.c | 17 +- drivers/i2c/busses/Kconfig | 2 +- drivers/i2c/busses/i2c-designware-amdpsp.c | 188 ++++------------ drivers/i2c/busses/i2c-designware-core.h | 1 - drivers/i2c/busses/i2c-designware-platdrv.c | 1 - drivers/tee/amdtee/call.c | 2 +- drivers/tee/amdtee/shm_pool.c | 2 +- include/linux/psp-platform-access.h | 65 ++++++ include/linux/psp-sev.h | 8 - include/linux/psp.h | 29 +++ 20 files changed, 461 insertions(+), 205 deletions(-) create mode 100644 drivers/crypto/ccp/platform-access.c create mode 100644 drivers/crypto/ccp/platform-access.h create mode 100644 include/linux/psp-platform-access.h create mode 100644 include/linux/psp.h -- 2.34.1

3 years, 3 months

2
2
0 0

[PATCH v9] tee: optee: Add SMC for loading OP-TEE image

by Jeffrey Kardatzke

Adds an SMC call that will pass an OP-TEE binary image to EL3 and instruct it to load it as the BL32 payload. This works in conjunction with a feature added to Trusted Firmware for ARMv8 and above architectures that supports this. The main purpose of this change is to facilitate updating the OP-TEE component on devices via a rootfs change rather than having to do a firmware update. Further details are linked to in the Kconfig file. Signed-off-by: Jeffrey Kardatzke <jkardatzke(a)chromium.org> Signed-off-by: Jeffrey Kardatzke <jkardatzke(a)google.com> --- Changes in v9: - Add CPU hotplug callback to init on all cores at startup Changes in v8: - Renamed params and fixed alignment issue Changes in v7: - Added documentation to Documentation/staging/tee.rst Changes in v6: - Expanded Kconfig documentation Changes in v5: - Renamed config option - Added runtime warning when config is used Changes in v4: - Update commit message - Added more documentation - Renamed config option, added ARM64 dependency Changes in v3: - Removed state tracking for driver reload - Check UID of service to verify it needs image load Changes in v2: - Fixed compile issue when feature is disabled - Addressed minor comments - Added state tracking for driver reload Documentation/staging/tee.rst | 41 +++++++++++ drivers/tee/optee/Kconfig | 17 +++++ drivers/tee/optee/optee_msg.h | 12 +++ drivers/tee/optee/optee_smc.h | 24 ++++++ drivers/tee/optee/smc_abi.c | 134 ++++++++++++++++++++++++++++++++++ 5 files changed, 228 insertions(+) diff --git a/Documentation/staging/tee.rst b/Documentation/staging/tee.rst index 498343c7ab08..315aa8e35e6b 100644 --- a/Documentation/staging/tee.rst +++ b/Documentation/staging/tee.rst @@ -214,6 +214,47 @@ call is done from the thread assisting the interrupt handler. This is a building block for OP-TEE OS in secure world to implement the top half and bottom half style of device drivers. +OPTEE_INSECURE_LOAD_IMAGE Kconfig option +---------------------------------------- + +The OPTEE_INSECURE_LOAD_IMAGE Kconfig option enables the ability to load the +BL32 OP-TEE image from the kernel after the kernel boots, rather than loading +it from the firmware before the kernel boots. This also requires enabling the +corresponding option in Trusted Firmware for Arm. The documentation there +explains the security threat associated with enabling this as well as +mitigations at the firmware and platform level. +https://trustedfirmware-a.readthedocs.io/en/latest/threat_model/threat_model.html + +There are additional attack vectors/mitigations for the kernel that should be +addressed when using this option. + +1. Boot chain security. + Attack vector: Replace the OP-TEE OS image in the rootfs to gain control of + the system. + Migitation: There must be boot chain security that verifies the kernel and + rootfs, otherwise an attacker can modify the loaded OP-TEE + binary by modifying it in the rootfs. +3. Alternate boot modes. + Attack vector: Using an alternate boot mode (i.e. recovery mode), the OP-TEE + driver isn't loaded, leaving the SMC hole open. + Mitigation: If there are alternate methods of booting the device, such as a + recovery mode, it should be ensured that the same mitigations are + applied in that mode. +3. Attacks prior to SMC invocation. + Attack vector: Code that is executed prior to issuing the SMC call to load + OP-TEE can be exploited to then load an alternate OS image. + Mitigation: The OP-TEE driver must be loaded before any potential attack + vectors are opened up. This should include mounting of any + modifiable filesystems, opening of network ports or communicating + with external devices (e.g. USB). +4. Blocking SMC call to load OP-TEE. + Attack vector: Prevent the driver from being probed, so the SMC call to load + OP-TEE isn't executed when desired, leaving it open to being + executed later and loading a modified OS. + Mitigation: It is recommended to build the OP-TEE driver as an included + driver rather than a module to prevent exploits that may cause + the module to not be loaded. + AMD-TEE driver ============== diff --git a/drivers/tee/optee/Kconfig b/drivers/tee/optee/Kconfig index f121c224e682..70898bbd5809 100644 --- a/drivers/tee/optee/Kconfig +++ b/drivers/tee/optee/Kconfig @@ -7,3 +7,20 @@ config OPTEE help This implements the OP-TEE Trusted Execution Environment (TEE) driver. + +config OPTEE_INSECURE_LOAD_IMAGE + bool "Load OP-TEE image as firmware" + default n + depends on OPTEE && ARM64 + help + This loads the BL32 image for OP-TEE as firmware when the driver is + probed. This returns -EPROBE_DEFER until the firmware is loadable from + the filesystem which is determined by checking the system_state until + it is in SYSTEM_RUNNING. This also requires enabling the corresponding + option in Trusted Firmware for Arm. The documentation there explains + the security threat associated with enabling this as well as + mitigations at the firmware and platform level. + https://trustedfirmware-a.readthedocs.io/en/latest/threat_model/threat_mode… + + Additional documentation on kernel security risks are at + Documentation/staging/tee.rst. diff --git a/drivers/tee/optee/optee_msg.h b/drivers/tee/optee/optee_msg.h index 70e9cc2ee96b..e8840a82b983 100644 --- a/drivers/tee/optee/optee_msg.h +++ b/drivers/tee/optee/optee_msg.h @@ -241,11 +241,23 @@ struct optee_msg_arg { * 384fb3e0-e7f8-11e3-af63-0002a5d5c51b. * Represented in 4 32-bit words in OPTEE_MSG_UID_0, OPTEE_MSG_UID_1, * OPTEE_MSG_UID_2, OPTEE_MSG_UID_3. + * + * In the case where the OP-TEE image is loaded by the kernel, this will + * initially return an alternate UID to reflect that we are communicating with + * the TF-A image loading service at that time instead of OP-TEE. That UID is: + * a3fbeab1-1246-315d-c7c4-06b9c03cbea4. + * Represented in 4 32-bit words in OPTEE_MSG_IMAGE_LOAD_UID_0, + * OPTEE_MSG_IMAGE_LOAD_UID_1, OPTEE_MSG_IMAGE_LOAD_UID_2, + * OPTEE_MSG_IMAGE_LOAD_UID_3. */ #define OPTEE_MSG_UID_0 0x384fb3e0 #define OPTEE_MSG_UID_1 0xe7f811e3 #define OPTEE_MSG_UID_2 0xaf630002 #define OPTEE_MSG_UID_3 0xa5d5c51b +#define OPTEE_MSG_IMAGE_LOAD_UID_0 0xa3fbeab1 +#define OPTEE_MSG_IMAGE_LOAD_UID_1 0x1246315d +#define OPTEE_MSG_IMAGE_LOAD_UID_2 0xc7c406b9 +#define OPTEE_MSG_IMAGE_LOAD_UID_3 0xc03cbea4 #define OPTEE_MSG_FUNCID_CALLS_UID 0xFF01 /* diff --git a/drivers/tee/optee/optee_smc.h b/drivers/tee/optee/optee_smc.h index 73b5e7760d10..7d9fa426505b 100644 --- a/drivers/tee/optee/optee_smc.h +++ b/drivers/tee/optee/optee_smc.h @@ -104,6 +104,30 @@ struct optee_smc_call_get_os_revision_result { unsigned long reserved1; }; +/* + * Load Trusted OS from optee/tee.bin in the Linux firmware. + * + * WARNING: Use this cautiously as it could lead to insecure loading of the + * Trusted OS. + * This SMC instructs EL3 to load a binary and execute it as the Trusted OS. + * + * Call register usage: + * a0 SMC Function ID, OPTEE_SMC_CALL_LOAD_IMAGE + * a1 Upper 32bit of a 64bit size for the payload + * a2 Lower 32bit of a 64bit size for the payload + * a3 Upper 32bit of the physical address for the payload + * a4 Lower 32bit of the physical address for the payload + * + * The payload is in the OP-TEE image format. + * + * Returns result in a0, 0 on success and an error code otherwise. + */ +#define OPTEE_SMC_FUNCID_LOAD_IMAGE 2 +#define OPTEE_SMC_CALL_LOAD_IMAGE \ + ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, ARM_SMCCC_SMC_32, \ + ARM_SMCCC_OWNER_TRUSTED_OS_END, \ + OPTEE_SMC_FUNCID_LOAD_IMAGE) + /* * Call with struct optee_msg_arg as argument * diff --git a/drivers/tee/optee/smc_abi.c b/drivers/tee/optee/smc_abi.c index a1c1fa1a9c28..fcbcd0c0c3aa 100644 --- a/drivers/tee/optee/smc_abi.c +++ b/drivers/tee/optee/smc_abi.c @@ -7,10 +7,13 @@ #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt #include <linux/arm-smccc.h> +#include <linux/cpuhotplug.h> #include <linux/errno.h> +#include <linux/firmware.h> #include <linux/interrupt.h> #include <linux/io.h> #include <linux/irqdomain.h> +#include <linux/kernel.h> #include <linux/mm.h> #include <linux/module.h> #include <linux/of.h> @@ -1149,6 +1152,22 @@ static bool optee_msg_api_uid_is_optee_api(optee_invoke_fn *invoke_fn) return false; } +#ifdef CONFIG_OPTEE_INSECURE_LOAD_IMAGE +static bool optee_msg_api_uid_is_optee_image_load(optee_invoke_fn *invoke_fn) +{ + struct arm_smccc_res res; + + invoke_fn(OPTEE_SMC_CALLS_UID, 0, 0, 0, 0, 0, 0, 0, &res); + + if (res.a0 == OPTEE_MSG_IMAGE_LOAD_UID_0 && + res.a1 == OPTEE_MSG_IMAGE_LOAD_UID_1 && + res.a2 == OPTEE_MSG_IMAGE_LOAD_UID_2 && + res.a3 == OPTEE_MSG_IMAGE_LOAD_UID_3) + return true; + return false; +} +#endif + static void optee_msg_get_os_revision(optee_invoke_fn *invoke_fn) { union { @@ -1354,6 +1373,117 @@ static void optee_shutdown(struct platform_device *pdev) optee_disable_shm_cache(optee); } +#ifdef CONFIG_OPTEE_INSECURE_LOAD_IMAGE + +#define OPTEE_FW_IMAGE "optee/tee.bin" + +static optee_invoke_fn *cpuhp_invoke_fn; + +static int optee_cpuhp_probe(unsigned int cpu) +{ + /* + * Invoking a call on a CPU will cause OP-TEE to perform the required + * setup for that CPU. Just invoke the call to get the UID since that + * has no side effects. + */ + if (optee_msg_api_uid_is_optee_api(cpuhp_invoke_fn)) + return 0; + else + return -EINVAL; +} + +static int optee_load_fw(struct platform_device *pdev, + optee_invoke_fn *invoke_fn) +{ + const struct firmware *fw = NULL; + struct arm_smccc_res res; + phys_addr_t data_pa; + u8 *data_buf = NULL; + u64 data_size; + u32 data_pa_high, data_pa_low; + u32 data_size_high, data_size_low; + int rc; + int hp_state; + + if (!optee_msg_api_uid_is_optee_image_load(invoke_fn)) + return 0; + + rc = request_firmware(&fw, OPTEE_FW_IMAGE, &pdev->dev); + if (rc) { + /* + * The firmware in the rootfs will not be accessible until we + * are in the SYSTEM_RUNNING state, so return EPROBE_DEFER until + * that point. + */ + if (system_state < SYSTEM_RUNNING) + return -EPROBE_DEFER; + goto fw_err; + } + + data_size = fw->size; + /* + * This uses the GFP_DMA flag to ensure we are allocated memory in the + * 32-bit space since TF-A cannot map memory beyond the 32-bit boundary. + */ + data_buf = kmalloc(fw->size, GFP_KERNEL | GFP_DMA); + if (!data_buf) { + rc = -ENOMEM; + goto fw_err; + } + memcpy(data_buf, fw->data, fw->size); + data_pa = virt_to_phys(data_buf); + reg_pair_from_64(&data_pa_high, &data_pa_low, data_pa); + reg_pair_from_64(&data_size_high, &data_size_low, data_size); + goto fw_load; + +fw_err: + pr_warn("image loading failed\n"); + data_pa_high = data_pa_low = data_size_high = data_size_low = 0; + +fw_load: + /* + * Always invoke the SMC, even if loading the image fails, to indicate + * to EL3 that we have passed the point where it should allow invoking + * this SMC. + */ + pr_warn("OP-TEE image loaded from kernel, this can be insecure"); + invoke_fn(OPTEE_SMC_CALL_LOAD_IMAGE, data_size_high, data_size_low, + data_pa_high, data_pa_low, 0, 0, 0, &res); + if (!rc) + rc = res.a0; + if (fw) + release_firmware(fw); + kfree(data_buf); + + if (!rc) { + /* + * We need to initialize OP-TEE on all other running cores as + * well. Any cores that aren't running yet will get initialized + * when they are brought up by the power management functions in + * TF-A which are registered by the OP-TEE SPD. Due to that we + * can un-register the callback right after registering it. + */ + cpuhp_invoke_fn = invoke_fn; + hp_state = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "optee:probe", + optee_cpuhp_probe, NULL); + if (hp_state < 0) { + pr_warn("Failed with CPU hotplug setup for OP-TEE"); + return -EINVAL; + } + cpuhp_remove_state(hp_state); + cpuhp_invoke_fn = NULL; + } + + return rc; +} +#else +static inline int optee_load_fw(struct platform_device *pdev, + optee_invoke_fn *invoke_fn) +{ + return 0; +} +#endif + static int optee_probe(struct platform_device *pdev) { optee_invoke_fn *invoke_fn; @@ -1372,6 +1502,10 @@ static int optee_probe(struct platform_device *pdev) if (IS_ERR(invoke_fn)) return PTR_ERR(invoke_fn); + rc = optee_load_fw(pdev, invoke_fn); + if (rc) + return rc; + if (!optee_msg_api_uid_is_optee_api(invoke_fn)) { pr_warn("api uid mismatch\n"); return -EINVAL; -- 2.40.0.rc1.284.g88254d51c5-goog

3 years, 3 months

2
1
0 0

[PATCH v6] tee: optee: Add SMC for loading OP-TEE image

by Jeffrey Kardatzke

Adds an SMC call that will pass an OP-TEE binary image to EL3 and instruct it to load it as the BL32 payload. This works in conjunction with a feature added to Trusted Firmware for ARMv8 and above architectures that supports this. The main purpose of this change is to facilitate updating the OP-TEE component on devices via a rootfs change rather than having to do a firmware update. Further details are linked to in the Kconfig file. Signed-off-by: Jeffrey Kardatzke <jkardatzke(a)chromium.org> Signed-off-by: Jeffrey Kardatzke <jkardatzke(a)google.com> --- Changes in v6: - Expanded Kconfig documentation Changes in v5: - Renamed config option - Added runtime warning when config is used Changes in v4: - Update commit message - Added more documentation - Renamed config option, added ARM64 dependency Changes in v3: - Removed state tracking for driver reload - Check UID of service to verify it needs image load Changes in v2: - Fixed compile issue when feature is disabled - Addressed minor comments - Added state tracking for driver reload drivers/tee/optee/Kconfig | 29 +++++++++++ drivers/tee/optee/optee_msg.h | 12 +++++ drivers/tee/optee/optee_smc.h | 24 +++++++++ drivers/tee/optee/smc_abi.c | 97 +++++++++++++++++++++++++++++++++++ 4 files changed, 162 insertions(+) diff --git a/drivers/tee/optee/Kconfig b/drivers/tee/optee/Kconfig index f121c224e682..8d4836c58486 100644 --- a/drivers/tee/optee/Kconfig +++ b/drivers/tee/optee/Kconfig @@ -7,3 +7,32 @@ config OPTEE help This implements the OP-TEE Trusted Execution Environment (TEE) driver. + +config OPTEE_INSECURE_LOAD_IMAGE + bool "Load OP-TEE image as firmware" + default n + depends on OPTEE && ARM64 + help + This loads the BL32 image for OP-TEE as firmware when the driver is + probed. This returns -EPROBE_DEFER until the firmware is loadable from + the filesystem which is determined by checking the system_state until + it is in SYSTEM_RUNNING. This also requires enabling the corresponding + option in Trusted Firmware for Arm. The documentation there explains + the security threat associated with enabling this as well as + mitigations at the firmware and platform level. + https://trustedfirmware-a.readthedocs.io/en/latest/threat_model/threat_mode… + + When utilizing this option, the following mitigations should be + implemented to prevent attacks at the kernel level. + 1. There must be boot chain security that verifies the kernel and + rootfs, otherwise an attacker can modify the loaded OP-TEE binary. + 2. It is recommended to build it as an included driver rather than + a module to prevent exploits that may cause the module to not be + loaded. + 3. If there are alternate methods of booting the device, such as a + recovery mode, it should be ensured that the same mitigations are + applied in that mode. + 4. The OP-TEE driver must be loaded before any potential attack + vectors are opened up. This should include mounting of any + modifiable filesystems, opening of network ports or communicating + with external devices (such a USB). diff --git a/drivers/tee/optee/optee_msg.h b/drivers/tee/optee/optee_msg.h index 70e9cc2ee96b..e8840a82b983 100644 --- a/drivers/tee/optee/optee_msg.h +++ b/drivers/tee/optee/optee_msg.h @@ -241,11 +241,23 @@ struct optee_msg_arg { * 384fb3e0-e7f8-11e3-af63-0002a5d5c51b. * Represented in 4 32-bit words in OPTEE_MSG_UID_0, OPTEE_MSG_UID_1, * OPTEE_MSG_UID_2, OPTEE_MSG_UID_3. + * + * In the case where the OP-TEE image is loaded by the kernel, this will + * initially return an alternate UID to reflect that we are communicating with + * the TF-A image loading service at that time instead of OP-TEE. That UID is: + * a3fbeab1-1246-315d-c7c4-06b9c03cbea4. + * Represented in 4 32-bit words in OPTEE_MSG_IMAGE_LOAD_UID_0, + * OPTEE_MSG_IMAGE_LOAD_UID_1, OPTEE_MSG_IMAGE_LOAD_UID_2, + * OPTEE_MSG_IMAGE_LOAD_UID_3. */ #define OPTEE_MSG_UID_0 0x384fb3e0 #define OPTEE_MSG_UID_1 0xe7f811e3 #define OPTEE_MSG_UID_2 0xaf630002 #define OPTEE_MSG_UID_3 0xa5d5c51b +#define OPTEE_MSG_IMAGE_LOAD_UID_0 0xa3fbeab1 +#define OPTEE_MSG_IMAGE_LOAD_UID_1 0x1246315d +#define OPTEE_MSG_IMAGE_LOAD_UID_2 0xc7c406b9 +#define OPTEE_MSG_IMAGE_LOAD_UID_3 0xc03cbea4 #define OPTEE_MSG_FUNCID_CALLS_UID 0xFF01 /* diff --git a/drivers/tee/optee/optee_smc.h b/drivers/tee/optee/optee_smc.h index 73b5e7760d10..7d9fa426505b 100644 --- a/drivers/tee/optee/optee_smc.h +++ b/drivers/tee/optee/optee_smc.h @@ -104,6 +104,30 @@ struct optee_smc_call_get_os_revision_result { unsigned long reserved1; }; +/* + * Load Trusted OS from optee/tee.bin in the Linux firmware. + * + * WARNING: Use this cautiously as it could lead to insecure loading of the + * Trusted OS. + * This SMC instructs EL3 to load a binary and execute it as the Trusted OS. + * + * Call register usage: + * a0 SMC Function ID, OPTEE_SMC_CALL_LOAD_IMAGE + * a1 Upper 32bit of a 64bit size for the payload + * a2 Lower 32bit of a 64bit size for the payload + * a3 Upper 32bit of the physical address for the payload + * a4 Lower 32bit of the physical address for the payload + * + * The payload is in the OP-TEE image format. + * + * Returns result in a0, 0 on success and an error code otherwise. + */ +#define OPTEE_SMC_FUNCID_LOAD_IMAGE 2 +#define OPTEE_SMC_CALL_LOAD_IMAGE \ + ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, ARM_SMCCC_SMC_32, \ + ARM_SMCCC_OWNER_TRUSTED_OS_END, \ + OPTEE_SMC_FUNCID_LOAD_IMAGE) + /* * Call with struct optee_msg_arg as argument * diff --git a/drivers/tee/optee/smc_abi.c b/drivers/tee/optee/smc_abi.c index a1c1fa1a9c28..00b6b69b6f79 100644 --- a/drivers/tee/optee/smc_abi.c +++ b/drivers/tee/optee/smc_abi.c @@ -8,9 +8,11 @@ #include <linux/arm-smccc.h> #include <linux/errno.h> +#include <linux/firmware.h> #include <linux/interrupt.h> #include <linux/io.h> #include <linux/irqdomain.h> +#include <linux/kernel.h> #include <linux/mm.h> #include <linux/module.h> #include <linux/of.h> @@ -1149,6 +1151,22 @@ static bool optee_msg_api_uid_is_optee_api(optee_invoke_fn *invoke_fn) return false; } +#ifdef CONFIG_OPTEE_INSECURE_LOAD_IMAGE +static bool optee_msg_api_uid_is_optee_image_load(optee_invoke_fn *invoke_fn) +{ + struct arm_smccc_res res; + + invoke_fn(OPTEE_SMC_CALLS_UID, 0, 0, 0, 0, 0, 0, 0, &res); + + if (res.a0 == OPTEE_MSG_IMAGE_LOAD_UID_0 && + res.a1 == OPTEE_MSG_IMAGE_LOAD_UID_1 && + res.a2 == OPTEE_MSG_IMAGE_LOAD_UID_2 && + res.a3 == OPTEE_MSG_IMAGE_LOAD_UID_3) + return true; + return false; +} +#endif + static void optee_msg_get_os_revision(optee_invoke_fn *invoke_fn) { union { @@ -1354,6 +1372,81 @@ static void optee_shutdown(struct platform_device *pdev) optee_disable_shm_cache(optee); } +#ifdef CONFIG_OPTEE_INSECURE_LOAD_IMAGE + +#define OPTEE_FW_IMAGE "optee/tee.bin" + +static int optee_load_fw(struct platform_device *pdev, + optee_invoke_fn *invoke_fn) +{ + const struct firmware *fw = NULL; + struct arm_smccc_res res; + phys_addr_t data_pa; + u8 *data_buf = NULL; + u64 data_size; + u32 data_pa_high, data_pa_low; + u32 data_size_high, data_size_low; + int rc; + + if (!optee_msg_api_uid_is_optee_image_load(invoke_fn)) + return 0; + + rc = request_firmware(&fw, OPTEE_FW_IMAGE, &pdev->dev); + if (rc) { + /* + * The firmware in the rootfs will not be accessible until we + * are in the SYSTEM_RUNNING state, so return EPROBE_DEFER until + * that point. + */ + if (system_state < SYSTEM_RUNNING) + return -EPROBE_DEFER; + goto fw_err; + } + + data_size = fw->size; + /* + * This uses the GFP_DMA flag to ensure we are allocated memory in the + * 32-bit space since TF-A cannot map memory beyond the 32-bit boundary. + */ + data_buf = kmalloc(fw->size, GFP_KERNEL | GFP_DMA); + if (!data_buf) { + rc = -ENOMEM; + goto fw_err; + } + memcpy(data_buf, fw->data, fw->size); + data_pa = virt_to_phys(data_buf); + reg_pair_from_64(&data_pa_high, &data_pa_low, data_pa); + reg_pair_from_64(&data_size_high, &data_size_low, data_size); + goto fw_load; + +fw_err: + pr_warn("image loading failed\n"); + data_pa_high = data_pa_low = data_size_high = data_size_low = 0; + +fw_load: + /* + * Always invoke the SMC, even if loading the image fails, to indicate + * to EL3 that we have passed the point where it should allow invoking + * this SMC. + */ + pr_warn("OP-TEE image loaded from kernel, this can be insecure"); + invoke_fn(OPTEE_SMC_CALL_LOAD_IMAGE, data_size_high, data_size_low, + data_pa_high, data_pa_low, 0, 0, 0, &res); + if (!rc) + rc = res.a0; + if (fw) + release_firmware(fw); + kfree(data_buf); + + return rc; +} +#else +static inline int optee_load_fw(struct platform_device *__unused1, + optee_invoke_fn *__unused2) { + return 0; +} +#endif + static int optee_probe(struct platform_device *pdev) { optee_invoke_fn *invoke_fn; @@ -1372,6 +1465,10 @@ static int optee_probe(struct platform_device *pdev) if (IS_ERR(invoke_fn)) return PTR_ERR(invoke_fn); + rc = optee_load_fw(pdev, invoke_fn); + if (rc) + return rc; + if (!optee_msg_api_uid_is_optee_api(invoke_fn)) { pr_warn("api uid mismatch\n"); return -EINVAL; -- 2.40.0.rc1.284.g88254d51c5-goog

3 years, 3 months

2
5
0 0

[PATCH] tee: optee: Fix typo Unuspported -> Unsupported

by Jules Maselbas

Fix typo Unuspported -> Unsupported Signed-off-by: Jules Maselbas <jmaselbas(a)kalray.eu> --- drivers/tee/optee/call.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tee/optee/call.c b/drivers/tee/optee/call.c index 290b1bb0e9cd..df5fb5410b72 100644 --- a/drivers/tee/optee/call.c +++ b/drivers/tee/optee/call.c @@ -488,7 +488,7 @@ static bool is_normal_memory(pgprot_t p) #elif defined(CONFIG_ARM64) return (pgprot_val(p) & PTE_ATTRINDX_MASK) == PTE_ATTRINDX(MT_NORMAL); #else -#error "Unuspported architecture" +#error "Unsupported architecture" #endif } -- 2.17.1

3 years, 3 months

3
2
0 0

[GIT PULL] Fix spell error in OP-TEE driver for v6.3

by Jens Wiklander

Hello arm-soc maintainers, Please pull this small patch fixing a spell error in an error message in the OP-TEE driver. Thanks, Jens The following changes since commit eeac8ede17557680855031c6f305ece2378af326: Linux 6.3-rc2 (2023-03-12 16:36:44 -0700) are available in the Git repository at: https://git.linaro.org/people/jens.wiklander/linux-tee.git/ tags/optee-fix-for-v6.3 for you to fetch changes up to 172fa6366c0c84eda31f1bc34e6c3e4698786215: tee: optee: Fix typo Unuspported -> Unsupported (2023-03-14 11:57:03 +0100) ---------------------------------------------------------------- Fixes a spell error in an error message in the OP-TEE driver ---------------------------------------------------------------- Jules Maselbas (1): tee: optee: Fix typo Unuspported -> Unsupported drivers/tee/optee/call.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

3 years, 3 months

1
0
0 0

[PATCH v7] tee: optee: Add SMC for loading OP-TEE image

by Jeffrey Kardatzke

Adds an SMC call that will pass an OP-TEE binary image to EL3 and instruct it to load it as the BL32 payload. This works in conjunction with a feature added to Trusted Firmware for ARMv8 and above architectures that supports this. The main purpose of this change is to facilitate updating the OP-TEE component on devices via a rootfs change rather than having to do a firmware update. Further details are linked to in the Kconfig file. Signed-off-by: Jeffrey Kardatzke <jkardatzke(a)chromium.org> Signed-off-by: Jeffrey Kardatzke <jkardatzke(a)google.com> --- Changes in v7: - Added documentation to Documentation/staging/tee.rst Changes in v6: - Expanded Kconfig documentation Changes in v5: - Renamed config option - Added runtime warning when config is used Changes in v4: - Update commit message - Added more documentation - Renamed config option, added ARM64 dependency Changes in v3: - Removed state tracking for driver reload - Check UID of service to verify it needs image load Changes in v2: - Fixed compile issue when feature is disabled - Addressed minor comments - Added state tracking for driver reload Documentation/staging/tee.rst | 41 +++++++++++++++ drivers/tee/optee/Kconfig | 17 ++++++ drivers/tee/optee/optee_msg.h | 12 +++++ drivers/tee/optee/optee_smc.h | 24 +++++++++ drivers/tee/optee/smc_abi.c | 97 +++++++++++++++++++++++++++++++++++ 5 files changed, 191 insertions(+) diff --git a/Documentation/staging/tee.rst b/Documentation/staging/tee.rst index 498343c7ab08..315aa8e35e6b 100644 --- a/Documentation/staging/tee.rst +++ b/Documentation/staging/tee.rst @@ -214,6 +214,47 @@ call is done from the thread assisting the interrupt handler. This is a building block for OP-TEE OS in secure world to implement the top half and bottom half style of device drivers. +OPTEE_INSECURE_LOAD_IMAGE Kconfig option +---------------------------------------- + +The OPTEE_INSECURE_LOAD_IMAGE Kconfig option enables the ability to load the +BL32 OP-TEE image from the kernel after the kernel boots, rather than loading +it from the firmware before the kernel boots. This also requires enabling the +corresponding option in Trusted Firmware for Arm. The documentation there +explains the security threat associated with enabling this as well as +mitigations at the firmware and platform level. +https://trustedfirmware-a.readthedocs.io/en/latest/threat_model/threat_model.html + +There are additional attack vectors/mitigations for the kernel that should be +addressed when using this option. + +1. Boot chain security. + Attack vector: Replace the OP-TEE OS image in the rootfs to gain control of + the system. + Migitation: There must be boot chain security that verifies the kernel and + rootfs, otherwise an attacker can modify the loaded OP-TEE + binary by modifying it in the rootfs. +3. Alternate boot modes. + Attack vector: Using an alternate boot mode (i.e. recovery mode), the OP-TEE + driver isn't loaded, leaving the SMC hole open. + Mitigation: If there are alternate methods of booting the device, such as a + recovery mode, it should be ensured that the same mitigations are + applied in that mode. +3. Attacks prior to SMC invocation. + Attack vector: Code that is executed prior to issuing the SMC call to load + OP-TEE can be exploited to then load an alternate OS image. + Mitigation: The OP-TEE driver must be loaded before any potential attack + vectors are opened up. This should include mounting of any + modifiable filesystems, opening of network ports or communicating + with external devices (e.g. USB). +4. Blocking SMC call to load OP-TEE. + Attack vector: Prevent the driver from being probed, so the SMC call to load + OP-TEE isn't executed when desired, leaving it open to being + executed later and loading a modified OS. + Mitigation: It is recommended to build the OP-TEE driver as an included + driver rather than a module to prevent exploits that may cause + the module to not be loaded. + AMD-TEE driver ============== diff --git a/drivers/tee/optee/Kconfig b/drivers/tee/optee/Kconfig index f121c224e682..70898bbd5809 100644 --- a/drivers/tee/optee/Kconfig +++ b/drivers/tee/optee/Kconfig @@ -7,3 +7,20 @@ config OPTEE help This implements the OP-TEE Trusted Execution Environment (TEE) driver. + +config OPTEE_INSECURE_LOAD_IMAGE + bool "Load OP-TEE image as firmware" + default n + depends on OPTEE && ARM64 + help + This loads the BL32 image for OP-TEE as firmware when the driver is + probed. This returns -EPROBE_DEFER until the firmware is loadable from + the filesystem which is determined by checking the system_state until + it is in SYSTEM_RUNNING. This also requires enabling the corresponding + option in Trusted Firmware for Arm. The documentation there explains + the security threat associated with enabling this as well as + mitigations at the firmware and platform level. + https://trustedfirmware-a.readthedocs.io/en/latest/threat_model/threat_mode… + + Additional documentation on kernel security risks are at + Documentation/staging/tee.rst. diff --git a/drivers/tee/optee/optee_msg.h b/drivers/tee/optee/optee_msg.h index 70e9cc2ee96b..e8840a82b983 100644 --- a/drivers/tee/optee/optee_msg.h +++ b/drivers/tee/optee/optee_msg.h @@ -241,11 +241,23 @@ struct optee_msg_arg { * 384fb3e0-e7f8-11e3-af63-0002a5d5c51b. * Represented in 4 32-bit words in OPTEE_MSG_UID_0, OPTEE_MSG_UID_1, * OPTEE_MSG_UID_2, OPTEE_MSG_UID_3. + * + * In the case where the OP-TEE image is loaded by the kernel, this will + * initially return an alternate UID to reflect that we are communicating with + * the TF-A image loading service at that time instead of OP-TEE. That UID is: + * a3fbeab1-1246-315d-c7c4-06b9c03cbea4. + * Represented in 4 32-bit words in OPTEE_MSG_IMAGE_LOAD_UID_0, + * OPTEE_MSG_IMAGE_LOAD_UID_1, OPTEE_MSG_IMAGE_LOAD_UID_2, + * OPTEE_MSG_IMAGE_LOAD_UID_3. */ #define OPTEE_MSG_UID_0 0x384fb3e0 #define OPTEE_MSG_UID_1 0xe7f811e3 #define OPTEE_MSG_UID_2 0xaf630002 #define OPTEE_MSG_UID_3 0xa5d5c51b +#define OPTEE_MSG_IMAGE_LOAD_UID_0 0xa3fbeab1 +#define OPTEE_MSG_IMAGE_LOAD_UID_1 0x1246315d +#define OPTEE_MSG_IMAGE_LOAD_UID_2 0xc7c406b9 +#define OPTEE_MSG_IMAGE_LOAD_UID_3 0xc03cbea4 #define OPTEE_MSG_FUNCID_CALLS_UID 0xFF01 /* diff --git a/drivers/tee/optee/optee_smc.h b/drivers/tee/optee/optee_smc.h index 73b5e7760d10..7d9fa426505b 100644 --- a/drivers/tee/optee/optee_smc.h +++ b/drivers/tee/optee/optee_smc.h @@ -104,6 +104,30 @@ struct optee_smc_call_get_os_revision_result { unsigned long reserved1; }; +/* + * Load Trusted OS from optee/tee.bin in the Linux firmware. + * + * WARNING: Use this cautiously as it could lead to insecure loading of the + * Trusted OS. + * This SMC instructs EL3 to load a binary and execute it as the Trusted OS. + * + * Call register usage: + * a0 SMC Function ID, OPTEE_SMC_CALL_LOAD_IMAGE + * a1 Upper 32bit of a 64bit size for the payload + * a2 Lower 32bit of a 64bit size for the payload + * a3 Upper 32bit of the physical address for the payload + * a4 Lower 32bit of the physical address for the payload + * + * The payload is in the OP-TEE image format. + * + * Returns result in a0, 0 on success and an error code otherwise. + */ +#define OPTEE_SMC_FUNCID_LOAD_IMAGE 2 +#define OPTEE_SMC_CALL_LOAD_IMAGE \ + ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, ARM_SMCCC_SMC_32, \ + ARM_SMCCC_OWNER_TRUSTED_OS_END, \ + OPTEE_SMC_FUNCID_LOAD_IMAGE) + /* * Call with struct optee_msg_arg as argument * diff --git a/drivers/tee/optee/smc_abi.c b/drivers/tee/optee/smc_abi.c index a1c1fa1a9c28..00b6b69b6f79 100644 --- a/drivers/tee/optee/smc_abi.c +++ b/drivers/tee/optee/smc_abi.c @@ -8,9 +8,11 @@ #include <linux/arm-smccc.h> #include <linux/errno.h> +#include <linux/firmware.h> #include <linux/interrupt.h> #include <linux/io.h> #include <linux/irqdomain.h> +#include <linux/kernel.h> #include <linux/mm.h> #include <linux/module.h> #include <linux/of.h> @@ -1149,6 +1151,22 @@ static bool optee_msg_api_uid_is_optee_api(optee_invoke_fn *invoke_fn) return false; } +#ifdef CONFIG_OPTEE_INSECURE_LOAD_IMAGE +static bool optee_msg_api_uid_is_optee_image_load(optee_invoke_fn *invoke_fn) +{ + struct arm_smccc_res res; + + invoke_fn(OPTEE_SMC_CALLS_UID, 0, 0, 0, 0, 0, 0, 0, &res); + + if (res.a0 == OPTEE_MSG_IMAGE_LOAD_UID_0 && + res.a1 == OPTEE_MSG_IMAGE_LOAD_UID_1 && + res.a2 == OPTEE_MSG_IMAGE_LOAD_UID_2 && + res.a3 == OPTEE_MSG_IMAGE_LOAD_UID_3) + return true; + return false; +} +#endif + static void optee_msg_get_os_revision(optee_invoke_fn *invoke_fn) { union { @@ -1354,6 +1372,81 @@ static void optee_shutdown(struct platform_device *pdev) optee_disable_shm_cache(optee); } +#ifdef CONFIG_OPTEE_INSECURE_LOAD_IMAGE + +#define OPTEE_FW_IMAGE "optee/tee.bin" + +static int optee_load_fw(struct platform_device *pdev, + optee_invoke_fn *invoke_fn) +{ + const struct firmware *fw = NULL; + struct arm_smccc_res res; + phys_addr_t data_pa; + u8 *data_buf = NULL; + u64 data_size; + u32 data_pa_high, data_pa_low; + u32 data_size_high, data_size_low; + int rc; + + if (!optee_msg_api_uid_is_optee_image_load(invoke_fn)) + return 0; + + rc = request_firmware(&fw, OPTEE_FW_IMAGE, &pdev->dev); + if (rc) { + /* + * The firmware in the rootfs will not be accessible until we + * are in the SYSTEM_RUNNING state, so return EPROBE_DEFER until + * that point. + */ + if (system_state < SYSTEM_RUNNING) + return -EPROBE_DEFER; + goto fw_err; + } + + data_size = fw->size; + /* + * This uses the GFP_DMA flag to ensure we are allocated memory in the + * 32-bit space since TF-A cannot map memory beyond the 32-bit boundary. + */ + data_buf = kmalloc(fw->size, GFP_KERNEL | GFP_DMA); + if (!data_buf) { + rc = -ENOMEM; + goto fw_err; + } + memcpy(data_buf, fw->data, fw->size); + data_pa = virt_to_phys(data_buf); + reg_pair_from_64(&data_pa_high, &data_pa_low, data_pa); + reg_pair_from_64(&data_size_high, &data_size_low, data_size); + goto fw_load; + +fw_err: + pr_warn("image loading failed\n"); + data_pa_high = data_pa_low = data_size_high = data_size_low = 0; + +fw_load: + /* + * Always invoke the SMC, even if loading the image fails, to indicate + * to EL3 that we have passed the point where it should allow invoking + * this SMC. + */ + pr_warn("OP-TEE image loaded from kernel, this can be insecure"); + invoke_fn(OPTEE_SMC_CALL_LOAD_IMAGE, data_size_high, data_size_low, + data_pa_high, data_pa_low, 0, 0, 0, &res); + if (!rc) + rc = res.a0; + if (fw) + release_firmware(fw); + kfree(data_buf); + + return rc; +} +#else +static inline int optee_load_fw(struct platform_device *__unused1, + optee_invoke_fn *__unused2) { + return 0; +} +#endif + static int optee_probe(struct platform_device *pdev) { optee_invoke_fn *invoke_fn; @@ -1372,6 +1465,10 @@ static int optee_probe(struct platform_device *pdev) if (IS_ERR(invoke_fn)) return PTR_ERR(invoke_fn); + rc = optee_load_fw(pdev, invoke_fn); + if (rc) + return rc; + if (!optee_msg_api_uid_is_optee_api(invoke_fn)) { pr_warn("api uid mismatch\n"); return -EINVAL; -- 2.40.0.rc1.284.g88254d51c5-goog

3 years, 3 months

2
2
0 0

2026

2025

2024

2023

2022

2021

2020

OP-TEE