FreeRTOS Placement in ARMv8-M: Secure vs. Non-Secure World Trade-offs
The placement of FreeRTOS in ARMv8-M architectures, particularly in the context of the Secure and Non-Secure worlds, is a critical design decision that impacts system security, performance, and maintainability. ARMv8-M introduces the concept of TrustZone for ARM Cortex-M processors, which partitions the system into Secure and Non-Secure worlds. This partitioning allows developers to isolate sensitive code and data in the Secure world while running less critical code in the Non-Secure world. FreeRTOS, being a popular real-time operating system (RTOS) for embedded systems, can be deployed in either world, but each choice comes with its own set of trade-offs.
Running FreeRTOS in the Secure world allows the RTOS to manage both Secure and Non-Secure tasks directly. This approach simplifies task scheduling and context switching but increases the attack surface of the Secure world. Conversely, running FreeRTOS in the Non-Secure world reduces the exposure of the Secure world but requires additional mechanisms for Secure-Non-Secure communication and context switching. The decision must balance security, performance, and complexity, taking into account the specific requirements of the application.
The ARM Platform Security Architecture (PSA) provides guidelines for implementing secure systems, including recommendations for RTOS placement. According to PSA, running FreeRTOS in the Non-Secure world with Secure world helper APIs is the preferred approach. This design minimizes the amount of code running in the Secure world, adhering to the principle of least privilege. However, this approach introduces challenges in managing Secure-Non-Secure transitions, ensuring data integrity, and maintaining system performance.
Memory Partitioning and Privilege Escalation Risks
One of the primary considerations when deciding where to place FreeRTOS in ARMv8-M systems is memory partitioning. ARMv8-M’s TrustZone technology divides the memory map into Secure and Non-Secure regions. The Secure world has access to both Secure and Non-Secure memory, while the Non-Secure world can only access Non-Secure memory. This partitioning is enforced by the Memory Protection Unit (MPU) and the Security Attribution Unit (SAU).
Running FreeRTOS in the Secure world allows the RTOS to manage tasks in both worlds directly. However, this approach increases the risk of privilege escalation. If a vulnerability in the Non-Secure world is exploited, an attacker could potentially gain access to Secure world resources through the RTOS. This risk is particularly concerning in systems where the Secure world handles sensitive operations such as cryptographic key management or secure boot.
On the other hand, running FreeRTOS in the Non-Secure world limits the RTOS’s access to Secure world resources. This design reduces the attack surface of the Secure world but requires careful management of Secure-Non-Secure transitions. The RTOS must rely on Secure world helper APIs for operations that require access to Secure resources, such as context switching or inter-process communication. These transitions introduce overhead and complexity, which can impact system performance and real-time behavior.
Another consideration is the handling of exceptions and interrupts. ARMv8-M allows exceptions to be configured as Secure or Non-Secure. When FreeRTOS runs in the Non-Secure world, Secure exceptions must be handled by Secure world code, while Non-Secure exceptions are handled by the RTOS. This separation requires careful coordination to ensure that exceptions are handled correctly and efficiently.
Implementing Secure-Non-Secure Communication and Context Switching
When FreeRTOS is placed in the Non-Secure world, Secure-Non-Secure communication and context switching become critical components of the system architecture. ARMv8-M provides several mechanisms for Secure-Non-Secure communication, including the Secure Gateway (SG) instruction and the Non-Secure Callable (NSC) memory region. These mechanisms allow Non-Secure code to call Secure world functions in a controlled manner.
The Secure Gateway instruction is used to transition from the Non-Secure to the Secure world. When a Non-Secure function calls a Secure function, the SG instruction validates the call and ensures that it targets a valid entry point in the NSC memory region. This validation prevents unauthorized access to Secure world resources. The NSC memory region contains Secure world functions that can be called from the Non-Secure world. These functions must be carefully designed to minimize the risk of exposing sensitive information or operations.
Context switching between Secure and Non-Secure tasks requires additional considerations. When FreeRTOS runs in the Non-Secure world, it cannot directly manage Secure world tasks. Instead, the RTOS must rely on Secure world helper APIs to perform context switches. These APIs handle the saving and restoring of Secure world context, ensuring that Secure tasks are isolated from Non-Secure tasks. The context switch process must be optimized to minimize latency and ensure real-time performance.
To implement Secure-Non-Secure communication and context switching effectively, developers must carefully design the system’s memory map and exception handling. The NSC memory region should be placed in a secure area of memory, and its size should be minimized to reduce the attack surface. Exception handlers must be configured to handle Secure and Non-Secure exceptions correctly, ensuring that exceptions are processed efficiently and securely.
In addition to these mechanisms, developers should consider using ARM’s Trusted Firmware for Cortex-M (TF-M) as a reference implementation. TF-M provides a set of Secure world services and APIs that can be used to implement Secure-Non-Secure communication and context switching. By leveraging TF-M, developers can reduce the complexity of their system design and ensure compliance with PSA guidelines.
Performance Optimization and Debugging Considerations
Running FreeRTOS in the Non-Secure world introduces performance overhead due to Secure-Non-Secure transitions and context switching. To optimize performance, developers should minimize the frequency of these transitions and ensure that they are implemented efficiently. One approach is to batch multiple operations into a single Secure-Non-Secure transition, reducing the overall number of transitions required.
Debugging systems with FreeRTOS in the Non-Secure world can be challenging due to the separation of Secure and Non-Secure worlds. Developers must use debug tools that support ARMv8-M’s TrustZone technology, allowing them to inspect both Secure and Non-Secure worlds. ARM’s Development Studio and Keil MDK provide comprehensive debugging capabilities for TrustZone-enabled systems, including the ability to set breakpoints and inspect memory in both worlds.
When debugging Secure-Non-Secure communication, developers should pay close attention to the NSC memory region and the Secure Gateway instruction. These components are critical to the system’s security and must be implemented correctly. Debugging tools should be used to verify that Secure-Non-Secure transitions are performed as expected and that Secure world functions are not exposed to unauthorized access.
In conclusion, the placement of FreeRTOS in ARMv8-M systems involves careful consideration of security, performance, and complexity. Running FreeRTOS in the Non-Secure world, as recommended by PSA, reduces the attack surface of the Secure world but requires careful management of Secure-Non-Secure communication and context switching. By leveraging ARM’s TrustZone technology and Trusted Firmware for Cortex-M, developers can implement secure and efficient systems that meet the requirements of their applications.
