ARM TrustZone Peripheral Access Mechanisms and Security Models
The ARM TrustZone architecture introduces a hardware-based security model that partitions the system into Secure World (SW) and Non-Secure World (NW). This partitioning extends to peripherals, which can be accessed by either world depending on their configuration and the security requirements of the system. The core issue revolves around how peripherals are shared or isolated between the Secure and Non-Secure Worlds, particularly when both worlds require concurrent access to the same peripheral. This is a critical consideration for systems where peripherals like GPUs, timers, or network interfaces are shared between secure and non-secure applications.
The TrustZone architecture uses the NS (Non-Secure) bit in bus transactions to distinguish between Secure and Non-Secure accesses. However, the actual implementation of peripheral access control depends on whether the peripheral is TrustZone-aware or not. TrustZone-aware peripherals, such as the Generic Interrupt Controller (GIC) and System Memory Management Unit (SMMU), can natively handle multiple security states and use the NS bit to enforce access control. Non-TrustZone-aware peripherals rely on the memory system to enforce access policies, which can lead to complications when both worlds attempt to access the same peripheral simultaneously.
For example, consider a GPU that is shared between the Secure and Non-Secure Worlds. If both worlds attempt to load their respective GPU kernels concurrently, the system must ensure that the access is either serialized or that the GPU can handle concurrent accesses securely. This requires a deep understanding of the peripheral’s capabilities, the system’s security requirements, and the mechanisms provided by the TrustZone architecture to manage access.
TrustZone-Aware vs. Non-TrustZone-Aware Peripherals
The behavior of peripherals in a TrustZone-enabled system depends on whether they are TrustZone-aware or not. TrustZone-aware peripherals, such as the GIC and SMMU, are designed to handle multiple security states natively. These peripherals use the NS bit in bus transactions to determine which security state is making the access and can enforce access control based on this information. For example, a TrustZone-aware GPU might have separate configuration registers for Secure and Non-Secure accesses, allowing both worlds to use the GPU concurrently without interfering with each other.
Non-TrustZone-aware peripherals, on the other hand, do not have native support for multiple security states. These peripherals rely on the memory system to enforce access control. In such cases, the peripheral is typically assigned to either the Secure or Non-Secure World, and access from the other world is mediated by software. For example, a simple timer peripheral might be assigned to the Non-Secure World, and any access from the Secure World would need to go through a software interface provided by the Secure Monitor.
The distinction between TrustZone-aware and non-TrustZone-aware peripherals is crucial when designing a system that requires shared access to peripherals. TrustZone-aware peripherals provide a more flexible and secure mechanism for shared access, while non-TrustZone-aware peripherals require careful software management to ensure that access is properly controlled.
Implementing Secure Peripheral Access Control
To implement secure peripheral access control in a TrustZone-enabled system, several steps must be taken. First, the system designer must determine whether the peripheral is TrustZone-aware or not. If the peripheral is TrustZone-aware, the designer can configure the peripheral to handle multiple security states natively. This might involve setting up separate configuration registers for Secure and Non-Secure accesses, or configuring the peripheral to use the NS bit to enforce access control.
If the peripheral is not TrustZone-aware, the designer must assign the peripheral to either the Secure or Non-Secure World and implement a software interface to mediate access from the other world. This might involve using the Secure Monitor to provide a secure API for accessing the peripheral, or implementing a software lock to ensure that only one world can access the peripheral at a time.
In addition to these steps, the system designer must also consider the security requirements of the system. For example, if the system requires that certain peripherals be accessible only from the Secure World, the designer must ensure that these peripherals are properly protected from Non-Secure accesses. This might involve configuring the memory system to enforce access control, or using hardware mechanisms such as the TrustZone Address Space Controller (TZASC) to restrict access to certain memory regions.
Finally, the system designer must consider the performance implications of shared peripheral access. Concurrent access to a peripheral from both Secure and Non-Secure Worlds can lead to performance bottlenecks, particularly if the peripheral is not designed to handle multiple security states. In such cases, the designer might need to implement additional mechanisms, such as priority-based access control or hardware arbitration, to ensure that the peripheral can handle concurrent accesses efficiently.
In conclusion, implementing secure peripheral access control in a TrustZone-enabled system requires a deep understanding of the peripheral’s capabilities, the system’s security requirements, and the mechanisms provided by the TrustZone architecture. By carefully configuring the system and implementing appropriate software interfaces, the designer can ensure that peripherals are accessed securely and efficiently, even in systems where both Secure and Non-Secure Worlds require concurrent access.
