ARM Cortex-M23 TrustZone Branch Instruction Behavior in Non-Secure State
The ARM Cortex-M23 processor, which implements the ARMv8-M architecture, introduces TrustZone security extensions to enable secure and non-secure state separation. A critical aspect of this architecture is the handling of branch instructions, particularly when transitioning between secure and non-secure states. One specific issue arises when executing branch instructions (e.g., B, BX, BL, BLX, BXNS, BLXNS) in the non-secure state where the target address has a Least Significant Bit (LSB) of 0. This scenario triggers a secure fault, leading to a hardfault exception. Understanding this behavior requires a deep dive into the ARMv8-M architecture, TrustZone implementation, and the role of the LSB in branch target addresses.
In the ARMv8-M architecture, the LSB of a branch target address is not merely a part of the address but serves as an indicator of the instruction set state (Thumb or ARM) and, in the context of TrustZone, the security state. For Thumb instructions, which are the only instruction set supported by Cortex-M23, the LSB is always set to 1. However, when branching to an address with an LSB of 0, the processor interprets this as an attempt to switch to the ARM instruction set, which is unsupported. In the context of TrustZone, this also implies an invalid security state transition, leading to a secure fault.
The secure fault occurs because the processor’s security attribution unit (SAU) and implementation-defined attribution unit (IDAU) enforce strict rules on address decoding and state transitions. When the LSB of a branch target address is 0, the processor cannot determine a valid security state for the target address, resulting in a secure fault. This behavior is consistent with the ARMv8-M architecture’s goal of ensuring robust security state transitions and preventing unauthorized access to secure resources.
Memory Attribution and Security State Transition Rules in ARMv8-M
The root cause of the secure fault lies in the memory attribution and security state transition rules defined by the ARMv8-M architecture. The Cortex-M23 processor uses the SAU and IDAU to classify memory regions as secure or non-secure. These units work in conjunction with the processor’s memory protection unit (MPU) to enforce access rules based on the current security state.
When a branch instruction is executed, the processor checks the target address’s security attributes. If the target address is in a secure region, the processor must be in the secure state or use a secure gateway (SG) instruction to transition to the secure state. Conversely, if the target address is in a non-secure region, the processor must be in the non-secure state. The LSB of the target address plays a crucial role in this process.
In the ARMv8-M architecture, the LSB of a branch target address is used to determine the instruction set state (Thumb or ARM). For Thumb instructions, the LSB must be 1. If the LSB is 0, the processor assumes an attempt to switch to the ARM instruction set, which is unsupported in Cortex-M23. This assumption triggers a secure fault because the processor cannot resolve the security state of the target address. The secure fault is a protective mechanism to prevent invalid state transitions and potential security breaches.
The secure fault is also influenced by the processor’s exception handling mechanism. When a secure fault occurs, the processor enters the secure handler state, which is responsible for handling security-related exceptions. This state transition is part of the ARMv8-M architecture’s layered exception handling model, which ensures that security violations are promptly detected and handled.
Implementing Correct Branch Target Address Handling and Secure State Transitions
To resolve the secure fault issue, developers must ensure that branch target addresses in the non-secure state have an LSB of 1. This requirement applies to all branch instructions, including B, BX, BL, BLX, BXNS, and BLXNS. The following steps outline the necessary actions to implement correct branch target address handling and secure state transitions:
First, developers must verify that all branch target addresses in the non-secure state have an LSB of 1. This can be achieved by reviewing the linker script and ensuring that all function addresses are correctly aligned. The linker script should specify the correct alignment for functions, ensuring that the LSB of their addresses is set to 1.
Second, developers must enable the TrustZone compiler option (-mcmse) when compiling non-secure software. This option ensures that the compiler generates code that adheres to the ARMv8-M architecture’s security requirements. The -mcmse option enables the generation of secure gateway (SG) instructions for secure function calls and ensures that branch target addresses are correctly aligned.
Third, developers must review the assembly code generated by the compiler to ensure that branch instructions use target addresses with an LSB of 1. This review should include checking the addresses of functions and labels used in branch instructions. If any addresses have an LSB of 0, developers must modify the code to ensure correct alignment.
Fourth, developers must implement proper exception handling for secure faults. This includes setting up the secure fault handler to log and diagnose secure fault occurrences. The secure fault handler should also provide mechanisms for recovering from secure faults, such as resetting the processor or transitioning to a safe state.
Finally, developers must test the system thoroughly to ensure that all branch instructions in the non-secure state use target addresses with an LSB of 1. This testing should include both unit tests and system-level tests to verify correct behavior under various conditions. The tests should also cover scenarios where the processor transitions between secure and non-secure states to ensure that all state transitions are handled correctly.
By following these steps, developers can ensure that their Cortex-M23-based systems handle branch instructions correctly in the non-secure state, avoiding secure faults and ensuring robust security state transitions. This approach not only resolves the immediate issue but also enhances the overall security and reliability of the system.
