[TF-M] Re: How does TF-M deal with the faults originated from NSPE

Hi Sandeep,

The worst it might cause is a DoS attack AFAIU.

That's correct. Quality of Service (QoS) is not a part of the scopes for TrustZone for Armv8-M. For applications that need to have guaranteed Quality of Service (QoS), system designers can opt for having two processors (in fact, there were already a range of multi-core Cortex-M microcontrollers on the market when Armv8-M was announced). On the other hand, many IoT applications are very cost sensitive, so TrustZone for Armv8-M is created to make it possible to have security solutions with minimal hardware cost.

Please also note that the typical software deployments on Cortex-M systems are also different from Cortex-A. In Cortex-A systems, it is common to download additional software components and execute during runtime. Whereas in Cortex-M, often the application(s) is stored in non-volatile memory and the software developers creating the applications create the whole images (or at least the Non-secure images). It is less common to download application software in Cortex-M and execute it. Given this nature, DoS of service from Non-secure world to Secure firmware is less likely. Of course, if the Non-secure software creator is the attacker, then this (DoS attack) would happen, but QoS is not relevant in this case.

Finally, most Cortex-A processors (excluding early Armv7-A processors) also support virtualization. As a result, QoS is an important in the architecture. The architecture for Cortex-M does not have this requirement.

I leave it to TF-M team to answer the question on dummy handlers :-)

Hope this helps. Regards, Joseph

-----Original Message----- From: Sandeep Tripathy via TF-M tf-m@lists.trustedfirmware.org Sent: Tuesday, March 21, 2023 6:05 PM To: tf-m@lists.trustedfirmware.org Subject: [TF-M] Re: How does TF-M deal with the faults originated from NSPE

Hi Anton,

...

The design of Armv8-M does not prevent a Non-secure software from crashing a system.

Thanks for confirming. Since this particular behavior is different from A-class cores with TZ ext I was trying to see if this aspect is covered in tfm threat model. The worst it might cause is a DoS attack AFAIU.

I see dummy handlers in tfm for the faults which does not seem to do anything at the moment. The easiest thing one would probably do is to assume the worst for any fault and react to it in SPE instead of trying to treat the NSSPE originated ones differently if at all its feasible to identify. Or will it be feasible to do something better in TFM?

Appreciate your thoughts on this.

Thanks Sandeep -- TF-M mailing list -- tf-m@lists.trustedfirmware.org To unsubscribe send an email to tf-m-leave@lists.trustedfirmware.org