Introduction
Arm TrustZone technology offers an efficient, system-wide approach to security with hardware-enforced isolation built into the CPU. It provides the perfect starting point for establishing a device root of trust based on Platform Security Architecture (PSA) guidelines.
The TrustZone of the chip protects security-sensitive software and data in a trusted execution environment against potentially compromised SW running on the platform.
AXI AxPROT Signal
AXI provides access permission signals that can be used to protect against illegal transactions.
ARPROT[2:0] defines the access permission for read accesses.
AWPROT[2:0] defines the access permission for write accesses.
Note
The term AxPROT refers collectively to the ARPROT and AWPROT signals.
AxPROT |
Value |
Description |
|---|---|---|
[0] |
0 |
Unprivileged access |
1 |
Privileged access |
|
[1] |
0 |
Secure access |
1 |
Non-secure access |
|
[2] |
0 |
Data access |
1 |
Instruction access |
An AXI master may support secure and non-secure operating states, and extend this concept of security to memory access. AxPROT[1] identifies an access as a Secure (S) access or Non-secure (NS) access. When it is asserted, the transaction is identified as Non-secure.
TrustZone Overview
TrustZone’s implementation of the chip is to set the security checker for bus slave. The security checker is used to:
Configure the security attribution of the slave (S/NS)
Check the AxPROT[1] signal and the security attribution of the slave when a read/write transaction occurs, to prevent illegal access and achieve the system-level security.
The security checker includes MPC and PPC. Refer to Security Checkers for more information.
Also, bus master needs to support security functions. For CPU, SAU & IDAU of KM4 can allocate different security attributions for different address spaces and can intercept illegal access to CPU. Take KM4 for example:
When executing the code in a secure address space, CPU is in secure state. When read/write an address that is configured as a secure address by SAU&IDAU, the read/write transaction request sent from CPU will assert AxPROT[1] to 0, which means secure access. When read/write an address that is configured as a non-secure address by SAU&IDAU, the read/write transaction request sent from CPU will assert AxPROT[1] to 1, which means non-secure access.
When executing the code in a non-secure address space, CPU is in non-secure state. At this time, the read/write transaction request sent from CPU will assert AxPROT[1] to 1, which means Non-secure access, so CPU can only access Non-secure address space. If CPU tries to access the Secure address space, a secure fault will be triggered.
Caution
Some masters (KM0, Wi-Fi, SDIO, and PPE) are fixed to non-secure attribute and can only send non-secure transaction, while others have the ability of sending secure transaction.
