Hi tf-m experts, I have a fundamental query on v8m trustZone and containability of secure fault and other escalated HardFaults to SPE. With BFHFNMINA set to '0' IIUC that a malicious actor in NSPE can willingly cause fault in SPE ? Is there a way to contain the fault in NS world? Thanks Sandeep
Hi Sandeep,
Your question is about architecture and beyond TF-M scope.
Assume you are referring to BFHFNMINShttps://developer.arm.com/documentation/ka004627/latest bit.
Please find the answers from Cortex-M architecture experts:
There's plenty of ways in which the NS state can attempt to attack the S state. The goal of the architecture is to detect and report these attacks to the S state. BusFault is a particularly interesting one as the fault can be asynchronous so it may not be possible to determine which state triggered the error. Secure code must therefore assume the worse and handle the fault accordingly.
The design of Armv8-M does not prevent a Non-secure software from crashing a system. But it ensures that if anything "bad" happened, a fault handler in the Secure world would execute. The key objective is that if a Non-secure world crashed, it should not end up with Secure data being leaked, or Secure resources being manipulated.
For example,
- if BFHFNMINS is set to 0 (normal for a TrustZone environment), a bus error triggers a BusFault in the Secure world
- if an invalid FNC_RETURN or EXC_RETURN is carried out, it could trigger fault in SPE. But such issue should be catch by stack sealing and therefore SPE can handle the error.
Regards,
Anton
-----Original Message----- From: Sandeep Tripathy via TF-M tf-m@lists.trustedfirmware.org Sent: Monday, March 20, 2023 3:53 PM To: tf-m@lists.trustedfirmware.org Subject: [TF-M] How does TF-M deal with the faults originated from NSPE
Hi tf-m experts,
I have a fundamental query on v8m trustZone and containability of secure fault and other escalated HardFaults to SPE.
With BFHFNMINA set to '0' IIUC that a malicious actor in NSPE can willingly cause fault in SPE ? Is there a way to contain the fault in NS world?
Thanks
Sandeep
--
TF-M mailing list -- tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org To unsubscribe send an email to tf-m-leave@lists.trustedfirmware.orgmailto:tf-m-leave@lists.trustedfirmware.org
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
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
Hi Sandeep,
Regarding the fault handlers. All TF-M SPE faults cause tfm_core_panic() as recommended by PSA. https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/platform/ex... A particular platform can provide an alternative reaction but as far as I cannot see such. Could you point to the default dummy handlers you mentioned?
Hope that helps, Anton
-----Original Message----- From: Joseph Yiu via TF-M tf-m@lists.trustedfirmware.org Sent: Tuesday, March 21, 2023 6:57 PM To: tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: [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 -- TF-M mailing list -- tf-m@lists.trustedfirmware.org To unsubscribe send an email to tf-m-leave@lists.trustedfirmware.org
Hi Anton, I had reviewed an old forked code with "b ." . I see the default is 'tfm_core_panic()' now and I agree that is the right thing to do with what v8m arch offers.
Thanks Joseph for the clarifications.
Thanks Sandeep
tf-m@lists.trustedfirmware.org
-
Anton Komlev -
Joseph Yiu -
Sandeep Tripathy -
sandeep tripathy