ARM processors prior to the introduction of the Security Extensions have included a single debug control signal that globally enables or disables debugger access to the processor. Deploying security sensitive software alongside a rich operating environment in these designs implies that debug must be globally disabled, otherwise you risk significant threat from simple hardware attacks.
As operating environments become larger and more complex this starts to become a far from ideal situation, especially when there is a large community of developers who desire to develop software for the rich operating environment. These people need to debug their applications, typically after the device is in the field and the security software has been enabled.
The TrustZone debug extensions separate the debug access control into independently configurable views of each of the following aspects:
Secure privileged invasive (JTAG) debug
Secure privileged non-invasive (trace) debug
Secure user invasive debug
Secure user non-invasive debug
The Secure privileged debug access is controlled by two input signals to the core, SPIDEN (invasive) and SPNIDEN (non-invasive). The Secure user mode debug access is controlled by two bits, SUIDEN (invasive) and SUNIDEN (non-invasive) in a Secure privileged access only CP15 register. These settings enable a TrustZone processor to give control over the debug visibility once the device is deployed. It is, for example, possible to give full Normal world debug visibility while also preventing all Secure world debug.
ARM processors also include global debug enable input signals: DBGEN and, on cores which implement the ARMv7 architecture, NIDEN. These signals can be used to disable all debug visibility of a core, including Normal world debug.
ARMv6: DBGEN - global invasive and non-invasive debug enable.
ARMv7: DBGEN - global invasive debug enable.
ARMv7: NIDEN - global non-invasive debug enable.
In ARM processors implementing the multiprocessor extensions, described in Multiprocessor systems with the Security Extensions, each processor in the cluster is provided with independent DBGEN, NIDEN, SPIDEN and SPNIDEN input signals. This allows a subset of the processors in the cluster to be debugged in a subset of the possible ways.
System designers must be aware that the SMP data coherency hardware may allow a processor with invasive debug enabled to modify the data being used by a processor with invasive debug disabled.
To enable low level benchmarking of code, the ARMv6 and ARMv7 applications-grade processors include a Performance Monitor in CP15. This hardware unit can be used for timing code execution and counting processor events which can occur at run-time, such as cache line evictions.
To prevent the Performance Monitor being used in attacks against the Secure world software, a secure CP15 configuration option can be used to prevent Normal world and user mode access to these counters.