Peripherals with split security access

Some peripherals have split security access, meaning they can handle both secure and non-secure access. A subset of the peripheral's functions can be secure, while another subset is non-secure. The security is configured using SPU registers.

The peripheral instantiation table in Instantiation details the peripherals with split access.

Split security access is handled either on the register level or on the bit level, as explained in the following sections.

Register level split security access

For this group of peripherals, security is enforced at the register level. Split security settings apply for the entire register. Illegal access to the register will trigger a security fault. For example, if a register is configured as secure and the register is accessed from non-secure code, a security fault with a bus fault will be generated. A security fault due to an illegal access triggers the SPU event PERIPHACCERR.

Bit level split security access

For this group of peripherals, security is enforced at the register bit level. Split security settings are applied to individual bits of the register. The register supports access from both secure and non-secure code.

No exceptions are triggered for the access, however the following apply:
  • Writing a secure bit from non-secure code will have no effect
  • Reading a register from non-secure code will return 0 for all bits that are secure
For example, if bit i is configured as secure, then the following apply:
  • Non-secure write access to the register will not change bit i
  • Non-secure read access to the register will read 0 for the bit at position i

Interrupts

Some peripherals have split security interrupts. This means the interrupt can be configured with a security attribute.

An interrupt may be generated during secure or non-secure execution, and the interrupt handler is executed based on the interrupt's security attribute.

Interrupts implement split security at the register level. For instance, if interrupt 0 is configured as secure and there is a non-secure read/write access to registers INTEN0, INTENSET0, INTENCLR0, or INTPEND0, a security fault with a bus fault will be generated.

Interrupts are generated when enabled events are triggered. When an event for a split security interrupt is triggered, the following applies.

  • If an interrupt is configured as secure, an event associated to either a secure or non-secure feature can trigger the interrupt.
  • If an interrupt is configured as non-secure, only events associated with non-secure features can trigger the interrupt.

An attempt to enable an interrupt for an event that does not match the ownership and security settings of the interrupt will be ignored and a security fault is not generated.

A non-secure event can be enabled to trigger a secure interrupt.

CRACEN

CRACEN protects the Protected RAM and the SEED register from being accessed by the CPU.

Only KMU is able to push assets to the Protected RAM and the SEED register. The CPU does not have access to these. The hardware has built in protection that does not need configuration.

DPPIC

Individual DPPI channels and channel groups can have independent security attributes that are defined as either secure or non-secure. DPPI supports split security, handling both secure and non-secure access.

DPPI channels

A peripheral configured as non-secure can only subscribe to or publish on non-secure DPPI channels. A peripheral configured as secure can access all DPPI channels. An attempt by a non-secure peripheral to subscribe to or publish on a DPPI channel configured as secure is ignored, and a PPI event is not issued.

DPPI channels are enabled or disabled through individual bits in registers CHEN, CHENSET, and CHENCLR.

The security of a DPPI channel is configured using FEATURE.DPPIC.CH[n] (n=0..23).

DPPI channel groups

Channels can be grouped, which allows them to be enabled or disabled collectively.

A channel group is either secure or non-secure.
  • Secure channel group – includes both secure and non-secure DPPI channels
  • Non-secure channel group – only includes non-secure DPPI channels

An attempt to include a secure DPPI channel in a non-secure DPPI channel group is ignored.

Registers CHG[n], TASKS_CHG[n].EN, TASKS_CHG[n].DIS, SUBSCRIBE_CHG[n].EN, and SUBSCRIBE_CHG[n].DIS configure the DPPI channel groups. A security fault is triggered when an illegal access is made to these registers.

DPPIC subscribe to DPPIC channels through the SUBSCRIBE_CHG[] registers to trigger the task for enabling or disabling channel groups. An event from a secure channel is ignored if the group subscribing to that channel is non-secure. A secure group can subscribe to a non-secure channel or a secure channel.

The security of a DPPIC channel group is configured using FEATURE.DPPIC.CHG[n] (n=0..7).

GPIO

GPIO pins can be either secure or non-secure.

GPIO supports split security, meaning the GPIO pins and registers can be accessed from both secure and non-secure peripherals.

A peripheral configured as non-secure can only access non-secure pins. A peripheral configured as secure will be able to access all pins. An attempt to access a pin configured as secure by a non-secure peripheral is ignored.

GPIO pins can be read and written through individual bits in the GPIO port registers OUT, OUTSET, OUTCLR, and IN. GPIO pin direction is configured individually using bits in registers DIR, DIRSET, and DIRCLR. An attempt to access bits with a different security setting is ignored. Writing to these bits will have no effect, and read access returns a zero value.

The LATCH register has split security. Non-secure code can only read the state of the non-secure pins, while the secure pins read as zero. Secure code is able to read the state of all pins.

The DETECTMODE register applies to the entire port (both secure and non-secure pins), and determines if the latched or non-latched signals will generate the DETECT signal.

Pin security configuration

Access to device pins can be controlled by SPU. A pin can be set as secure so that only secure peripherals or secure code can access it. Pins set as non-secure can be accessed by both secure and non-secure peripherals or code.

The security attribute of each pin can be individually configured in FEATURE.GPIO[n].PIN[o] (n=0..1) (o=0..31). When the secure attribute (SECATTR) is set for a pin, only peripherals that have the secure attribute set will be able to read the value of the pin or change it.

Peripherals can select the pins they need access to through their PSEL registers. If a peripheral has its attribute set to non-secure, but one of its PSEL registers selects a pin with the attribute set to secure, the SPU controlled logic will ensure that the pin selection is not propagated. In addition, the pin value will always be read as zero to prevent a non-secure peripheral from obtaining a value from a secure pin. Access to other pins with the attribute set as non-secure will not be blocked.

Pins can also be dedicated to peripherals by using the CTRLSEL field in the GPIO PIN_CNF[n] register. For pins controlled using CTRLSEL, the SPU PIN security setting is bypassed and pin access is controlled by the peripheral. This is illustrated in the following figure.

Figure 3. Pin access using CTRLSEL
Pin access using CTRLSEL

GPIOTE

Individual GPIOTE channels and interrupts can have independent security settings and are defined as secure or non-secure.

GPIOTE channels

GPIOTE channel security is configured using FEATURE.GPIOTE[n].CH[o] (n=0..1) (o=0..7).

A GPIOTE channel configured as secure can only be used by secure code to send tasks and receive events. A GPIOTE channel configured as non-secure can be used by both secure and non-secure code to send tasks and receive events.

GPIOTE channel tasks and events can be configured with a specific GPIO pin.
  • A secure GPIOTE channel can be configured with both secure and non-secure GPIO pins
  • A non-secure GPIOTE channel can only be configured with non-secure GPIO pins
See CONFIG[n].PSEL and CONFIG[n].PORT registers for more information.

GPIOTE channels that are not configured as described will not write to the pin when triggering the SET[n], CLR[n], and OUT[n] tasks, and will not generate the IN[n] event with changes in the pin polarity.

A GPIOTE channel n configured as secure has the following properties only during secure code execution:
  • Trigger SET[n], CLR[n], and OUT[n] tasks
  • Generate IN[n] events
  • Access to the corresponding CONFIG[n] register
A GPIOTE channel n configured as non-secure has the following properties during both secure and non-secure code execution:
  • Trigger SET[n], CLR[n], and OUT[n] tasks
  • Generate IN[n] events
  • Access to the corresponding CONFIG[n] register

A security fault is triggered when there is an access violation when accessing registers TASKS_SET[n], TASKS_CLR[n], TASKS_OUT[n], EVENTS_IN[n], or CONFIG[n].

GPIOTE channels can connect to PPI channels in order to send and receive events from other peripherals. GPIOTE channels can only publish or subscribe from DPPI channels that have the correct security attribute. An attempt to subscribe or publish on a DPPI channel configured as secure by a non-secure GPIOTE channel is ignored. A secure GPIOTE channel can subscribe or publish to both secure and non-secure DPPI channels.

GPIOTE interrupts

The security of the GPIOTE interrupt is configured using FEATURE.GPIOTE[n].INTERRUPT[o] (n=0..1) (o=0..7).

A secure fault is triggered when non-secure code attempts to access registers INTENSET/INTENCLR on a secure GPIOTE interrupt.

GPIOTE interrupt i can only be generated by IN[j] event if interrupt i and channel j have the correct security attribute.

A secure GPIOTE interrupt can be triggered by an event generated by a secure and non-secure GPIOTE channel.

A non-secure GPIOTE interrupt can only be triggered by an event generated by non-secure GPIOTE channel.

GRTC

GRTC is implemented with split security, meaning it handles access from both secure and non-secure code. Individual GRTC SYSCOUNTER compare/capture channels and interrupts can have independent security settings that define them as secure or non-secure.

SYSCOUNTER compare/capture channels
The SYSCOUNTER compare/capture channels have the following security:
  • Secure — The channel and its associated registers, trigger/subscribe tasks, and receive/publish events can only be accessed by secure code.
  • Non-secure — The channel and its associated registers, trigger/subscribe tasks, and receive/publish events can be accessed by secure and non-secure code.
GRTC interrupts

GRTC interrupts can be defined as secure or non-secure.

A security fault is triggered when an invalid access targets registers INTEN/INTENSET/INTENCLR/INTPEND associated with an GRTC interrupt.

GRTC interrupt can only be generated by a COMPARE[j] event if the interrupt and channel have the correct security attribute.

A secure GRTC interrupt can be triggered by a secure or non-secure GRTC channel.

A non-secure GRTC interrupt can be triggered by an event generated by non-secure GRTC channel. An event generated by secure GRTC channel cannot trigger the interrupt.