[Hafnium] Boot arguments for S-EL1 with SPMC at S-EL2 - OP-TEE

27 Mar 2023


      Hi, Olivier,
Whether Boot Information Blob is a file similar to manifest.dtb or sp.pkg? 
How do I generate this blob? 
Does it need to be packaged into atf firmware at compile phase？
Thanks.
Regards,
Yuye.
------------------------------------------------------------------
发件人：Olivier Deprez Olivier.Deprez@arm.com
发送时间：2023年3月21日(星期二) 22:37
收件人：Jens Wiklander jens.wiklander@linaro.org
抄　送：hafnium@lists.trustedfirmware.org hafnium@lists.trustedfirmware.org; OP-TEE TrustedFirmware op-tee@lists.trustedfirmware.org
主　题：Re: [Hafnium] Boot arguments for S-EL1 with SPMC at S-EL2
Hi Jens,
See comments inline [OD].
Regards,
Olivier.
________________________________
From: Jens Wiklander via Hafnium hafnium@lists.trustedfirmware.org
Sent: 21 March 2023 09:30
To: Olivier Deprez Olivier.Deprez@arm.com
Cc: hafnium@lists.trustedfirmware.org hafnium@lists.trustedfirmware.org; OP-TEE TrustedFirmware op-tee@lists.trustedfirmware.org
Subject: [Hafnium] Boot arguments for S-EL1 with SPMC at S-EL2
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.
[OD] Fair enough, I believe that would conflate into some generic PIE support?
I can see how this helps with the multi OP-TEE instances use case, perhaps?
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?
[OD] The standard way would be to use the FF-A boot protocol e.g. if you add this to OP-TEE's SP manifest:
+ /* Boot protocol */
+ gp-register-num = <0x0>;
+
+ /* Boot Info */
+ boot-info {
+ compatible = "arm,ffa-manifest-boot-info";
+ ffa_manifest;
+ };
See https://trustedfirmware-a.readthedocs.io/en/latest/components/secure-partiti... <https://trustedfirmware-a.readthedocs.io/en/latest/components/secure-partiti... >
At SP entry, x0 contains the address of a 'Boot Information Blob' (FF-A v1.1 REL0 section 5.4.2) starting with a Boot Information Header (Table 5.9).
The SP manifest DT address can be extracted from a Boot Information Descriptor (Table 5.8).
Eventually the SP is able to parse its own SP manifest, into which it finds FF-A standard fields (load-address...) in addition to any impdef field added.
Note the partition size is not standarded (it should probably be), so for starters you can add your own memsize field.
There is some sample usage in TF-a-tests:
https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tree/spm/cactus/cactus_m... <https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tree/spm/cactus/cactus_m... >
and also in context of EDKII/StMM:
https://github.com/odeprez/edk2/commit/7066c913cb227056d68ea99de5e92f2067fe7... <https://github.com/odeprez/edk2/commit/7066c913cb227056d68ea99de5e92f2067fe7... >
Thanks,
Jens
--
Hafnium mailing list -- hafnium@lists.trustedfirmware.org
To unsubscribe send an email to hafnium-leave@lists.trustedfirmware.org