Where the system designer wants them to be, of course!
There is no restriction on where the various software modules reside. As with all other Cortex-M processors, the system designer is at liberty to build the solution that has the best fit for the target application.
For secure solutions, the recommendation that you hear from security experts is:
Reduce the trusted code to a minimum in order to reduce the attack surface and in order to simplify the security audit.
That is, only put code in the trusted space that has gone through exhaustive inspection and tests against attacks. This trusted code needs to be tested that it works per specification AND it also needs to be tested to make sure it does not work as not expected. (different test mindset)
If we apply the recommendation above then we imagine a code distribution as shown in the diagram above.
The secure boot, device resource manager and the security API would reside in the privileged trusted space. This is the box that has access control to all resources and has the highest priority level.
Trusted libraries reside in the un-privileged but trusted space. These libraries are under control of the resource manager and have further mutual protection using the memory protection unit.
On the un-trusted side, we see the same code distribution as any Cortex-M today. The OS in the privileged box and the application in the user space. This is one of the powerful benefits of TrustZone for ARMv8-M, the user side remains the same while the system gains security. Efficient, and user friendly security, this is the promise of TrustZone for ARMv8-M.
The bulk of the work is in the camp of the developer of the code on the trusted side. A security audit of the code is recommended which is why a smaller code is recommended.
At the same time, new opportunities open up. For example, there will now spring up a new market for IoT node health monitors. A small piece of code in the trusted space that would watch the behaviour of the system to detect anomalies and hack attempts in order to take corrective action. If we consider that the IoT node will remain in the field for multiple years without human intervention then this is probably the most important piece of code that is required to ensure a long operational life.
what do you think about this software layout? Any constructive counter arguments?
Diya Soubra said:A small piece of code in the trusted space that would watch the behaviour of the system to detect anomalies and hack attempts in order to take corrective action.
This is an interesting idea that sounds good but maybe lack of practice & validity, is there any company providing such kind of solutions for low-power iot devices ?
Multiple vendors are looking into this sort of health check. I have not seen their products go public yet.
Keep in mind that this could be something as simple as counting the number of packets transmitted over time.
for example, If I am a sensor node and I am expected to send sensor readings every ten minutes then anything more than a few packets over a ten minute period is suspicious activity (except for firmware update)