ARMv7 Secure and Non-Secure Mode Stack Pointer Configuration and Undefined Exception Analysis

ARMv7 Secure and Non-Secure Mode Stack Pointer Configuration Challenges

The ARMv7 architecture introduces the concept of Secure and Non-Secure states, which are designed to provide isolation between trusted (Secure) and untrusted (Non-Secure) execution environments. This separation is crucial for systems that require robust security, such as those implementing TrustZone technology. One of the key challenges when working with ARMv7 in such environments is the proper configuration of the Stack Pointer (SP) in both Secure and Non-Secure modes. The Stack Pointer is a critical register that must be correctly initialized for each mode to ensure proper execution of code, especially when dealing with exceptions and interrupts.

In ARMv7, the Secure and Non-Secure states have separate Stack Pointers for each processor mode (e.g., IRQ, SVC, etc.). However, the core registers, including the Stack Pointer, are not banked between Secure and Non-Secure states. This means that when transitioning between Secure and Non-Secure states, the values of these registers must be manually managed to avoid corruption or unintended behavior. The challenge arises when attempting to set the Stack Pointer in Non-Secure mode after transitioning from Secure mode, as improper handling can lead to undefined exceptions or other unexpected behavior.

The issue is further complicated by the fact that certain operations, such as modifying the Current Program Status Register (CPSR), can trigger exceptions if not handled correctly. Specifically, when attempting to set the Stack Pointer in Non-Secure mode, an undefined exception may be triggered, even though the Stack Pointer appears to be correctly modified. This behavior can be confusing and requires a deep understanding of the ARMv7 architecture, particularly the interaction between the Secure Configuration Register (SCR), the Hyp Configuration Register (HCR), and the CPSR.

Undefined Exception Triggered by CPSR Modification During Secure to Non-Secure Transition

The undefined exception encountered when attempting to set the Stack Pointer in Non-Secure mode is likely related to the modification of the CPSR. The CPSR contains several control bits, including the interrupt disable bits (CPSR.I and CPSR.F), which are used to enable or disable interrupts and fast interrupts, respectively. These bits are controlled by the SCR and HCR registers, and improper modification of these bits can lead to undefined exceptions.

When transitioning from Secure to Non-Secure mode, the SCR.NS bit is set to indicate that the processor is entering Non-Secure state. However, if the CPSR is modified immediately after setting the SCR.NS bit, the processor may trigger an undefined exception. This is because the access to certain CPSR bits, such as CPSR.I and CPSR.F, is controlled by the SCR and HCR registers. If these bits are modified while the processor is in an inconsistent state (e.g., during the transition between Secure and Non-Secure modes), an undefined exception may be triggered.

Additionally, the ARMv7 architecture specifies that the usual mechanism for changing from Secure to Non-Secure state is through an exception return. This means that software executing in Monitor mode (which always runs in Secure state) should set the SCR.NS bit to 1 and then perform an exception return to transition to Non-Secure state. Attempting to modify the CPSR directly during this transition can lead to undefined behavior, as the processor may not be in a state where such modifications are allowed.

Proper Stack Pointer Initialization and Exception Handling in ARMv7 Secure and Non-Secure Modes

To properly initialize the Stack Pointer in both Secure and Non-Secure modes and avoid undefined exceptions, the following steps should be taken:

1. Secure Mode Stack Pointer Initialization: Before transitioning to Non-Secure mode, ensure that the Stack Pointers for all relevant modes (e.g., IRQ, SVC, etc.) are correctly initialized in Secure mode. This can be done by switching to each mode and setting the corresponding Stack Pointer register. For example, to set the IRQ mode Stack Pointer in Secure mode, the following code can be used:

   mov r0, #(CPSR_MODE_IRQ | CPSR_IRQ_INHIBIT | CPSR_FIQ_INHIBIT)
   msr cpsr_c, r0
   ldr sp, =__secure_IRQ_stack_core0
   

   This code switches to IRQ mode, disables interrupts, and sets the Stack Pointer to the address of the secure IRQ stack.

2. Transition to Non-Secure Mode: To transition from Secure to Non-Secure mode, use the recommended mechanism of setting the SCR.NS bit and performing an exception return. This ensures that the processor is in a consistent state when transitioning between Secure and Non-Secure modes. The following code demonstrates this process:

   mrc p15, 0, r4, c1, c1, 0  @ Read SCR
   orr r4, r4, #0x0001        @ Set NS bit
   mcr p15, 0, r4, c1, c1, 0  @ Write SCR with NS bit set
   isb                        @ Instruction Synchronization Barrier
   movs pc, lr                @ Exception return to Non-Secure state
   

   This code sets the SCR.NS bit to 1, ensuring that the processor will transition to Non-Secure state upon the exception return.

3. Non-Secure Mode Stack Pointer Initialization: After transitioning to Non-Secure mode, the Stack Pointers for the relevant modes must be initialized. However, care must be taken to avoid modifying the CPSR in a way that could trigger an undefined exception. Instead of directly modifying the CPSR, the mode bits can be modified separately, and the CPSR can be updated without touching the interrupt disable bits. The following code demonstrates this approach:

   mrs r0, cpsr                @ Read CPSR
   bic r0, r0, #0x1F           @ Clear mode bits
   orr r0, r0, #CPSR_MODE_IRQ  @ Set IRQ mode bits
   msr cpsr_c, r0              @ Write CPSR with new mode bits
   ldr sp, =__nsIRQ_stack_core0 @ Set Non-Secure IRQ Stack Pointer
   

   This code reads the current CPSR, modifies only the mode bits, and writes the updated CPSR back without modifying the interrupt disable bits. This avoids triggering an undefined exception while still allowing the Stack Pointer to be set correctly.

4. Exception Handling: If an undefined exception is encountered, it is important to handle it properly to avoid system crashes or other unintended behavior. The undefined exception handler should be designed to log the exception and, if possible, recover from it. The following code provides a basic example of an undefined exception handler:

   undefined_exception_handler:
       push {r0-r12, lr}       @ Save registers
       bl log_exception        @ Log the exception
       pop {r0-r12, lr}        @ Restore registers
       movs pc, lr             @ Return from exception
   

   This handler saves the registers, logs the exception, restores the registers, and returns from the exception. The log_exception function can be implemented to store the exception details in a log buffer or print them to a debug console.

By following these steps, the Stack Pointers in both Secure and Non-Secure modes can be correctly initialized, and the risk of triggering undefined exceptions can be minimized. Proper handling of the CPSR and careful management of the Secure to Non-Secure transition are key to ensuring reliable operation in ARMv7 systems with Secure and Non-Secure states.