Secure World Non-Preemptive Nature and TrustZone Execution Model
The ARM TrustZone architecture provides a hardware-based security foundation by partitioning the system into two distinct worlds: the Secure World and the Non-Secure World. The Secure World is designed to handle sensitive operations, such as cryptographic functions, secure boot, and trusted execution environments (TEEs), while the Non-Secure World runs the general-purpose operating system and applications. A key characteristic of the Secure World is its non-preemptive nature, meaning that once the processor is executing in the Secure World, it retains control until it explicitly decides to return to the Non-Secure World. This transition is typically triggered by a Secure Monitor Call (SMC) or the completion of a secure operation.
However, the non-preemptive nature of the Secure World can lead to confusion when considering scenarios where the TrustZone Execution Environment (TEE) is managed by a userspace daemon in the Non-Secure World. In such cases, the TEE appears to be preempted, which seems to contradict the fundamental design of TrustZone. This apparent contradiction arises from the interaction between the Secure and Non-Secure Worlds, particularly in how interrupts and scheduling are handled.
The TrustZone architecture allows for different software models, including cooperative and preemptive models. In the cooperative model, the Secure World retains full control and only yields to the Non-Secure World when it explicitly decides to do so. In contrast, the preemptive model requires cooperation between the two worlds, where the Secure World can be interrupted by Non-Secure World events, such as interrupts, under specific conditions. This preemptive behavior is not inherent to TrustZone but is instead a result of software design choices that enable the Secure World to respond to external events while maintaining security.
Interrupt Handling and Priority Management in TrustZone Systems
The ability to preempt the Secure World depends heavily on how interrupts are managed within the system. ARM’s Generic Interrupt Controller (GIC) plays a critical role in this process by allowing interrupts to be classified as Secure or Non-Secure and assigning priorities to them. When the processor is executing in the Secure World, it can choose to mask or ignore Non-Secure interrupts, effectively maintaining its non-preemptive behavior. Alternatively, the Secure World can configure the GIC to allow certain Non-Secure interrupts to trigger a return to the Non-Secure World.
In a typical implementation, the Secure World may configure the GIC to prioritize Secure interrupts over Non-Secure interrupts. This ensures that critical Secure World operations are not disrupted by lower-priority Non-Secure events. However, if the Secure World does not mask Non-Secure interrupts or configures the GIC to allow specific Non-Secure interrupts to preempt Secure execution, the system can exhibit preemptive behavior. This is often achieved by setting up interrupt priorities in such a way that certain Non-Secure interrupts are treated as high-priority events, forcing the Secure World to yield control.
The decision to allow preemption in the Secure World involves trade-offs between responsiveness and security. Allowing Non-Secure interrupts to preempt Secure execution can improve system responsiveness but may introduce security risks if not carefully managed. For example, a malicious Non-Secure application could exploit preemption to disrupt Secure World operations or gain unauthorized access to sensitive data. Therefore, any implementation that enables preemption must include robust mechanisms to ensure that security is not compromised.
Implementing Cooperative and Preemptive TrustZone Models
To address the challenges of Secure World preemption, developers can implement either a cooperative or preemptive TrustZone model, depending on the specific requirements of their system. In the cooperative model, the Secure World retains full control and only yields to the Non-Secure World when it explicitly decides to do so. This model is straightforward to implement and provides strong security guarantees, as the Secure World is never interrupted by Non-Secure events. However, it may result in reduced system responsiveness, particularly in scenarios where the Secure World performs long-running operations.
In the preemptive model, the Secure World is designed to cooperate with the Non-Secure World, allowing certain Non-Secure interrupts to trigger a return to the Non-Secure state. This model requires careful configuration of the GIC and the Secure World software to ensure that preemption occurs only under controlled conditions. For example, the Secure World may configure the GIC to allow only specific high-priority Non-Secure interrupts to preempt Secure execution. Additionally, the Secure World software must include mechanisms to save and restore its state when preemption occurs, ensuring that Secure operations can resume correctly after control is returned.
A key consideration when implementing a preemptive model is the handling of Secure and Non-Secure interrupts. The Secure World must ensure that its own interrupts are processed promptly, even when allowing Non-Secure interrupts to preempt execution. This can be achieved by configuring the GIC to prioritize Secure interrupts over Non-Secure interrupts or by using interrupt masking to temporarily block Non-Secure interrupts during critical Secure operations.
Another important aspect of implementing a preemptive model is the design of the Non-Secure World software. In systems where the TEE is managed by a userspace daemon, the daemon must be designed to interact with the Secure World in a way that respects the security boundaries of TrustZone. This includes using SMC instructions to transition between the Secure and Non-Secure Worlds and ensuring that Non-Secure interrupts are used responsibly to avoid disrupting Secure operations.
In summary, the non-preemptive nature of the Secure World in ARM TrustZone systems can be adapted to support preemptive behavior through careful software design and configuration of the interrupt controller. By understanding the trade-offs between cooperative and preemptive models and implementing appropriate mechanisms to manage interrupts and state transitions, developers can create TrustZone-based systems that balance security and responsiveness effectively.
