ARMv8-M TrustZone Secure State to Non-Secure State Branching Faults
In ARMv8-M architectures, the TrustZone security extension provides a robust mechanism for isolating secure and non-secure worlds. This isolation is critical for ensuring that sensitive operations and data in the secure world are protected from potential vulnerabilities in the non-secure world. However, this isolation also introduces complexities when secure code needs to interact with non-secure code. One such complexity arises when secure code attempts to branch directly to non-secure code using standard branch instructions like BLX, BX, or BL, rather than the dedicated TrustZone branch instructions such as BLXNS or BXNS. This direct branching can lead to secure faults, which are exceptions triggered by violations of the TrustZone security rules.
The secure fault occurs because the ARMv8-M architecture enforces strict rules on how transitions between secure and non-secure states are handled. When secure code attempts to branch to non-secure code using a standard branch instruction, the processor detects this as a security violation. This is because the standard branch instructions do not include the necessary mechanisms to ensure that the transition is handled securely. Specifically, they do not handle the secure context saving and restoration that is required to prevent the non-secure world from tampering with the secure world’s execution flow.
The ARMv8-M architecture provides dedicated instructions like BLXNS and BXNS to handle these transitions securely. These instructions ensure that the return address is stored in the secure stack and that the link register (LR) is updated with a special value called FNC_RETURN. This mechanism prevents the non-secure world from modifying the return address, thereby maintaining the integrity of the secure world’s execution flow. When the non-secure function completes, the FNC_RETURN value is used to restore the return address from the secure stack, ensuring a secure transition back to the secure world.
In summary, the secure fault triggered by using standard branch instructions to transition from secure to non-secure state is a deliberate security feature of the ARMv8-M architecture. It ensures that all transitions between secure and non-secure states are handled in a controlled and secure manner, preventing potential security vulnerabilities that could arise from improper state transitions.
Memory Protection Unit (MPU) and Security Attribution Unit (SAU) Configuration Issues
The ARMv8-M architecture includes two key components that play a critical role in enforcing the security boundaries between the secure and non-secure worlds: the Memory Protection Unit (MPU) and the Security Attribution Unit (SAU). The MPU is responsible for defining memory regions and their access permissions, while the SAU is used to assign security attributes to these memory regions. Misconfiguration of either the MPU or the SAU can lead to secure faults when attempting to branch from secure to non-secure code.
The MPU is typically configured to define memory regions with specific access permissions for both secure and non-secure worlds. For example, a memory region containing secure code and data would be configured as secure and accessible only to the secure world. Conversely, a memory region containing non-secure code and data would be configured as non-secure and accessible to both secure and non-secure worlds, depending on the desired level of isolation. However, if the MPU is misconfigured, it can lead to situations where secure code attempts to access non-secure memory regions without the proper permissions, resulting in a secure fault.
The SAU, on the other hand, is responsible for assigning security attributes to memory regions. It defines which memory regions are secure and which are non-secure. The SAU configuration is critical for ensuring that the secure and non-secure worlds are properly isolated. If the SAU is misconfigured, it can lead to situations where secure code attempts to branch to non-secure code without the proper security attributes, resulting in a secure fault.
In addition to the MPU and SAU, the ARMv8-M architecture also includes the TrustZone Address Space Controller (TZASC), which is used to define secure and non-secure memory regions at a finer granularity. The TZASC is particularly useful in systems with complex memory hierarchies, where different memory regions may need to be assigned different security attributes. However, like the MPU and SAU, misconfiguration of the TZASC can lead to secure faults when secure code attempts to access non-secure memory regions.
In summary, the MPU, SAU, and TZASC are critical components of the ARMv8-M architecture that enforce the security boundaries between the secure and non-secure worlds. Misconfiguration of any of these components can lead to secure faults when secure code attempts to branch to non-secure code. Proper configuration of these components is essential for ensuring that secure and non-secure code can coexist safely and securely.
Implementing Secure State to Non-Secure State Transitions with BLXNS and BXNS
To safely transition from the secure state to the non-secure state in ARMv8-M architectures, the dedicated TrustZone branch instructions BLXNS and BXNS must be used. These instructions are specifically designed to handle the secure context saving and restoration that is required for secure state transitions. When secure code calls a non-secure function using BLXNS or BXNS, the return address is automatically pushed onto the secure stack, and the link register (LR) is updated with the FNC_RETURN value. This ensures that the non-secure world cannot modify the return address, thereby maintaining the integrity of the secure world’s execution flow.
The BLXNS instruction is used to call a non-secure function from secure code. It takes the address of the non-secure function as an operand and performs the following steps: First, it saves the return address to the secure stack. Second, it updates the LR with the FNC_RETURN value. Finally, it branches to the non-secure function. When the non-secure function completes, it returns using the BXNS instruction, which restores the return address from the secure stack and branches back to the secure world.
The BXNS instruction is used to return from a non-secure function to secure code. It takes the FNC_RETURN value as an operand and performs the following steps: First, it extracts the return address from the secure stack. Second, it branches back to the secure world using the extracted return address. This ensures that the secure world’s execution flow is not compromised by the non-secure world.
In addition to using BLXNS and BXNS, secure code must also ensure that the MPU, SAU, and TZASC are properly configured to allow secure state transitions. This includes defining the appropriate memory regions and security attributes for both secure and non-secure worlds. Proper configuration of these components is essential for ensuring that secure state transitions are handled safely and securely.
In summary, the BLXNS and BXNS instructions are critical for implementing secure state to non-secure state transitions in ARMv8-M architectures. These instructions ensure that the secure context is properly saved and restored, preventing the non-secure world from tampering with the secure world’s execution flow. Proper configuration of the MPU, SAU, and TZASC is also essential for ensuring that secure state transitions are handled safely and securely.
Conclusion
The ARMv8-M architecture’s TrustZone security extension provides a robust mechanism for isolating secure and non-secure worlds. However, this isolation introduces complexities when secure code needs to interact with non-secure code. Direct branching from secure to non-secure code using standard branch instructions like BLX, BX, or BL can lead to secure faults, which are exceptions triggered by violations of the TrustZone security rules. These secure faults are a deliberate security feature of the ARMv8-M architecture, ensuring that all transitions between secure and non-secure states are handled in a controlled and secure manner.
To safely transition from the secure state to the non-secure state, the dedicated TrustZone branch instructions BLXNS and BXNS must be used. These instructions ensure that the secure context is properly saved and restored, preventing the non-secure world from tampering with the secure world’s execution flow. Proper configuration of the MPU, SAU, and TZASC is also essential for ensuring that secure state transitions are handled safely and securely.
In conclusion, understanding the intricacies of secure state to non-secure state transitions in ARMv8-M architectures is critical for developing secure and reliable embedded systems. By using the appropriate branch instructions and properly configuring the MPU, SAU, and TZASC, developers can ensure that their systems are protected from potential security vulnerabilities while still allowing secure and non-secure code to coexist safely.
