ARM Security Attribution Unit (IDAU/SAU) and Memory Protection Controller (MPC) Interaction
The ARM architecture incorporates several components to manage memory security and access control, including the Implementation Defined Attribution Unit (IDAU), Security Attribution Unit (SAU), and Memory Protection Controller (MPC). These components work together to enforce security policies, but their roles and interactions can be confusing, especially when configuring secure and non-secure memory regions. The IDAU/SAU and MPC serve distinct purposes, and understanding their interplay is critical for designing robust secure systems.
The IDAU and SAU are hardware blocks that define the security state of memory regions at the architectural level. The IDAU is typically a fixed hardware unit that provides a static mapping of secure and non-secure memory regions, while the SAU is programmable and allows developers to configure security attributes dynamically. The MPC, on the other hand, enforces access control policies at the memory interface level, ensuring that only authorized transactions are allowed based on the security state of the core and the memory region being accessed.
The confusion arises when the IDAU/SAU and MPC appear to overlap in functionality. For example, if the IDAU/SAU defines a memory region as secure, but the MPC enforces a conflicting policy, the system may behave unexpectedly. This overlap is not redundant but rather a deliberate design choice to provide layered security. The IDAU/SAU operates at the architectural level, ensuring that the core adheres to the security state of the memory region, while the MPC operates at the implementation level, enforcing access control based on the physical memory layout.
Misconfiguration of Memory Aliasing and Security State Propagation
One of the primary causes of confusion is the misconfiguration of memory aliasing and the propagation of security states between the core, IDAU/SAU, and MPC. Memory aliasing refers to the practice of mapping the same physical memory region to multiple address spaces with different security attributes. For example, a memory region might be mapped to both secure and non-secure address spaces, with the IDAU/SAU determining the security state based on the address being accessed.
In the scenario described, the core is configured to use aliased addresses, where the non-secure address space starts at 0x00000000 and the secure address space starts at 0x10000000. The IDAU is configured to decode the 28th bit to determine the security state, while the MPC is programmed to enforce access control based on the physical memory layout. However, if the core is in non-secure state and accesses the non-secure address space (0x00000000), the IDAU will correctly identify the transaction as non-secure, but the MPC may reject the transaction if the physical memory region is marked as secure.
This misalignment occurs because the IDAU/SAU and MPC operate at different levels of abstraction. The IDAU/SAU provides a logical view of the memory security state, while the MPC enforces a physical view. If the logical and physical views are not aligned, the system will exhibit inconsistent behavior. Additionally, the core’s security state must be propagated correctly to both the IDAU/SAU and MPC to ensure that access control policies are enforced consistently.
Aligning IDAU/SAU and MPC Configurations for Consistent Security Enforcement
To resolve the misalignment between the IDAU/SAU and MPC, it is essential to ensure that their configurations are consistent and that the core’s security state is propagated correctly. The following steps outline the process for aligning the IDAU/SAU and MPC configurations and troubleshooting common issues.
Step 1: Verify IDAU/SAU Configuration
The first step is to verify that the IDAU/SAU is configured correctly to reflect the desired memory security attributes. The IDAU typically provides a static mapping of secure and non-secure memory regions, while the SAU allows for dynamic configuration. Ensure that the IDAU/SAU is programmed to match the physical memory layout and that the security state is correctly decoded based on the address being accessed.
For example, if the secure memory region is located at physical addresses 0x0000 to 0x1FFF and the non-secure region is located at 0x2000 to 0x4000, the IDAU/SAU should be configured to map these regions to the appropriate logical address spaces. The 28th bit decoding should be consistent with the address aliasing scheme, ensuring that the core’s security state aligns with the memory region being accessed.
Step 2: Configure the MPC for Physical Memory Access Control
Once the IDAU/SAU configuration is verified, the next step is to configure the MPC to enforce access control based on the physical memory layout. The MPC should be programmed to reflect the same secure and non-secure regions as the IDAU/SAU, ensuring that access control policies are enforced consistently.
For example, if the secure memory region is located at physical addresses 0x0000 to 0x1FFF, the MPC should be configured to allow access only from the secure state. Similarly, the non-secure region at 0x2000 to 0x4000 should be configured to allow access only from the non-secure state. This ensures that the MPC enforces the same security policies as the IDAU/SAU, preventing unauthorized access to secure memory regions.
Step 3: Propagate the Core’s Security State Correctly
The final step is to ensure that the core’s security state is propagated correctly to both the IDAU/SAU and MPC. The core’s security state determines whether a transaction is secure or non-secure, and this state must be communicated to both the IDAU/SAU and MPC to ensure consistent access control.
For example, if the core is in non-secure state and accesses the non-secure address space (0x00000000), the IDAU/SAU should correctly identify the transaction as non-secure, and the MPC should allow the transaction if the physical memory region is marked as non-secure. If the core’s security state is not propagated correctly, the MPC may reject the transaction, leading to access violations.
Step 4: Debugging and Validation
To validate the configuration, use debugging tools to monitor the core’s security state, the IDAU/SAU’s security attribution, and the MPC’s access control decisions. Verify that the security state is propagated correctly and that access control policies are enforced consistently. If discrepancies are found, revisit the IDAU/SAU and MPC configurations to ensure alignment.
For example, if the MPC rejects a transaction that should be allowed, check the IDAU/SAU configuration to ensure that the security state is correctly attributed. Similarly, if the MPC allows a transaction that should be rejected, verify that the MPC is configured to enforce the correct access control policies.
Step 5: Addressing Non-Secure Callable (NSC) Regions
In systems that include Non-Secure Callable (NSC) regions, additional care must be taken to ensure that the IDAU/SAU and MPC configurations are aligned. NSC regions are used to allow non-secure code to call secure functions, and they require specific security attributes to be set in both the IDAU/SAU and MPC.
For example, if an NSC region is located at physical addresses 0x3000 to 0x3FFF, the IDAU/SAU should be configured to mark this region as NSC, and the MPC should be configured to allow access from both secure and non-secure states. This ensures that non-secure code can call secure functions without violating access control policies.
By following these steps, you can align the IDAU/SAU and MPC configurations to ensure consistent security enforcement and avoid the confusion caused by misaligned memory aliasing and security state propagation. This approach provides a robust foundation for designing secure systems using ARM architectures.
