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. 
(2) optee may use multiple cores. When and how to process the initialization of multiple cores?
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.org/thread/D2HEKDEGRBLMMLAQ6OKC3AQDM4ELSJPL/#D2HEKDEGRBLMMLAQ6OKC3AQDM4ELSJPL
[3] https://github.com/OP-TEE/optee_os/issues/5699

Thanks,
Jens