ARM Cortex-M23 TrustZone Configuration Failures: SAU and SCB_NS Write Issues

ARM Cortex-M23 TrustZone Initialization and SAU Configuration Problems

The ARM Cortex-M23 processor, designed for embedded systems requiring robust security, incorporates ARM TrustZone technology to create a secure and non-secure (NS) execution environment. TrustZone enables the partitioning of memory and peripherals into secure and non-secure regions, managed by the Security Attribution Unit (SAU) and System Control Block Non-Secure (SCB_NS) registers. However, during the initialization of TrustZone, developers often encounter issues where writes to the SAU and SCB_NS registers fail, preventing the proper configuration of secure and non-secure memory regions.

The SAU is responsible for defining the memory regions as secure or non-secure. It consists of multiple region registers, including the Region Limit Address Register (RLAR) and Region Number Register (RNR). The SCB_NS, on the other hand, manages the non-secure vector table offset and other system control functions in the non-secure state. When TrustZone is enabled, the Cortex-M23 processor must correctly initialize these registers to establish the secure and non-secure memory map.

In the described scenario, the developer attempted to configure the SAU with four regions: one Non-Secure Callable (NSC) region, two non-secure regions, and one disabled region. Additionally, they tried to set the non-secure vector table address in the SCB_NS->VTOR register. However, the writes to both the SAU and SCB_NS registers failed, and no changes were observed in the memory locations corresponding to these registers. This failure indicates that the processor did not recognize the TrustZone configuration, leading to a non-functional secure environment.

The absence of HardFault or other exceptions during the failed writes suggests that the processor did not generate any error conditions, further complicating the debugging process. This behavior is atypical, as improper TrustZone configuration typically results in fault exceptions or access violations. The developer also confirmed that the disassembly of the code showed correct STR instructions with the appropriate values and destinations, ruling out simple coding errors.

TrustZone Disabled in Virtual Prototype or SoC Configuration

The root cause of the issue lies in the TrustZone configuration at the hardware level. The ARM Cortex-M23 processor relies on the SoC or virtual prototype to enable TrustZone functionality. If TrustZone is disabled at this level, the processor will not recognize or execute TrustZone-related operations, including writes to the SAU and SCB_NS registers. This behavior is consistent with the observed symptoms, where the processor appears to ignore the TrustZone configuration attempts.

To verify whether TrustZone is enabled, the developer can inspect the ID_PFR1 register, specifically bits 7:4. These bits indicate the presence of the Security Extension (TrustZone) in the processor. A value of 0b0001 in these bits confirms that TrustZone is enabled. In the described case, the developer checked the ID_PFR1 register using the debugger memory window and found that the bits were all zero, indicating that TrustZone was not enabled.

The virtual prototype used in this scenario was based on the Cortex-M23 Fast Model, which allows for the simulation of the processor’s behavior. However, the model generation process did not enable TrustZone by default. The Fast Model includes configuration options, such as "SECEXT," which must be explicitly enabled to activate TrustZone functionality. Without this option, the model behaves as if TrustZone is disabled, leading to the observed issues.

Enabling TrustZone in Cortex-M23 Fast Model and Debugging Steps

To resolve the issue, the developer must ensure that TrustZone is enabled in the Cortex-M23 Fast Model or the actual SoC. This involves modifying the model configuration to include the "SECEXT" option, which activates the Security Extension. Once TrustZone is enabled, the processor will recognize and execute TrustZone-related operations, allowing the SAU and SCB_NS registers to be configured correctly.

The following steps outline the process for enabling TrustZone and verifying its configuration:

1. Model Configuration: Access the Cortex-M23 Fast Model configuration settings and locate the "SECEXT" option. Enable this option to activate TrustZone functionality. If using an actual SoC, consult the hardware documentation to ensure that TrustZone is enabled at the hardware level.

2. Register Verification: After enabling TrustZone, verify the ID_PFR1 register to confirm that bits 7:4 are set to 0b0001. This indicates that the Security Extension is active. Use the debugger memory window to inspect the register values directly.

3. SAU and SCB_NS Configuration: Reattempt the configuration of the SAU and SCB_NS registers. Ensure that the SAU regions are defined correctly, with appropriate values for the RLAR and RNR registers. Set the non-secure vector table address in the SCB_NS->VTOR register.

4. Debugging and Validation: Use the debugger to step through the initialization code and verify that the writes to the SAU and SCB_NS registers are successful. Check the memory locations corresponding to these registers to confirm that the values have been updated.

5. State Verification: Determine the current state of the processor (secure or non-secure) by inspecting the CONTROL register. The SPSEL bit indicates the stack pointer selection, while the nPRIV bit indicates the privilege level. Additionally, use the TT instruction to check the security attributes of specific memory locations.

6. Exception Handling: Ensure that the exception handlers are correctly configured for both secure and non-secure states. Verify that the vector table addresses are set correctly and that the processor can transition between states without generating faults.

By following these steps, the developer can successfully enable and configure TrustZone on the Cortex-M23 processor, resolving the issues with SAU and SCB_NS register writes. Proper configuration of TrustZone is essential for creating a secure embedded system, and understanding the hardware and model settings is critical for successful implementation.

Additional Considerations for TrustZone Implementation

When working with TrustZone on the Cortex-M23, developers should also consider the following aspects to ensure a robust and secure system:

• Memory Partitioning: Carefully plan the memory layout to define secure and non-secure regions. Use the SAU to enforce these partitions and ensure that sensitive data and code are protected.

• NSC Region: The Non-Secure Callable (NSC) region allows non-secure code to call secure functions. Ensure that the NSC region is correctly defined and that the veneer functions are properly implemented.

• Secure Boot: Implement a secure boot process to verify the integrity of the firmware before execution. This prevents unauthorized modifications and ensures that the system starts in a secure state.

• Debugging and Testing: Use the debugger to thoroughly test the TrustZone configuration. Verify that the secure and non-secure states are correctly enforced and that the system behaves as expected under different conditions.

• Documentation and Support: Refer to the ARM documentation for detailed information on TrustZone implementation. Additionally, seek support from the SoC or virtual prototype provider to address any hardware-specific issues.

By addressing these considerations and following the outlined steps, developers can effectively implement TrustZone on the Cortex-M23 processor, creating a secure and reliable embedded system.