Hi,

Thanks for the correction.

Ideally, if there is no secure interrupt usage the latency should be as minimal as possible which would be fine for NSPE applications. But it is really an issue if there are secure interrupt usages, depending on how fast the secure IRQ can process the interrupt. Hence we need to measure the latency to ensure it won’t affect those time-sensitive applications in NSPE. This is a necessary work that is important for MCUs does not have rich resources, and it is feasible as Microcontroller development is somewhat 'static' which means we are clear about the scenarios (such as how many components, threads, partitions with IRQs or not getting involved) - it is not like a generic application CPU which is hard to estimate the user scenarios.

Current TF-M should have reduced the NS IRQ latency much when SPE is running under isolation level 1. For higher levels, we are still figuring out the solution to reduce the latency. Feel free to report issues met and then we can take a closer look at it. Don’t forget to give detail configurations you are using (Could be found in build commands) and the expected goal.

Thanks and BR 😉

/Ken

From: Romain JAYLES <romain.jayles@st.com>
Sent: Tuesday, December 6, 2022 8:51 PM
To: Ken Liu <Ken.Liu@arm.com>; tf-m@lists.trustedfirmware.org
Cc: nd <nd@arm.com>
Subject: RE: TF-M and communication stack in NSPE

Hi Ken,

Thank you for your answer,

Ok for the explanation of why there are mode checking in Secure entrance, it makes sense.

Your assumption is not totally correct, sorry my explanations may have not been the clearest but the requirements on the Radio IRQ are not related to Security but rather on the latency of this IRQ handling by the protocol stack. We assume that everything related to this protocol stack could rely in NSPE.

The idea to put the Radio IRQ in a Secure partition arises because each Secure IRQ will have (by requirement of the TF-M) a higher priority than a NonSecure interrupt, thus someone writing a Secure Partition with an IRQ could preempt our Radio IRQ for a too long time (leading to a de-synchronization in the Radio protocol) if this Radio IRQ was on the NonSecure side.

If there was a way to let this Radio IRQ in NonSecure and, at the same time, being sure that no Secure IRQ will delay for too long the handling of this Radio IRQ, it could be a solution.

What you mentioned with "notifying the NSPE by triggering an NS software IRQ" and "'threaded' ISR" is a very interesting method to notify the NSPE and to call TFM API when in ISR routine. The drawback being the risk that the part of the processing now done in an NonSecure IRQ (so with a priority lower than any Secure IRQ) could be preempted by a Secure IRQ.

Thanks,

Best Regards,

Romain

From: Ken Liu via TF-M <tf-m@lists.trustedfirmware.org>
Sent: Tuesday, December 6, 2022 4:32 AM
To: tf-m@lists.trustedfirmware.org
Cc: nd <nd@arm.com>
Subject: [TF-M] Re: TF-M and communication stack in NSPE

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