SPU — System protection unit

For a ARM® TrustZone® for Cortex®-M enabled CPU, the SPU also controls custom logic.

Custom logic is shown as the implementation defined attribution unit (IDAU) in figure Simplified view of the protection of RAM, flash and peripherals using SPU. Full support is provided for:

• 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

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

The 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 two 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 from the highest address in that region, going downwards. Figure below 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 if:

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

If FLASHNSC[i].REGION and FLASHNSC[j].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.

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

The following will happen once the logic controlled by the 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
• Feedback will be sent to the master through specific bus error signals, if this is supported by the master. Moreover, the SPU will receive an event that can optionally trigger an interrupt towards the CPU.
• SecureFault exception will be triggered if security violation is detected for access from Cortex®-M33
• BusFault exception will be triggered when read/write/execute protection violation is detected for Cortex®-M33
• FLASHACCERR event will be triggered if any access violations are detected for all master types except for Cortex®-M33 security violation

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

For a 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 access violation, an exception to this rule applies during a debug session.

The 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 two 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 from the highest address in that region, going downwards. Figure below illustrates 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 if:

• 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.

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

The following 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
• Feedback will be sent to the master through specific bus error signals, if this is supported by the master
• SecureFault exception will be triggered if security violation is detected for access from Cortex®-M33
• BusFault exception will be triggered when read/write/execute protection violation is detected for Cortex®-M33. The SPU will also generate an event that can optionally trigger an interrupt towards the CPU.
• RAMACCERR event will be triggered if any access violations are detected for all master types but for Cortex®-M33 security violation

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

For a 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 Instantiation 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 0x4XXX_XXXX. Peripherals that have secure security mapping have their address starting with 0x5XXX_XXXX.

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

• 0x4XXX_XXXX, if the peripheral security attribute is set to non-secure
• 0x5XXX_XXXX, if the peripheral security attribute is set to secure

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

• 0x4XXX_XXXX for non-secure access and 0x5XXX_XXXX for secure access, if the peripheral security attribute is set to non-secure
  • Secure registers in the 0x4XXX_XXXX 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 0x5XXX_XXXX range
• 0x5XXX_XXXX, if the peripheral security attribute is set to secure

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

The table below illustrates the address mapping for the three type of peripherals in all possible configurations

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 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
• Feedback is sent to the master through specific bus error signals, if this is supported by the master. 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 gis 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.