Hi, Olivier, The question in the last email may be a little confusing. I want to change the question, do you know how implement that hafnium boot optee at runtime? I think there should be less initialization than the first boot. Thanks a lot for the support. Regards, Yuye. ------------------------------------------------------------------ 发件人：梅建强(禹夜) meijianqiang.mjq@alibaba-inc.com 发送时间：2023年4月23日(星期日) 16:36 收件人：Olivier Deprez Olivier.Deprez@arm.com 抄 送：hafnium hafnium@lists.trustedfirmware.org 主 题：hyp_loaded Hi, Olivier, I would like to ask you about the solution to the optee hot update. In the current scenario, we have updated the optee core image after REE OS is booted. And we want to re-initialize hafnium and optee in the boot flow. So we re-execute the function spmd_init() in the ATF and enter into hafnium succesfully. However, we find that function plat_psci_cpu_resume() has some problems with hafnium entering into optee. We add some debug near the following code. dlog("[Hafnium] cpu_index:%x, cpu->id:%x\n",cpu_index(c), c->id); vcpu = vm_get_vcpu(vm, (vm->vcpu_count == 1) ? 0 : cpu_index(c)); vcpu_locked = vcpu_lock(vcpu); Because the tee_driver that initiate a optee update request is running on a random cpu after REE OS is booted, cpu_id here is a random id, but cpu_index is still 0, like the print: [Hafnium] cpu_index:0, cpu->id:2d0000 which seems to affect optee booting and the system will hang before hafnium enter into optee. I am not familiar with the vcpu switching. Do you know how to solve this problem? Or should we directly select the secondary core boot way instead of the primary on the current physical cpu? Regards, Yuye. ------------------------------------------------------------------ 发件人：Olivier Deprez Olivier.Deprez@arm.com 发送时间：2023年2月3日(星期五) 18:10 收件人：梅建强(禹夜) meijianqiang.mjq@alibaba-inc.com 抄 送：hafnium hafnium@lists.trustedfirmware.org; raghu.ncstate raghu.ncstate@icloud.com; Achin Gupta Achin.Gupta@arm.com; Gyorgy Szing Gyorgy.Szing@arm.com 主 题：Re: hyp_loaded Hi Yuve, I believe we missed to reply to:
In addition, the OPTEE community seems to be discussing the issue of Post-boot loading OPTEE.
Does anyone know whether these two issues can be regarded as the same kind of issue? From my perspective, this is a fundamentally different approach to how OP-TEE is loaded and booted. And actually a quite orthogonal model of trust compared to usual TF-A deployments. This requires an enforcement of the bootloader and kernel to verify the filesystem contents hence this has additional assumptions about the system integration. So I believe this a different 'problem' addressed, if compared to the generic firmware update topic. Regards, Olivier. From: 梅建强(禹夜) meijianqiang.mjq@alibaba-inc.com Sent: 19 January 2023 18:30 To: Gyorgy Szing Gyorgy.Szing@arm.com; Achin Gupta Achin.Gupta@arm.com; raghu.ncstate raghu.ncstate@icloud.com; Olivier Deprez Olivier.Deprez@arm.com; hafnium hafnium@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: 回复：[Hafnium] 回复：回复：回复：回复：hyp_loaded Hi, George Since I have to go home for the Spring Festival, I have delayed two days for the reply to this issue.Sorry about that.
would it be possible for you to instead of extending HF with SP loading capability, implement a loader SP instead?
Yes, we have recognized that method of extanding HF is not only complex but also against the HF design principle. We have reanalysed the SP loading. Now we think that BL31 may be a good choice to replace the HF for loading the OPTEE at runtime phase. And it seems that we can benefit from some implementation of image loading in BL2 in TF-A. In addition, the OPTEE community seems to be discussing the issue of Post-boot loading OPTEE. Does anyone know whether these two issues can be regarded as the same kind of issue? Regards, Yuye ------------------------------------------------------------------ 发件人：Gyorgy Szing Gyorgy.Szing@arm.com 发送时间：2023年1月17日(星期二) 18:27 收件人：梅建强(禹夜) meijianqiang.mjq@alibaba-inc.com; Achin Gupta Achin.Gupta@arm.com; raghu.ncstate raghu.ncstate@icloud.com; Olivier Deprez Olivier.Deprez@arm.com; hafnium hafnium@lists.trustedfirmware.org 抄 送：nd nd@arm.com 主 题：RE: [Hafnium] 回复：回复：回复：回复：hyp_loaded Hi Yuye, would it be possible for you to instead of extending HF with SP loading capability, implement a loader SP instead? This SP would be loaded by BL2 instead of OP-TEE, and would be able to "replace itself" with the real payload of the SP later (in this case OP-TEE). For that it could either host a storage driver, if boot-time loading is needed, or if storage is only accessible from the SWd, or allow the NWd to send the payload if run-time loading is more beneficial. The main benefit of this approach would be to keep extra complexity out of HF, and to run the loader compartmentalized (least privilege principle). This might need some changes in HF, and will need a new treat model and threat mitigations. But I think the same is true if the loader is implemented in HF. Experts any thoughts? Would this be feasible? Would this be a good approach? /George -----Original Message----- From: 梅建强(禹夜) via Hafnium hafnium@lists.trustedfirmware.org Sent: 17 January 2023 02:42 To: Achin Gupta Achin.Gupta@arm.com; raghu.ncstate raghu.ncstate@icloud.com; Olivier Deprez Olivier.Deprez@arm.com; hafnium hafnium@lists.trustedfirmware.org Subject: [Hafnium] 回复：回复：回复：回复：hyp_loaded Hi,
If you are looking at changing the OP-TEE image at runtime then this is effectively a firmware update right?
Yes.
Are you planning to add this support to Hafnium too or will this be done on a separate controller?
Yes, we intend to use Hafnium to support it now. regards, yuye ------------------------------------------------------------------ 发件人：Achin Gupta Achin.Gupta@arm.com 发送时间：2023年1月17日(星期二) 05:18 收件人：raghu.ncstate raghu.ncstate@icloud.com; Olivier Deprez Olivier.Deprez@arm.com; hafnium hafnium@lists.trustedfirmware.org; 梅建强(禹夜) meijianqiang.mjq@alibaba-inc.com 主 题：Re: [Hafnium] 回复：回复：回复：hyp_loaded Hi Yuye, If you are looking at changing the OP-TEE image at runtime then this is effectively a firmware update right? Apart from storage drivers you would need some support for verifying or measuring the image as well. Are you planning to add this support to Hafnium too or will this be done on a separate controller? cheers, Achin From: 梅建强(禹夜) via Hafnium hafnium@lists.trustedfirmware.org Sent: 16 January 2023 17:50 To: raghu.ncstate raghu.ncstate@icloud.com; Olivier Deprez Olivier.Deprez@arm.com; hafnium hafnium@lists.trustedfirmware.org Subject: [Hafnium] 回复：回复：回复：hyp_loaded Hi, In our current boot flow, we have implemented TF-A BL2 to load OPTEE. However, at runtime, this static loading method is not convenient for updating OPTEE, considering that we may make some changes to OPTEE on demand. So we wanted to load OPTEE with a dynamic loading solution, and Hafnium would be a good runtime component, since TF-A BL2 is not a runtime component. Before I do that, I want to implement Hafnium's static loading of OPTEE. If you have any questions about the above ideas or other solutions to this query, glad to discuss with you. Thanks for support. regards, yuye ------------------------------------------------------------------ 发件人：raghu.ncstate raghu.ncstate@icloud.com 发送时间：2023年1月17日(星期二) 01:15 收件人：梅建强(禹夜) meijianqiang.mjq@alibaba-inc.com; Olivier Deprez Olivier.Deprez@arm.com; hafnium hafnium@lists.trustedfirmware.org 抄 送：赵哲(为哲) weizhe.zz@alibaba-inc.com 主 题：RE: [Hafnium] 回复：回复：hyp_loaded It would be good if consider using TF-A BL2 or equivalent to load OPTEE, that runs before hafnium, which is really the secure loader. I would recommend against hafnium including a loader, to keep it simple (and replicate the same functionality of another component), although that might be the right approach for your platform. -----Original Message----- From: 梅建强(禹夜) via Hafnium hafnium@lists.trustedfirmware.org Sent: Monday, January 16, 2023 8:37 AM To: Olivier Deprez Olivier.Deprez@arm.com; hafnium hafnium@lists.trustedfirmware.org Cc: 赵哲(为哲) weizhe.zz@alibaba-inc.com Subject: [Hafnium] 回复：回复：hyp_loaded Hi, expert It seems that if I want to implement the query, I need to implement storage drivers in hafnium by myself. Thanks for the confirmation. regards, yuye ------------------------------------------------------------------ 发件人：Olivier Deprez Olivier.Deprez@arm.com 发送时间：2023年1月17日(星期二) 00:30 收件人：hafnium hafnium@lists.trustedfirmware.org; 梅建强(禹夜) meijianqiang.mjq@alibaba-inc.com 抄 送：赵哲(为哲) weizhe.zz@alibaba-inc.com 主 题：Re: 回复：[Hafnium] hyp_loaded Hi, In the reference implementation, OP-TEE is loaded (from flash to DRAM) as a partition by a bootloader running before Hafnium is launched. The bootloader can be TF-A's BL2 or another solution. Hafnium cannot "load an image/partition to DRAM" as it doesn't implement storage drivers. Regards, Olivier. From: 梅建强(禹夜) meijianqiang.mjq@alibaba-inc.com Sent: 16 January 2023 17:25 To: Olivier Deprez Olivier.Deprez@arm.com; hafnium hafnium@lists.trustedfirmware.org Cc: 赵哲(为哲) weizhe.zz@alibaba-inc.com Subject: 回复：[Hafnium] hyp_loaded Hi, expert For my configuration, Hafnium is used as a SPMC running on S-EL2. Is there any problems if I use Hafnium to load an OP-TEE image in the boot flow? regards, yuye ------------------------------------------------------------------ 发件人：Olivier Deprez Olivier.Deprez@arm.com 发送时间：2023年1月17日(星期二) 00:15 收件人：hafnium hafnium@lists.trustedfirmware.org; 梅建强(禹夜) meijianqiang.mjq@alibaba-inc.com 抄 送：赵哲(为哲) weizhe.zz@alibaba-inc.com 主 题：Re: [Hafnium] hyp_loaded Hi, As I recall hyp_loaded option was introduced in context of Hafnium used as a NS EL2 hypervisor. Is this a configuration you use? This option is only related to normal world VMs. I don't believe it was designed for SPs or the SPMC image itself. One reason is that SEL2/SPMC starts before the NS EL2 hypervisor in the boot flow. For the record, the change that introduced this option: https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 > <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 > > < < >https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 > <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 > > > < < >https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 > <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 > > < < >https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 > <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 <https://review.trustedfirmware.org/c/hafnium/hafnium/+/10540 > > > > Regards, Olivier. From: 梅建强(禹夜) via Hafnium hafnium@lists.trustedfirmware.org Sent: 16 January 2023 13:54 To: Olivier Deprez Olivier.Deprez@arm.com; hafnium hafnium@lists.trustedfirmware.org Cc: 赵哲(为哲) weizhe.zz@alibaba-inc.com Subject: [Hafnium] hyp_loaded Hi, expert I want to confirm a problem about using hafnium to load spmc payload. That is, Dose hafnium supports hyp_loaded for spmc payload or ffa_partion (such as optee_os) in the boot phase? If the community confirms that it does not support it, I wonder, what might be the problem with doing so? I see the following code in hanfnium： if (manifest->vm[i].is_ffa_partition && !manifest->vm[i].is_hyp_loaded) { TRY(parse_ffa_partition_package(stage1_locked, &vm_node, &manifest->vm[i], vm_id, ppool)); } else { TRY(parse_vm(&vm_node, &manifest->vm[i], vm_id)); } It seems that hafnium has no handling for both is_ffa_partition and is_hyp_loaded. regards, yuye -- Hafnium mailing list -- hafnium@lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave@lists.trustedfirmware.org -- Hafnium mailing list -- hafnium@lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave@lists.trustedfirmware.org -- Hafnium mailing list -- hafnium@lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave@lists.trustedfirmware.org -- Hafnium mailing list -- hafnium@lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave@lists.trustedfirmware.org