Introduction to
Cortex-M33/M25 SAU/IDAU
SITE HOME
Scope:
This techerature introduces the SAU, the Security Attribution Unit
on Certain ARM Cortex-M processors.
It also explains SAU vs IDAU, something which the users are often
confused about.
In previous section(s) we learned about ARM Cortex-M
TrustZone on ARM Cortex-M processors. Here, we explain the
role of SAU and the IDAU in ARM Cortex-M TrustZone technology.
SAU is the Security Attribution Unit. It is present as an build time
option in those ARM Cortex-M processors which support ARM's
TrustZone technology, e.g. M33, M23.
IDAU is the Implementation defined Attribute Unit, it is also
present as a build time option in those ARM Cortex-M processors
which support ARM's TrustZone technology, e.g M33, M23.
While IDAU is an hardware unit that sits outside the processor, the
SAU is software programmable Unit that sits inside the processor.
Both of them can be used to partition the system memory into
secure/non-secure/secure-callable regions.
In terms of who gains the precedence, its like this:
If any region of the memory is defined as 'secure' by either the
IDAU or the SAU, it will be treated as secure.
The address of all access from the processor pass in parallel from
the SAU and the internal counterpart of the IDAU, to check if the
access is a 'secure' or a 'non-secure' access. In case software
running with non-secure access rights tries to access a memory
location which is defined as 'secure' by the SAU or by the IDAU, an
exception is generated.
SAU vs IDAU:
While the SAU is totally an internal Unit, and it is software
programmable, the IDAU is an external Unit, that has a internal
counterpart. The internal counterpart is connected to the external
IDAU via processors' IDAU interface. IDAU is typically a fixed
mechanism to partition the memory into
secure/non-secure/secure-callable regions. In case the IDAU is not
in use the interface signals on the processor, must be tied to a
recommended value as define in the Integration and implementation
Manual.
SAU is not 'fixed' mechanism, and unlike the IDAU, is fully software
programmable, though only by software running with 'secure' access
rights. You can achieve the same results either with SAU or IDAU or
a combination of both.
If the processor has been built enabling the build-time Security
Options selected, and the user does not use the IDAU or the SAU,
then all the accesses from the processor will be treated as
'secured'.
<= PREV : ARM Cortex-M MPU
Next => No Next
Yet
Click Here to Make Comments or ask Questions
SITE HOME