Reading Secure CONTROL Register Fields on Cortex-M33 with TrustZone-M Using GDB

Understanding Secure and Non-Secure CONTROL Register Banked Fields in Cortex-M33

The ARM Cortex-M33 processor, which incorporates TrustZone-M technology, introduces a dual-world execution environment: Secure and Non-Secure. This separation is critical for implementing robust security architectures in embedded systems. The CONTROL register in the Cortex-M33 is one of the key registers that is banked between these two worlds. This means that the Secure world and the Non-Secure world each have their own instance of the CONTROL register, allowing them to maintain independent configurations for certain control bits.

The CONTROL register in the Cortex-M33 is responsible for managing the stack selection, privilege level, and floating-point context. In the context of TrustZone-M, some fields of the CONTROL register are banked, meaning they have separate instances in the Secure and Non-Secure worlds. This banking mechanism ensures that the Secure world can maintain its own stack and privilege settings without interfering with the Non-Secure world, and vice versa.

When debugging a Cortex-M33 processor using GDB, reading the Secure version of the CONTROL register is not straightforward because GDB, by default, accesses the Non-Secure world’s registers. This can be problematic when debugging Secure firmware, as the Secure CONTROL register fields are not directly accessible through standard GDB commands. The challenge lies in configuring GDB to access the Secure world’s registers, particularly the CONTROL register, which is essential for understanding the current state of the Secure world’s stack, privilege level, and floating-point context.

DSCSR Configuration and Secure Debug Access in Cortex-M33

The Debug Security Control and Status Register (DSCSR) plays a pivotal role in enabling access to Secure world registers from a debugger like GDB. The DSCSR is part of the ARMv8-M architecture and is specifically designed to manage the debug access to the Secure and Non-Secure worlds. By configuring the DSCSR, developers can control whether the debugger has access to the Secure or Non-Secure world’s resources, including the banked CONTROL register.

The DSCSR contains several fields that are relevant to this discussion. The most important field is the CDS (Current Domain Secure) bit, which determines whether the debugger is currently accessing the Secure or Non-Secure world. When the CDS bit is set to 1, the debugger has access to the Secure world’s resources, including the Secure CONTROL register. When the CDS bit is set to 0, the debugger accesses the Non-Secure world’s resources.

Another important field in the DSCSR is the SBRSEL (Secure Banked Register Select) bit. This bit controls whether the debugger accesses the banked registers (such as the CONTROL register) from the Secure or Non-Secure world. When the SBRSEL bit is set to 1, the debugger accesses the Secure world’s banked registers. When the SBRSEL bit is set to 0, the debugger accesses the Non-Secure world’s banked registers.

To read the Secure CONTROL register using GDB, the DSCSR must be configured to enable access to the Secure world’s resources. This involves setting the CDS bit to 1 and the SBRSEL bit to 1. Once these bits are set, GDB can access the Secure CONTROL register, allowing developers to inspect the Secure world’s stack selection, privilege level, and floating-point context.

Configuring GDB to Access Secure CONTROL Register on Cortex-M33

To read the Secure CONTROL register using GDB on a Cortex-M33 processor, the following steps must be taken:

1. Enable Secure Debug Access: Before accessing the Secure CONTROL register, the debugger must be granted access to the Secure world. This is done by setting the CDS bit in the DSCSR to 1. This can be achieved by writing to the DSCSR using a GDB command. For example, the following GDB command can be used to set the CDS bit:

   set *((unsigned int*)0xE000EE08) = 0x00000001
   

   This command writes the value 0x00000001 to the DSCSR, setting the CDS bit to 1 and enabling Secure debug access.

2. Select Secure Banked Registers: Once Secure debug access is enabled, the next step is to configure the DSCSR to access the Secure world’s banked registers. This is done by setting the SBRSEL bit in the DSCSR to 1. The following GDB command can be used to set the SBRSEL bit:

   set *((unsigned int*)0xE000EE08) = 0x00000003
   

   This command writes the value 0x00000003 to the DSCSR, setting both the CDS and SBRSEL bits to 1. This ensures that GDB accesses the Secure world’s banked registers, including the Secure CONTROL register.

3. Read the Secure CONTROL Register: With the DSCSR properly configured, GDB can now access the Secure CONTROL register. The following GDB command can be used to read the Secure CONTROL register:

   p/x $control
   

   This command prints the value of the Secure CONTROL register in hexadecimal format. The output will reflect the current state of the Secure world’s stack selection, privilege level, and floating-point context.

4. Restore Non-Secure Debug Access: After reading the Secure CONTROL register, it is important to restore the debugger’s access to the Non-Secure world. This is done by clearing the CDS and SBRSEL bits in the DSCSR. The following GDB command can be used to restore Non-Secure debug access:

   set *((unsigned int*)0xE000EE08) = 0x00000000
   

   This command writes the value 0x00000000 to the DSCSR, clearing both the CDS and SBRSEL bits and restoring access to the Non-Secure world’s resources.

By following these steps, developers can successfully read the Secure CONTROL register using GDB on a Cortex-M33 processor with TrustZone-M. This capability is essential for debugging Secure firmware and ensuring that the Secure world’s stack, privilege level, and floating-point context are correctly configured.

Additional Considerations for Secure Debugging on Cortex-M33

While the above steps provide a straightforward method for reading the Secure CONTROL register, there are several additional considerations that developers should keep in mind when debugging Secure firmware on a Cortex-M33 processor:

1. Secure Debug Authentication: Access to the Secure world’s resources is typically protected by Secure debug authentication mechanisms. These mechanisms ensure that only authorized debuggers can access the Secure world’s resources. Before attempting to read the Secure CONTROL register, developers must ensure that the debugger has been properly authenticated and granted access to the Secure world. This may involve configuring the device’s Secure debug settings or providing a Secure debug key.

2. Debugger Compatibility: Not all debuggers support the configuration of the DSCSR and access to the Secure world’s resources. Developers should ensure that their debugger (in this case, GDB) is compatible with the ARMv8-M architecture and supports the necessary commands for configuring the DSCSR and accessing Secure registers. If the debugger does not support these features, developers may need to use a different debugger or implement custom scripts to configure the DSCSR.

3. Impact on System Behavior: Configuring the DSCSR to access the Secure world’s resources can have an impact on the system’s behavior. For example, setting the CDS bit to 1 may temporarily halt Non-Secure world execution while the debugger accesses the Secure world’s resources. Developers should be aware of these potential impacts and take steps to minimize any disruption to the system’s operation.

4. Cache Coherency and Memory Barriers: When accessing Secure world resources, developers should be mindful of cache coherency and memory barriers. The Cortex-M33 processor may use caches to improve performance, and accessing Secure world resources without proper cache management can lead to inconsistent or incorrect results. Developers should ensure that appropriate memory barriers and cache management operations are performed when accessing Secure world resources.

5. Error Handling and Recovery: Debugging Secure firmware can be complex, and errors can occur when attempting to access Secure world resources. Developers should implement robust error handling and recovery mechanisms to handle any errors that may occur during Secure debugging. This may include checking the status of the DSCSR after configuring it, verifying that the Secure CONTROL register was successfully read, and handling any errors that may arise during the debugging process.

By considering these additional factors, developers can ensure that their Secure debugging process is robust, reliable, and minimally disruptive to the system’s operation. This will enable them to effectively debug Secure firmware on the Cortex-M33 processor and ensure that the Secure world’s stack, privilege level, and floating-point context are correctly configured.

Conclusion

Reading the Secure CONTROL register on a Cortex-M33 processor with TrustZone-M using GDB requires careful configuration of the DSCSR to enable access to the Secure world’s resources. By setting the CDS and SBRSEL bits in the DSCSR, developers can configure GDB to access the Secure CONTROL register and inspect the Secure world’s stack selection, privilege level, and floating-point context. However, developers must also consider additional factors such as Secure debug authentication, debugger compatibility, system behavior, cache coherency, and error handling to ensure a robust and reliable Secure debugging process. By following the steps and considerations outlined in this guide, developers can effectively debug Secure firmware on the Cortex-M33 processor and ensure the correct configuration of the Secure world’s resources.