On Sun, Mar 12, 2023 at 1:14 AM 梅建强(禹夜) meijianqiang.mjq@alibaba-inc.com wrote:
Hi, experts,
I have another two other questions about this issue. (1) What should I do if the current optee to load already exists or I want to update optee? The most straightforward way I could think of is to reclaim the memory currently used by optee, then reload the optee image and initialize it.
I just reboot to handle this.
(2) optee may use multiple cores. When and how to process the initialization of multiple cores?
This is already handled in the TF-A code patch, when an SMC from the non-secure world comes in or a relevant power management event occurs, it checks to see if that CPU has been initialized yet, and if it hasn't it initializes it then.
Do you have any solutions or ideas?
Regards, Yuye.
发件人：梅建强(禹夜) meijianqiang.mjq@alibaba-inc.com 发送时间：2023年3月11日(星期六) 21:44 收件人：Jens Wiklander jens.wiklander@linaro.org; tf-a tf-a@lists.trustedfirmware.org; OP-TEE TrustedFirmware op-tee@lists.trustedfirmware.org 抄 送：Dan Handley Dan.Handley@arm.com; Jeffrey Kardatzke jkardatzke@google.com; jwerner jwerner@chromium.org; raghu.ncstate raghu.ncstate@icloud.com; Ilias Apalodimas ilias.apalodimas@linaro.org 主 题：Re: Post-boot loading of OP-TEE
Hi, experts,
If I want to apply the code to the S-EL2 framework (Hafnium as SPMC), What special processing should be added to spmd_handle_smc_load function or other function, such as context restore and save? I'm not clear about the details of the process, can you give me some help?
Regards, Yuye.
发件人：Jens Wiklander jens.wiklander@linaro.org 发送时间：2023年1月9日(星期一) 15:39 收件人：tf-a tf-a@lists.trustedfirmware.org; OP-TEE TrustedFirmware op-tee@lists.trustedfirmware.org 抄 送：Dan Handley Dan.Handley@arm.com; Jeffrey Kardatzke jkardatzke@google.com; jwerner jwerner@chromium.org; raghu.ncstate raghu.ncstate@icloud.com; Ilias Apalodimas ilias.apalodimas@linaro.org 主 题：Post-boot loading of OP-TEE
Hi,
The recent patch [1] for the OP-TEE Dispatcher in TF-A proposes a way of post-boot loading OP-TEE by the Linux kernel with signature verification in the normal world only. This has previously been discussed in this mail thread [2] about half a year ago. Ultimately, it was concluded that this should in principle be accepted upstream as a platform choice to allow this or not. There are concerns that what we have in upstream TF-A should serve as good examples, and trusting the normal world to verify secure world software might not meet that criterion. There are also concerns about adding signature verification to BL31
Leaving the secure world wide open until the Linux kernel has been able to successfully load and verify an OP-TEE binary seems very risky. Even if it's claimed that the normal world can be trusted at this point, we're still giving up a critical level of defense without a good reason.
I've started to review [1], but it should not be accepted for merging without support and approval from other maintainers.
I would like to explore other options in this mail thread. In [2] it was suggested that a remnant of bl2 could be kept to verify OP-TEE before starting to execute it. This could be taken one step further and load a limited OP-TEE at boot which later is updated live, almost like what's discussed in [3]. This should minimize the impact on TF-A and also leave OP-TEE in charge of accepting an update instead of a divided responsibility between the normal world and TF-A.
[1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/18635 [2] https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.o... [3] https://github.com/OP-TEE/optee_os/issues/5699
Thanks, Jens