Hello Kevin,

Thank you for your detailed answer.

Here are my comments on each point:

1. Yes exactly, I was talking about a lower “NVIC priority numerical value” so yes “higher priority urgency”. The issue with this configuration is that the design limitation on Secure IRQ priority applied to not “perturbate” the Radio IRQ and the protocol stack will potentially limit a user wishing to write its own partition with its own IRQ. For example, if a user wants to add its own Secure Element or sensors triggering an IRQ to a Secure partition may not be feasible anymore without having the risk to delay too much the Radio IRQ handling.

2. I understand that having this Secure Partition as an ARoT type and isolation level 3 should be enough to mitigate a Security flaw in case of exploitation of a vulnerability in this Secure partition. But having a huge protocol stack which has not been written necessary with a focus on security wouldn’t break the concept induced by the TrustZone and the idea of NonSecure/Secure code separation with Secure code being as little as possible ?

3. Yes by “forward an IRQ to the NonSecure” I was meaning “SPE callback to NSPE”. For now, this forward is done by retrieving the NonSecure Radio IRQ Handler from the VTOR_NS, declaring it as a “cmse_nonsecure_call” and calling it from the Secure IRQ handler. I understand that if done that way with an IRQ with a high priority urgency, if a Security vulnerability is exploited in the NonSecure IRQ handler, it could cause a Denial of Service.

When you mention the use of “notification mechanism”, there is no such thing already developed in the TF-M for now ? The issue I see with this type of mechanism is that if the notification relies on the TF-M scheduler, it could potentially introduce too much delay in the interrupt treatment to be compliant with the protocol requirements (depending on the core frequency).

For the “call TF-M from NonSecure in handler mode”, I was meaning that in SFN mode, it is impossible to call TF-M API when the NSPE is in handler mode (referring to the psa_interface_sfn.c and the multiples checks of __get_active_exc_num() != EXC_NUM_THREAD_MODE). Which will be problematic if the NSPE wants to modify the Radio IRQ propriety (enable/disable/priority) while in handler mode, as it will be necessary to call our TF-M Secure Partition to modify the Radio IRQ propriety.

Thank you,

Best Regards,

Romain

ST Restricted

From: Kevin Peng <Kevin.Peng@arm.com>
Sent: Monday, December 5, 2022 4:06 AM
To: Romain JAYLES <romain.jayles@st.com>; tf-m@lists.trustedfirmware.org
Subject: RE: TF-M and communication stack in NSPE

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.

2. 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.

3. 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