Security of Bus Accesses
Article ID: 131324001
Published date: 04 Aug 2017
Last updated: -
Applies to: ARMv8-M, Cortex-M23, Cortex-M33
How does the processor determine the Security signaling on the bus interface?
This knowledge article provides an overview of which Security level the processor will signal on its bus interface under which circumstances. For more complete details, please see the ARMv8-M Architecture Reference Manual.
The ARMv8-M Architecture Reference Manual, section B3.13 covers the memory accesses from the processor.
When the processor is in Non-secure state, data accesses are issued as Non-secure accesses.
When the processor is in Secure state, data accesses are issued with the security attribute set to match the security of the address being accessed, as determined by whichever is the more restrictive of the attributions for the address from the Security Attribution Unit (SAU) and the Implementation Defined Attribution Unit (IDAU).
Instruction fetches are issued to match the security state of the address being fetched. This means that the processor in Non-secure state can fetch any instruction, Secure or Non-secure. However, execution of a Secure instruction when in Non-secure state is only possible if the instruction is a Secure Gateway (SG) instruction located fully in memory designated as Secure and Non-secure Callable (NSC). This is the defined mechanism for calling Secure functions from Non-secure code.
Section B11.3.4 covers the security of debugger accesses. If DHCSR.S_SDE is set and the debugger requests a secure access, the access will be issued as Secure. If the debugger requests a Non-secure access, or DHCSR.S_SDE is not set, the access will be issued as Non-secure. The DHCSR.S_SDE bit reflects the current Secure debug authentication status of a running processor, or for a halted processor, the security state and authentication state at the point where it was halted.