Hi,
Just providing my own understandings. Please check blow.
Best Regards, Kevin
From: Romain JAYLES via TF-M tf-m@lists.trustedfirmware.org Sent: Friday, December 2, 2022 17:33 To: tf-m@lists.trustedfirmware.org Subject: [TF-M] TF-M and communication stack in NSPE
Hello,
We are currently integrating a protocol stack with a Radio IRQ in a TrustZone environment with the TF-M as the SPE. The Radio IRQ requires fast treatment from our protocol stack, the need is to have the Radio IRQ handled with the lowest latency possible.
The fact that all the IRQs in the NonSecure side can't preempt IRQ on the Secure side in the TF-M design leads us to the following possibilities with several limitations:
1. Having the Radio IRQ as the lowest priority on the NonSecure side: if a user creates its own partition with an IRQ (which by design will have a lower priority of our IRQ because it's in the Secure side), it could potentially delay for too long the Radio IRQ processing, thus leading to Radio protocol related issues. [Kevin] "which by design will have a lower priority of our IRQ because it's in the Secure side" - I think you meant "higher priority". That's true. This might be only solved by design to limit the usage of Secure interrupts.
1. Having the protocol stack related to the Radio IRQ in a partition directly in Secure side : this configuration is highly disputable from a Security point of view, the possibility to introduce a Security flaw with the protocol stack in Secure being too high. [Kevin] This depends on the on isolation level and the type of the Secure Partition you deploy. If you apply isolation level 3 for TF-M and ARoT type to the Secure Partition, then it's low possibility to introduce any Security flaws. That's because each ARoT Secure Partition is isolated with their own domains in isolation level 3 and the APIs for interacting with the framework is designed to be secure.
1. Having the Radio IRQ in a Secure partition (FLIH for faster handling) and forward the IRQ handling to the protocol stack in the NonSecure side, all modifications to the NVIC registers of this Radio IRQ (enable, disable, priority level) requested by the protocol stack in NonSecure side will have to be done through this partition with TF-M API calls (SFN backend for execution performances) : This configuration will probably led to issues such as reentrancy on the TF-M (for example if the TF-M forward an IRQ to the NonSecure which then calls TF-M API for Radio NVIC register manipulations) or having to call TF-M from NonSecure in handler mode. [Kevin] This sounds like a good solution. By "forward an IRQ to the NonSecure", are you referring to SPE callback to NSPE? Well, that is not supported in TF-M so you should apply some notification mechanism instead. Around the "call TF-M from NonSecure in handler mode", could you describe more?
Do you already have experienced with this type of problematics, or do you see TF-M configurations which will be more suitable for such a use-case ?
Thank you,
Regards,
Romain
ST Restricted