Hi Francois,
On Wed, 15 May 2024 at 16:16, ff ff@shokubai.tech wrote:
Le 15 mai 2024 à 14:42, Kamlesh Gurudasani via TF-A tf-a@lists.trustedfirmware.org a écrit :
Hi Achin,
Thanks for the suggestion,
Instead of adding the complexity of yielding semantics to BL31, have you considered migrating the SCMI operations to a S-EL0 partition that is managed by EL3 firmware? This would be a preemptible bare-metal partition and does not require migrating the SCMI operations to a TEE.
As per [0], we can't have a SEL1 firmware at all(e.g. OP-TEE), if we run S-EL0 partition image.
"It is not currently possible for BL31 to integrate SPM support and a Secure Payload Dispatcher (SPD) at the same time; they are mutually exclusive.
It has been possible to run a TEE and UEFI crypto as a separate partition for UEFI SecureBoot with U-Boot. Adding a second partition may be complex but not impossible.
Thanks for cc'ing me and apologies for the late reply, I was travelling.
I added Ilias in the to: as he knows alls the details
It's technically possible, but we run StMM completely isolated from other TAs in the secure world. But we did this a few years ago when FF-A was just starting nad there was no code in u-boot. TF-A, EDK2 etc. FF-A is more mature nowadays so I'd rather use that and Trusted Services instead of adding another path in OP-TEE
Cheers /Ilias
In the SPM bootflow, a Secure Partition image executing at S-EL0 replaces the Secure Payload image executing at S-EL1 (e.g. a Trusted OS). Both are referred to as BL32."
Let me know if you think otherwise.
What we want is,
- Run clock and power management services as well as TEE services
- We don't want to put clock and power and management services in TEE,
so that we have liberty to use any TEE we want. Example, if we put our SCMI operations in OP-TEE, then we'll be constrained to use OP-TEE and only OP-TEE.
[0]https://trustedfirmware-a.readthedocs.io/en/latest/components/secure-partiti...
Regards, Kamlesh
Achin Gupta Achin.Gupta@arm.com writes:
Hi Kamlesh,
We are aware that ARM v8.4-A onwards arch are having a SEL2 level with which we can run a vendor specific firmware
parallel to TEE at SEL1 in a secure partition. But how we do handle clock and power management for version which doesn't support SEL2?
Instead of adding the complexity of yielding semantics to BL31, have you considered migrating the SCMI operations to a S-EL0 partition that is managed by EL3 firmware? This would be a preemptible bare-metal partition and does not require migrating the SCMI operations to a TEE.
cheers, Achin
From: Kamlesh Gurudasani via TF-A tf-a@lists.trustedfirmware.org Sent: 15 May 2024 10:33 To: tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org Cc: bb@ti.com bb@ti.com; vigneshr@ti.com vigneshr@ti.com; d-gole@ti.com d-gole@ti.com; afd@ti.com afd@ti.com; hnagalla@ti.com hnagalla@ti.com Subject: [TF-A] Make TF-A (bl31) (El3 firmware) preemtible
Clock and power management in ATF, preemption issue.
I have seen that multiple Vendors are using arm scmi protocol to do clock management in bl31[0][1].
The problem with such implementations is any long running SCMI operations (like PLL locking for example) will hold the core in EL3 for extended period of time, adding to latency of NS EL1 interrupt handling as ATF is not preemptible.
This problem can be solved by making ATF preemptible, similar to how OP-TEE does it by by implementing a remote procedural call after it receives a interrupt. [2]How Linux does SMC call with YIELD flag enabled. [3]How OP-TEE handles the timer interrupt [4]How Linux receives an interrupt which came in EL3->SEL1
As quoted in exception Handling document in ATF docs[5]
"Receive exceptions, but handle part of the exception in EL3, and delegate processing of the error to dedicated software stack running at lower secure ELs (as above); additionally, the Normal world may also be required to participate in the handling, or be notified of such events (for example, as an event). In this scheme, exception handling potentially and maximally spans all ELs in both Secure and Normal worlds."
From this we can understand that we can delegate the exception to EL1 if we are already in EL3. (way to preempt)
We are aware that ARM v8.4-A onwards arch are having a SEL2 level with which we can run a vendor specific firmware parallel to TEE at SEL1 in a secure partition. But how we do handle clock and power management for version which doesn't support SEL2?
We don't want to put it in TEE as it will constraint our devices to that specific TEE.
I am starting to work on a proposal to make ATF preemptible similar to how OP-TEE is doing it. a)Will the similar approach from OP-TEE if implemented and working be accepted by ATF upstream? The SMC call with YIELD option will only be preemtible so will not affect the normal flow.
b)As quoted in Trusted Firmware-A Document[6] Page 94, "Yielding calls are reserved exclusively for Trusted OS providers" "Yielding 0- 1 Reserved for existing Armv7-A calls Yielding 2-63 Trusted OS Standard Calls"
Can this range be consumed within ATF/bl31 firmware or is it necessary to forward all yielding calls to Trusted OS?
[0]https://github.com/ARM-software/arm-trusted-firmware/blob/master/plat/st/stm... [1]https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/21840 [2]https://elixir.bootlin.com/linux/v6.9-rc3/source/drivers/tee/optee/smc_abi.c... [3]https://github.com/OP-TEE/optee_os/blob/fc57019cb35c8c1bad66fc6d814ace5debde... [4]https://elixir.bootlin.com/linux/v6.9-rc3/source/drivers/tee/optee/smc_abi.c... [5]https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/compon... [6]https://trustedfirmware-a.readthedocs.io/_/downloads/en/latest/pdf/
Regards, Kamlesh -- TF-A mailing list -- tf-a@lists.trustedfirmware.org To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.org
-- TF-A mailing list -- tf-a@lists.trustedfirmware.org To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.org