SPU — System protection unit

SPU also controls custom logic for an Arm TrustZone for Cortex®-M enabled CPU.

Custom logic is shown as the implementation defined attribution unit (IDAU) in figure Simplified view of SPU protection. Full support is provided for the following:

• Arm TrustZone for Cortex-M related instructions, like test target (TT) for reporting the security attributes of a region
• Non-secure callable (NSC) regions, to implement secure entry points from non-secure code

SPU provides the necessary registers to configure the security attributes for memory regions and peripherals. However, as a requirement to use SPU, the secure attribution unit (SAU) needs to be disabled and all memory set as non-secure in the Arm core. This will allow SPU to control the IDAU and set the security attribution of all addresses as originally intended.

SPU provides support for the definition of non-secure callable (NSC) sub-regions to allow non-secure to secure function calls.

A non-secure callable sub-region can only exist within an existing secure region and its definition is done using the following registers:

• FLASHNSC[n].REGION, used to select the secure region that will contain the NSC sub-region
• FLASHNSC[n].SIZE, used to define the size of the NSC sub-region within the secure region

The NSC sub-region will be defined starting with the highest address in that region and descending. The following figure illustrates the NSC sub-regions and the registers used for their definition.

Figure 3. Non-secure callable region definition in the flash memory space

The NSC sub-region will only be defined when the following are true:

• FLASHNSC[i].SIZE value is non zero
• FLASHNSC[i].REGION defines a secure region

If FLASHNSC[i].REGION and FLASHNSCj].REGION have the same value, there is only one sub-region defined as NSC, with the size given by the maximum of FLASHNSC[i].SIZE and FLASHNSC[j].SIZE.

If FLASHNSC[i].REGION defines a non-secure region, then there is no non-secure callable region defined and the selected region stays non-secure.

SPU and the logic controlled by it will respond with a certain behavior once an access violation is detected.

The following actions will happen once the logic controlled by SPU detects an access violation on one of the flash ports:

• The faulty transfer will be blocked.
• In case of a read transfer, the bus will be driven to zero.
• If supported by the master, feedback will be sent to the master through specific bus error signals. At the same time, SPU will receive an event that can optionally trigger a CPU interrupt.
• A SecureFault exception will be triggered if a security violation is detected for access from the CPU.
• A BusFault exception will be triggered when a read/write/execute protection violation is detected from the CPU.
• The FLASHACCERR event will be triggered if any access violations are detected for all master types except for the CPU security violation.

The following table summarizes the SPU behavior based on the type of initiator and access violation.

For the Arm Cortex-M33 master, the SecureFault exception will take precedence over the BusFault exception if a security violation occurs simultaneously with another type of violation.

The user information configuration registers (UICR) and factory information configuration registers (FICR) are always considered as secure. FICR registers are read-only. UICR registers can be read and written by secure code only.

Writing new values to user information configuration registers must follow the procedure described in NVMC — Non-volatile memory controller. Code execution from FICR and UICR address spaces will always be reported as an access violation except during a debug session.

SPU provides support for the definition of non-secure callable (NSC) sub-regions to allow non-secure to secure function calls.

A non-secure callable sub-region can only exist within an existing secure region. It is defined by the following registers:

• RAMNSC[n].REGION, used to select the secure region that will contain the NSC sub-region
• RAMNSC[n].SIZE, used to define the size of the NSC sub-region within the secure region

The NSC sub-region will be defined starting with the highest address in that region and descending. The following figure shows the NSC sub-regions and the registers used for their definition.

Figure 5. Non-secure callable region definition in the RAM memory space

The NSC sub-region will only be defined when the following are true:

• RAMNSC[i].SIZE value is non zero
• RAMNSC[i].REGION defines a secure region

If RAMNSC[i].REGION and RAMNSC[j].REGION have the same value, there is only one sub-region defined as NSC, with the size given by the maximum of RAMNSC[i].SIZE and RAMNSC[j].SIZE.

If RAMNSC[i].REGION defines a non-secure region, then there is no non-secure callable region defined and the selected region stays non-secure.

SPU and the logic it controls will respond with a certain behavior once an access violation is detected.

The following actions will happen once the logic controlled by the SPU detects an access violation on one of the RAM ports:

• The faulty transfer will be blocked.
• In case of a read transfer, the bus will be driven to zero.
• If supported by the master, feedback will be sent to the master through specific bus error signals.
• A SecureFault exception will be triggered if security violation is detected for access from Arm Cortex-M33
• A BusFault exception will be triggered when read/write/execute protection violation is detected for Arm Cortex-M33. The SPU will also generate an event that can optionally trigger an interrupt towards the CPU.
• The RAMACCERR event will be triggered if any access violations are detected for all master types but for Arm Cortex-M33 security violation

The following table summarizes the SPU behavior based on the type of initiator and access violation.

For the Arm Cortex-M33 master, the SecureFault exception will take precedence over the BusFault exception if a security violation occurs simultaneously with another type of violation.

Peripherals with split security are defined to handle use-cases when both secure and non-secure code needs to control the same resource.

When peripherals with split security have their security attribute set to non-secure, access to specific registers and bitfields within some registers is dependent on the security attribute of the bus transfer. For example, some registers will not be accessible for a non-secure transfer.

When peripherals with split security have their security attribute set to secure, then only secure transfers can access their registers.

See Peripherals for an overview of split security peripherals. Respective peripheral chapters explain the specific security behavior of each peripheral.

Peripherals that have non-secure security mapping have their address starting with 0x4XXXXXXX. Peripherals that have secure security mapping have their address starting with 0x5XXXXXXX.

Peripherals with a user-selectable security mapping are available at an address starting with the following:

• 0x4XXXXXXX, if the peripheral security attribute is set to non-secure
• 0x5XXXXXXX, if the peripheral security attribute is set to secure

Peripherals with a split security mapping are available at an address starting with the following:

• 0x4XXXXXXX for non-secure access and 0x5XXXXXXX for secure access, if the peripheral security attribute is set to non-secure
  • Secure registers in the 0x4XXXXXXX range are not visible for secure or non-secure code, and an attempt to access such a register will result in write-ignore, read-as-zero behavior
  • Secure code can access both non-secure and secure registers in the 0x5XXXXXXX range
• 0x5XXXXXXX, if the peripheral security attribute is set to secure

Any attempt to access the 0x50000000 to 0x5FFFFFFF address range from non-secure code will be ignored and generate a SecureFault exception.

The following table contains the address mapping for the three peripheral types in each configuration.

Peripherals containing a DMA master can be configured so the security attribute of the DMA transfers is different from the security attribute of the peripheral itself. This allows a secure peripheral to do non-secure data transfers to or from the system memories.

The following conditions must be met:

• The DMA field of PERIPHID[n].PERM.SECURITYMAPPING should read as "SeparateAttribute"
• The peripheral itself should be secure (PERIPHID[n].PERM.SECATTR == 1)

Then it is possible to select the security attribute of the DMA transfers using the field DMASEC (PERIPHID[n].PERM.DMASEC == Secure and PERIPHID[n].PERM.DMASEC == NonSecure) in PERIPHID[n].PERM.

Peripherals send error reports once access violation is detected.

The following actions will happen if the logic controlled by the SPU detects an access violation on one of the peripherals:

• The faulty transfer will be blocked.
• In case of a read transfer, the bus will be driven to zero.
• If supported by the master, feedback is sent to the master through specific bus error signals. If the master is a processor supporting Arm TrustZone for Cortex-M, a SecureFault exception will be generated for security related errors.
• The PERIPHACCERR event will be triggered.

DPPI channels can be enabled, disabled and grouped through the DPPI controller (DPPIC). The DPPIC is a split-security peripheral, and handles both secure and non-secure accesses.

A non-secure peripheral access will only be able to configure and control DPPI channels defined as non-secure in SPU's DPPI[n].PERM register(s). A secure peripheral access can control all DPPI channels, independently of the configuration in the DPPI[n].PERM register(s).

The DPPIC allows the creation of group of channels to be able to enable or disable all channels within a group simultaneously. The security attribute of a group of channels (secure or non-secure) is defined as follows:

• If all channels (enabled or not) in the group are non-secure, then the group is considered non-secure
• If at least one of the channels (enabled or not) in the group is secure, then the group is considered secure

A non-secure access to a DPPIC register, or a bitfield controlling a channel marked as secure in DPPI[n].PERM register(s), will be ignored:

• Write accesses will have no effect
• Read will always return a zero value

No exceptions are thrown when a non-secure access targets a register or bitfield controlling a secure channel. For example, if the bit i is set in the DPPI[n].PERM register (declaring the DPPI channel i as secure), then:

• Non-secure write accesses to registers CHEN, CHENSET and CHENCLR will not be able to write to bit i of those registers
• Non-secure write accesses to registers TASK_CHG[j].EN and TASK_CHG[j].DIS will be ignored if the channel group j contains at least one channel defined as secure (it can be the channel i itself or any channel declared as secured)
• Non-secure read accesses to registers CHEN, CHENSET and CHENCLR will always read zero for the bit at position i

For the channel configuration registers (DPPIC.CHG[n]), access from non-secure code is only possible if the included channels are all non-secure, whether the channels are enabled or not. If a DPPIC.CHG[g] register included one or more secure channels, then the group g is considered as secure and only a secure transfer can read or write DPPIC.CHG[g]. A non-secure write will be ignored and a non-secure read will return zero.

The DPPIC can subscribe to secure or non-secure channels through SUBSCRIBE_CHG[n] registers in order to trigger task for enabling or disabling groups of channels. But an event from a non-secure channel will be ignored if the group subscribing to this channel is secure. An event from a secure channel can trigger both secure and non-secure tasks.