The Security Attribution Unit (SAU) is a hardware security feature introduced in Arm Cortex-M23 and newer Cortex-M processor cores. It provides memory access control and software isolation capabilities to enable secure software execution in Cortex-M based microcontrollers.
Overview of SAU
The SAU controls access permissions to memory regions by attributing memory regions to different security states. It defines isolated security domains in the system, with each security state having its own memory region attribution. The SAU checks each memory access against the configured attributes to enforce security policies at the hardware level.
Some key capabilities offered by the SAU include:
- Attributing memory regions to different security states
- Access permission control for each attributed memory region
- Enforcing security policies for bus masters
- Hardware fault handling for security violations
The SAU enables building secure systems using Cortex-M devices by providing hardware-level isolation between trusted and untrusted software components. It is programmable through a set of SAU registers allowing flexible configuration of security policies.
SAU Security States
The SAU defines two types of security states:
- Secure State – Highest privilege state for trusted software
- Non-secure State – Lower privilege state for untrusted software
Additionally, the Non-secure state can be divided into multiple sub-states for additional software isolation. Up to 16 Non-secure states are supported in total.
Each security state has its own address space defined by attributing memory regions to it. All software executes in a specific security state based on programmer configuration. The SAU checks all memory accesses against the security state access permissions.
SAU Memory Region Attribution
The SAU attributes memory regions to different security states by programming a set of memory region attribution registers. Each attribution region is defined by:
- Start Address – Start address of the memory region
- End Address – End address of the memory region
- Region Number – Numerical ID for the attributed region
- Security Attribute – Security state access permissions
Overlapping regions are not allowed. The smallest attribtuable region is 32 bytes in size. Up to 32 distinct regions can be attributed to each configured security state.
Some devices may include fixed memory region attributes which are hardcoded and cannot be reconfigured by software.
SAU Access Permissions
The SAU enforces access permissions on each attributed memory region. The available permissions are:
- Read/Write – Full access
- Read-only – Read access only
- No access – No read or write access
These permissions apply to bus masters trying to access the region from a particular security state. For example, a region attributed as Read-only for the Non-secure state will allow read but not write access from Non-secure software.
Enforcing Security Policies
The SAU enforces security policies by controlling bus master access permissions to attributed memory regions. Policies are enforced based on:
- Security state – Software security state from which access originates
- Bus master – Hardware bus master index performing the access
- Memory region – Security attribution for target memory region
For each bus master, its security state can be independently configured. The SAU compares the bus master security state, its target memory address, and the region attributes to verify the access is permitted. Any violations are flagged and can generate a fault.
SAU Fault Handling
On detecting a security violation, the SAU signals a fault to the system. Fault handling depends on the system configuration, but typical responses include:
- Generating a hardware exception for handling in software
- Asserting the system reset signal to restart the system
- Flagging the error in SAU status registers
Software exception handlers can implement customized responses like terminating the offending process, logging the violation, or rebooting subsystems. This allows robust handling of security breaches.
Using SAU for Software Isolation
A typical use of the SAU is to isolate trusted from untrusted software. Some examples include:
- Isolating secure bootloader – Bootloader runs in Secure state while applications run in Non-secure states
- Protecting embedded firmware – Critical system firmware runs in Secure state away from external threats
- Separating OS kernel and applications – Kernel runs in Secure state while apps use Non-secure states
The SAU provides the access control mechanisms to enforce isolation between such software components executed in different security states.
Summary
The key points about Arm Cortex-M SAU are:
- Hardware security feature for Cortex-M23+ processor cores
- Atttributes memory regions to Secure and Non-secure security states
- Access permission control on attributed regions
- Checks each access against security policies
- Fault handling for security violations
- Enables trusted execution and software isolation
The SAU is an essential hardware security component for building secure Cortex-M based systems. Utilized properly, it can greatly improve software isolation and resilience against attacks.
