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 <https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/18635 > [2] https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.o... <https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.o... > [3] https://github.com/OP-TEE/optee_os/issues/5699 <https://github.com/OP-TEE/optee_os/issues/5699 > Thanks, Jens