ARMv9 RME and TZASC: Coexistence and Functional Overlap
The introduction of ARMv9 architecture brought significant advancements in security and memory management, particularly with the implementation of the Realm Management Extension (RME). RME introduces a new security state, the Realm state, which operates alongside the existing Secure and Non-secure states in ARM’s TrustZone technology. This new state is designed to provide isolated execution environments for sensitive workloads, such as confidential computing. However, the introduction of RME raises questions about the continued functionality of existing security mechanisms, particularly the TrustZone Address Space Controller (TZASC).
TZASC has been a cornerstone of ARM’s TrustZone technology, providing memory protection by partitioning the physical address space into secure and non-secure regions. It allows system designers to define access permissions for different memory regions, ensuring that secure code and data are protected from unauthorized access. With the advent of RME, which introduces its own memory partitioning mechanism through the Granule Protection Table (GPT), there is a natural concern about whether TZASC can still function as intended or if it becomes redundant.
The key issue here is understanding the interaction between RME’s GPT and TZASC in ARMv9 systems. Specifically, the question revolves around whether TZASC can still be used to enforce secure/non-secure access controls in the presence of RME, or if its role is entirely superseded by the GPT. This is a critical consideration for system designers who are migrating to ARMv9 and need to ensure that their existing TrustZone-based security models remain effective.
RME’s Granule Protection Table and TZASC’s Role in Secure State
To understand the compatibility and functional overlap between RME and TZASC, it is essential to delve into the mechanisms of both technologies. RME’s Granule Protection Table (GPT) is a hardware-based mechanism that divides memory into granules, each of which can be assigned to one of four states: Root, Realm, Secure, or Non-secure. The GPT is managed by the Realm Management Monitor (RMM), which operates in the Root state, the highest privilege level in ARMv9. The GPT provides fine-grained control over memory access, ensuring that each granule is accessible only to the appropriate security state.
On the other hand, TZASC operates within the TrustZone Secure state and is responsible for partitioning the physical address space into secure and non-secure regions. It does this by configuring memory regions with specific access permissions, which are enforced by the memory controller. TZASC is particularly useful in systems where multiple masters (e.g., CPUs, DMA controllers) need to access memory, and it ensures that secure masters can access both secure and non-secure regions, while non-secure masters are restricted to non-secure regions.
The critical point of interaction between RME and TZASC lies in the Secure state. According to ARM’s documentation, RME is designed to allow TrustZone to operate independently alongside the new Realm state. This means that TZASC can still be used in the Secure state to enforce secure/non-secure access controls, just as it did in ARMv8. However, TZASC is not intended to be used for managing memory access in the Root or Realm states, as these are governed by the GPT.
This separation of responsibilities ensures that TZASC remains relevant in ARMv9 systems, particularly for legacy TrustZone applications that rely on its memory partitioning capabilities. However, it also means that system designers must carefully consider how to integrate TZASC with RME’s GPT to avoid conflicts or unintended security vulnerabilities. For example, if a memory region is configured as Secure in TZASC but is assigned to the Realm state in the GPT, this could lead to access control issues that compromise the security of the system.
Integrating TZASC with RME: Best Practices and Configuration Guidelines
To ensure that TZASC and RME’s GPT work harmoniously in ARMv9 systems, system designers must follow a set of best practices and configuration guidelines. The first step is to clearly define the memory regions that will be managed by TZASC and those that will be managed by the GPT. This requires a thorough understanding of the security requirements of the system and the specific roles of each security state (Root, Realm, Secure, and Non-secure).
One approach is to use TZASC exclusively for memory regions that are accessed by TrustZone applications in the Secure state, while relying on the GPT for memory regions associated with the Root and Realm states. This ensures that TZASC’s access controls do not interfere with the GPT’s management of Realm memory. Additionally, system designers should ensure that the memory regions configured in TZASC do not overlap with those managed by the GPT, as this could lead to conflicting access permissions.
Another important consideration is the configuration of the memory attributes for each region. In ARMv9, memory attributes such as cacheability, shareability, and access permissions are critical for ensuring proper system behavior. When configuring TZASC, system designers must ensure that the memory attributes for secure regions are consistent with those defined in the GPT for the corresponding security state. This requires careful coordination between the software components that manage TZASC and the RMM, which manages the GPT.
Furthermore, system designers should be aware of the potential performance implications of using both TZASC and the GPT. While TZASC provides robust memory protection, it also introduces additional latency due to the need to check access permissions for each memory transaction. In systems where performance is critical, it may be necessary to optimize the configuration of TZASC to minimize its impact on system performance. This could involve reducing the number of memory regions managed by TZASC or using hardware acceleration features to speed up access permission checks.
Finally, system designers should thoroughly test the integration of TZASC and RME’s GPT to ensure that the system behaves as expected under all conditions. This includes testing for edge cases, such as transitions between security states and concurrent access to memory regions by multiple masters. By following these best practices and configuration guidelines, system designers can ensure that TZASC and RME’s GPT work together effectively to provide robust security in ARMv9 systems.
In conclusion, the introduction of RME in ARMv9 does not render TZASC obsolete. Instead, TZASC continues to play a vital role in enforcing secure/non-secure access controls in the TrustZone Secure state. However, system designers must carefully integrate TZASC with RME’s GPT to avoid conflicts and ensure that the system’s security requirements are met. By following the best practices and configuration guidelines outlined above, system designers can successfully navigate the complexities of ARMv9’s security architecture and build systems that are both secure and performant.
