ARMv8 Virtual Address Translation and Secure/Non-Secure EL1/0 Physical Address Mapping
The ARMv8 architecture introduces a sophisticated memory management system that supports both secure and non-secure worlds, each with its own exception levels (ELs). A critical question arises when considering virtual address translation in this dual-world environment: Does the same virtual address in secure EL1/0 and non-secure EL1/0 map to the same physical address? This issue is central to understanding how ARMv8 handles memory isolation and security, particularly when secure and non-secure worlds share the same translation table base registers (TTBRs).
In ARMv8, the Memory Management Unit (MMU) is responsible for translating virtual addresses to physical addresses. The translation process is governed by the translation tables pointed to by TTBR0_EL1 and TTBR1_EL1. These registers are accessible in both secure and non-secure EL1/0, raising questions about whether the same virtual address in these two worlds resolves to the same physical address. The answer lies in the interplay between the ARMv8 translation table architecture, the security state, and the configuration of the MMU.
Shared TTBRs and the Role of the Security State in Address Translation
The core of the issue revolves around the shared use of TTBR0_EL1 and TTBR1_EL1 by both secure and non-secure EL1/0. At first glance, it might seem that if the same TTBRs are used, the same virtual address would map to the same physical address in both worlds. However, this assumption overlooks the role of the security state in ARMv8’s memory translation process.
In ARMv8, the security state (secure or non-secure) is a fundamental attribute that influences how the MMU performs address translation. The security state is determined by the current execution context, which is controlled by the Secure Configuration Register (SCR_EL3) and the Non-Secure (NS) bit. When the processor is in the secure state, the MMU uses the secure translation regime, and when in the non-secure state, it uses the non-secure translation regime. These regimes are distinct, even though they share the same TTBRs.
The translation regime determines how the MMU interprets the translation tables. For example, in the secure translation regime, the MMU may apply additional checks or use different table walk behavior compared to the non-secure regime. This means that even if the same TTBRs are used, the physical address resolved for a given virtual address can differ between secure and non-secure EL1/0 due to the differences in the translation regimes.
Implementing Secure and Non-Secure Memory Isolation with ARMv8 MMU Configuration
To ensure proper memory isolation between secure and non-secure worlds, the ARMv8 architecture provides mechanisms to configure the MMU differently for each security state. Below are the key steps and considerations for implementing this isolation:
1. Configuring Translation Tables for Secure and Non-Secure Worlds
The translation tables pointed to by TTBR0_EL1 and TTBR1_EL1 must be carefully configured to enforce the desired memory isolation. In the secure world, the translation tables can include entries that map virtual addresses to secure physical memory regions. In the non-secure world, the same virtual addresses can be mapped to non-secure physical memory regions or marked as invalid to prevent access.
For example, consider a virtual address 0x8000. In the secure world, this address might map to a secure physical address 0x10000, while in the non-secure world, it might map to a non-secure physical address 0x20000. This is achieved by maintaining separate translation tables or by using the same tables with different entries for each security state.
2. Using the NS Bit to Control Access
The NS bit in the translation table descriptors plays a crucial role in distinguishing between secure and non-secure memory. When the NS bit is set to 1, the memory region is treated as non-secure. When it is set to 0, the region is treated as secure. This bit ensures that even if the same translation tables are used, the MMU can differentiate between secure and non-secure memory based on the security state.
For instance, if a translation table entry for virtual address 0x8000 has the NS bit set to 0, the MMU will map this address to a secure physical address when in the secure state. Conversely, if the NS bit is set to 1, the MMU will map the same virtual address to a non-secure physical address when in the non-secure state.
3. Enforcing Memory Isolation with Hardware Mechanisms
ARMv8 provides hardware mechanisms to enforce memory isolation between secure and non-secure worlds. These include:
- Translation Table Walk Caching: The MMU caches translation table walk results separately for secure and non-secure regimes. This ensures that the translation process is consistent within each security state.
- Memory Protection Units (MPUs): In systems without an MMU, MPUs can be used to enforce memory access policies based on the security state.
- TrustZone Address Space Controller (TZASC): The TZASC allows fine-grained control over memory regions, enabling secure and non-secure worlds to have distinct access permissions.
4. Handling Edge Cases and Debugging Common Issues
When configuring the MMU for secure and non-secure worlds, several edge cases and common issues may arise:
- Aliasing Virtual Addresses: If the same virtual address is mapped to different physical addresses in secure and non-secure worlds, care must be taken to ensure that the mappings do not conflict or cause unintended behavior.
- Cache Coherency: When secure and non-secure worlds access the same physical memory, cache coherency must be maintained. This can be achieved using cache maintenance operations and memory barriers.
- Debugging Translation Faults: If a translation fault occurs, it is essential to check the security state, the NS bit, and the translation table entries to identify the root cause.
5. Best Practices for Secure and Non-Secure Memory Management
To ensure robust memory isolation and optimal performance, follow these best practices:
- Use separate translation tables for secure and non-secure worlds whenever possible.
- Clearly define memory regions and access permissions for each security state.
- Regularly validate the MMU configuration using hardware debugging tools and simulation.
- Document the memory map and translation table configuration to facilitate maintenance and troubleshooting.
Conclusion
In summary, the same virtual address in secure EL1/0 and non-secure EL1/0 does not necessarily map to the same physical address in ARMv8. The security state, translation regime, and MMU configuration play critical roles in determining the physical address. By carefully configuring the translation tables, leveraging the NS bit, and using hardware mechanisms like the TZASC, developers can enforce robust memory isolation between secure and non-secure worlds. Understanding these principles is essential for designing secure and efficient embedded systems based on ARMv8 processors.
