Security configurations on STM32L5, STM32U5, and STM32U3 series
Security configurations on STM32L5, STM32U5, and STM32U3 series
The SAU/IDAU settings are only applicable to one master: the CPU. The other masters (such as DMA) do not see these policies. That is why a local secure gate is needed on the peripheral side.
In addition to the Cortex-M33 TrustZone feature, the STM32L5/U5/U3 devices come with complementary security features that reinforce and allow a more flexible partition between the secure and the nonsecure worlds, by providing a second level of security on top of the SAU/IDAU.
Security configuration of the flash memory
The flash memory regions are configurable as secure, thanks to the nonvolatile flash secure watermark and volatile block‑based flash interface registers, even if they are nonsecure through IDAU/SAU.
SAU and IDAU are responsible to grant the transactions issued by the CPU and tag the CPU access to the interconnect as secure or nonsecure. The flash memory secure watermarks and block‑based registers grant the transactions from the CPU/Cortex-M33 and other masters such as:
STM32L5 masters: DMA1, DMA2 and SDMMC
STM32U5 masters: GPDMA1 (general purpose DMA featuring two master ports), DMA2D, SDMMC1 and SDMMC2
STM32U3 masters: GPDMA1 (general purpose DMA featuring two master ports) and SDMMC1
The option byte defines up to two different non-volatile secure areas, and are read or written by a secure access only:
For STM32L5/U5: SECWMx_PSTRT and SECWMx_PEND (x = 1, 2)
For STM32U3: SECWMx_STRT and SECWMx_END (x=1, 2)
The figure below shows the default value after setting TZEN (the whole flash memory is secure).Figure 3. Default flash memory state though the option bytes after setting TZEN
The STM32CubeL5, STM32CubeU5, and STM32CubeU3 TrustZone examples assume that Bank 1 is secure and Bank 2 is nonsecure. Figure 4. Default flash bank security state defined by STM32Cube though the option bytes
Flash memory block‑based feature
Even if the whole flash memory is nonsecure through IDAU/SAU and through the flash secure watermark option bytes, it is possible to configure temporary secure areas using the flash memory block‑based feature.
Any page is programmed either in secure or nonsecure mode, using the flash interface block‑based configuration registers.
Block‑based registers can only set a page as secure whereas it is set as nonsecure through flash secure watermark option bytes. The opposite is not possible: a page cannot be configured as nonsecure using block‑based registers, when it is configured as secure through flash secure watermark option bytes.
Global TrustZone controller (GTZC)
The GTZC has the following subblocks:
TZSC (TrustZone security controller) allows the security attribute configuration of:
peripherals (see the note below) as either secure or nonsecure
external memories: through watermark-memory-protection controller (MPCWMx, x = 1, 2, 3) (for STM32L5/U5 only)
MPCBBx (block-based memory protection controller) allows the security attribute configuration of SRAM blocks as follows:
STM32L5: The SRAM1 and SRAM2 can be programmed as secure or nonsecure by blocks, using the MPCBBx. The granularity of SRAM secure block‑based is a page of 256 bytes.
STM32U5: The SRAM1, SRAM2, SRAM3, SRAM4 can be programmed as secure or nonsecure by blocks, using the MPCBBx. The granularity of SRAM secure block‑based is a page of 512 bytes.
STM32U3 The SRAM1 and SRAM2 can be programmed as secure or nonsecure by blocks, using the MPCBBx. The granularity of SRAM secure block‑based is a page of 512 bytes.
TZIC (TrustZone illegal access controller) gathers all illegal access events in the system, and generates a secure interrupt towards the NVIC (GTZC_IRQn).
Note: When the TrustZone security is active, a peripheral is either securable or TrustZone-aware:
Securable: the security attribute is configured by GTZC/TZSC controller.
TrustZone-aware: the security attribute is configured using some peripheral secure registers. For example, the GPIO is TrustZone-aware with a security attribute configured through the GPIOx_SECCFGR secure register.
When the TrustZone security is activated by the TZEN option bit in FLASH_OPTR, the default system security state is as follows:
Cortex-M33 CPU is in secure state after reset. The boot address must point toward a secure memory area.
All interrupts are assigned to secure interrupt controller.
All memory map is fully secure through the IDAU/SAU, until the secure code enables the SAU and define regions for nonsecure resources.
The whole flash memory is secure. The security area is defined by watermark user option bytes, for which production values are:
For STM32L5/U5:
SECWMx_PSTRT (x = 1, 2)= 0x00
SECWMx_PEND (x = 1, 2) = 0x7F
For STM32U3:
SECWMX_STRT (x = 1, 2) = 0x00
SECWMx_END (x = 1, 2) = 0x7F
All SRAMs are secure.
For STM32L5/U5: External memories FSMC and OCTOSPIx banks are secure.
For STM32U5, the backup SRAM is secure.
All peripherals (except GPIOs) are nonsecure.
All GPIOs are secure.
All DMA channels are nonsecure.
Backup registers are nonsecure.
Memory and peripheral security access rules
Any transaction issued by the CPU is filtered first by the SAU, then by the secure gate implemented close to the peripheral target (flash memory, SRAM, external memory or any secure peripheral) .
The figure below describes the transaction filtering according to transaction security attribute.Figure 5. Memory and peripheral data access rules summary
The transactions carry their secure attributes. According to these attributes, the access is granted or not by the SAU, then by the flash memory or the GTZC (for SRAMs, external memories and peripherals).
Note:
For STM32L5 only, the nonsecure information block is only accessible by nonsecure transactions. The information block is a flash memory region composed of option bytes, memory protection user configuration, system memory and OTP (one-time programmable) area. In particular, the OTP area, VREFINT and temperature sensor calibration values are only accessed by nonsecure transactions. The secure application must then program an SAU region configuring this area as nonsecure.
Nonsecure access to an address that is secure through SAU/IDAU: the access is blocked whatever the security attribute of the address through Flash/GTZC. A Cortex-M33 secure fault exception is triggered. See (3) in Figure 5 Memory and peripheral data access rules summary.
When the access is blocked, the result is one of the following:
RAZ/WI (read at zero/write ignore)
RAZ/WI and illegal access event/interrupt
Bus error
For example, a nonsecure access to a secure flash memory area is RAZ/WI and generates an illegal access event. An illegal access interrupt is generated if the illegal access interrupt is enabled by FLASHIE in GTZC_TZIC_IER2 for STM32L5 and GTZC1_TZIC_IER4 for STM32U5/U3.
