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

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

1 year, 9 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.

1 year, 9 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.

1 year, 9 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

1 year, 9 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

1 year, 9 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

1 year, 9 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. >

1 year, 9 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.

1 year, 9 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

1 year, 9 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

1 year, 9 months

2
2
0 0

2024

2023

2022

2021

2020

OP-TEE March 2023