When you are securing a firmware or an application code , it boils down to protecting the portion of memory with MPU. When and why would I use TrustZone-M for securing the firmware when I can actually get it done by an MPU. Any insights are appreciated!
As I expect you know already, the MPU provides a way to divide memory into separate regions, each with its own set of attributes. For example, you could configure one memory region with the read-only and the XN (eXecute Never) attributes, and another region with the read-write attribute.
Systems that include the ARMv8-M Security Extension (known as TrustZone for ARMv8-M) provides a separate unit called the Secure Attribution Unit (SAU). This is similar to the MPU in that it can be used to configure different memory regions. However, the SAU focuses on security and allows system designers to create secure memory regions, which are more suitable for trusted secure software, e.g., secure firmware, and non-secure memory regions suitable for any other software that might run on the system. Also, when the Security Extension is available, the system comes with two MPUs: a secure MPU and a non-secure MPU. Providing this extra level of partitioning/separation, with the addition of additional secure hardware such as an optional Implementation Defined Attribution Unit and Cryptocell IP, further reduces the attack surface.
More information is available on developer.arm.com.
So can I still use an MPU and have read-only attributes to the secure firmware APIs while totally protecting the rest of the secure firmware and achieve what I could with a TrustZone-M? I am trying to understand what an MPU can't that a TrustZone-M can do when it comes to protecting a firmware in the memory.
Thanks
One example of an extra thing the SAU can do is to protect the firmware from other *privileged* code. Any privileged code could reporgram the MPU and bypass your protection, Non-secure privileged code cannot reprogram the SAU.
thank! thats interesting to know