Hi,

Noticed this interesting discussion and provide my inputs:

• TF-M the secure firmware provides a ‘library’ like service modeling, it is not a complete system that can schedule threads freely – especially Trustzone case – SPE relies on NSPE to pass the execution to handle a case to service the caller ‘thread’. For Secure ISR needed by Secure Partitions, it is required to be quick and it cannot process mass quantity data which would occupy the whole system for a while. TF-M service API is expected to be called under thread mode because a secure thread can be preempted by NS IRQ in case NSPE got an important IRQ to be dispatched. That's why the there is a mode checking in the secure entrance.
• We need to find out what needs to be protected exactly, and try to limit the scope as smaller as possible. This could help pick out the important part - the key, the data, or the code.

From the description I guess the received data needs to be decrypted by a secure key or interactive with secure data. If the decryption can be processed in a 'threaded' ISR, then it would be all fine as the decryption can be delegated to SPE by a generic secure call. If the decryption is expected in NS ISR, it would be tricky because call to the secure service is expected to be done in threads, and the decryption would also occupy the system for a longer time as secure handler (non-secure handler calls into) mode has the priority higher than any non-secure handler, which boosts the radio's ISR into highest when performing a secure call no spite of which priority it is set in the NVIC.

The 3rd point provides a method closer to a workable one but needs some tweaks – notifying the NSPE by triggering an NS software IRQ would be easier, then NSPE scheduling could let the NS thread retrieve the data by a secure service call – Caution that Secure ISR cannot share the decrypted data to NSPE directly! This creates another channel to expose data to NSPE, which is not following FF-M.

Please correct me if my assumption is wrong, then let’s discuss it from another angle 😉

Thanks.

/Ken

From: Romain JAYLES via TF-M <tf-m@lists.trustedfirmware.org>
Sent: Monday, December 5, 2022 7:01 PM
To: Kevin Peng <Kevin.Peng@arm.com>; tf-m@lists.trustedfirmware.org
Subject: [TF-M] Re: TF-M and communication stack in NSPE

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