STM32MP25 firewall configuration

Applicable for

This article describes how the STM32MP2 series firewall should be configured to allow STM32 MPU Embedded Software distribution execution.

1. Overview[edit source]

The objective of this article is to provide guidelines for the hardware system firewall configuration taking into account the different platform constraints. On STM32MP2 series, the system firewall protects internal RAM, external memories and internal peripherals. It is the Resource Isolation Framework.
A minimal coherent RIF configuration is required to execute STM32 MPU Embedded Software distribution and support the different low power modes.

2. RIF initial hardware configuration[edit source]

The RIF is made up of several protection units like described in Resource Isolation Framework overview.
The initial hardware configuration depends on the type of peripheral/memory to protect and their usage by the ROM code.

2.1. RIFSC and RISAx[edit source]

Default state for RIFSC and RISAx protection units:

RIFSC RISUP protected peripherals and RIF-aware peripherals (except GPIO):
- Non-secure
- Unprivileged
- CID filtering disabled
RIFSC RIMU for bus master peripherals:
- Non-secure
- Unprivileged
- RISUP in inherited CID mode. This implies a CID0 for all bus master peripherals as RISUP initial configuration is CID filtering disabled
RISAF protected external memories:
- Base region0 only accessible by main processor (TDCID) in secure mode (CID1 Secure when Cortex-A35 is the main processor, CID2 secure when Cortex-M33 is the main processor).
RISAB protected internal memories:
- No CID filtering,
- Security level depends on protected memory. Please refer to RISAB internal peripheral article.

2.2. RIF-Aware peripherals[edit source]

Default state for RIF-Aware peripherals:

RIF component	Secure level	Privilege level	CID filtering
GPIO	Secure	Unprivileged	CID filtering disabled
EXTI	Non-secure	Unprivileged	CID filtering disabled
FMC	Non-secure	Unprivileged	CID filtering disabled
HPDMA	Non-secure	Unprivileged	CID filtering disabled
IPCC	Non-secure	Unprivileged	CID filtering disabled
PWR	Non-secure	Unprivileged	CID filtering disabled
RCC	Non-secure	Unprivileged	CID filtering disabled
RTC	Non-secure	Unprivileged	CID filtering disabled
TAMP	Non-secure	Unprivileged	CID filtering disabled
HSEM	Non-secure	Unprivileged	CID filtering disabled

2.3. Minimal RIF configuration rules[edit source]

According to above statements, a minimal RIF configuration should be performed by the secure OS running on main processor (TDCID) to allow a correct and coherent execution for the embedded SW:

Secure level of GPIO should be aligned with execution level of SW component in charge of IO configuration.
Secure level of RISAB should be aligned with execution level of SW component in charge of IO configuration.
RISAF regions should be programmed to allow the different bus master.
Secure level of some peripherals such as RNG

3. ROM code constraints[edit source]

The STM32MP25x lines ROM code which is running on Cortex-A35, shall be certified SESIP level3. This implies a certain number of security and isolation rules to guarantee ROM code execution:

All secure and non secure HW resources required by ROM code shall be accessible respectively to the Cortex-A35 secure and non-secure each time the ROM code is executed (cold boot, application reset, low power exit).
- RIFSC RISUP configuration associated to ROM code resources shall allow Cortex-A35 access
It shall not be possible to change RIF configuration of secure resources used by ROM code during its execution.
- When Cortex-M33 is the main processor (TDCID), RIFSC RISUP configuration associated to ROM code secure resources must be locked.
No active bus master peripheral shall have same RIF configuration as Cortex-A35 secure context executing secure ROM code.
- If a RIFSC RIMU of a bus master peripheral is defined as Secure and CID1, its associated clock must be disabled during ROM code execution.

ROM code is checking RIFSC and RISAB1&2 (dedicated to SYSRAM protection) configurations. If one setting doesn't match ROM code requirements, ROM code stops its execution and goes in failure.

For more information, please refer to STM32MP2 ROM code resource isolation.

4. STM32MPU Embedded Software ecosystem configuration[edit source]

STM32MPU Embedded Software proposes an ecosystem configuration that:

enables Cortex-A35 and Cortex-M33 secure OSes
enables isolation between Cortex-A35 and Cortex-M33
enables LTDC secure layer
enables authenticated Cortex-M33 coprocessor

To do that, RIF is configured to assign peripherals and features to the different execution contexts with the following rules:

The peripherals and resources used by Cortex-A35 secure OS are configured in secure, privilege and CID1 filtering
The peripherals and resources used by Cortex-M33 secure OS are configured in secure, privilege and CID2 filtering
The peripherals and resources shared by Cortex-A35 and by Cortex-M33 secure OS are configured in Secure, Privilege and semaphore filtering
The peripherals and resources used by Cortex-A35 non-secure OS are in non-secure, privilege and CID1 filtering
The peripherals and resources used by Cortex-M33 non-secure OS are in non-secure, privilege and CID2 filtering
The GPIO associated to one peripheral are configured with the same configuration as associated peripheral
RCC and PWR system resources (resources common to several execution contexts) are configured to be controlled by the main processor (TDCID) secure OS.
All peripherals used by ROM code are configured with access rights compliant with ROM code execution.

Regarding memories, RISAB and RISAF shall be configured according to product memory mapping.

Memory region exclusively used by a SW component shall be configured to allow only access of the execution context (security level, privilege level and CID) running the SW component
Memory region used by secure OS can be defined as encrypted
Memory region shared between to SW components (for inter OS or processor communication) shall be configured to both execution contexts

About bus master peripheral, it is important to define the identity of their accesses by configuring RIFSC RIMU. There are two possible methods:

inherit from RIFSC RISUP protecting peripheral configuration register accesses: In that case, the master port accesses on the bus will have the same RIF attributes as the RISUP of the peripheral. Peripheral can be seen as an extension of the execution context. There no impact on RISAF and RISAB configuration.
Define a dedicated configuration by setting security and privilege levels and specific CID. In that case, RISAF and RISAB configuration must be adapted to allow peripheral to access memory regions shared with SW component controlling it.

Examples:

In case of Cortex-A35 main processor boot from eMMC, SDMMC2 shall be accessible by:

Cortex-A35 ROM code non-secure
Cortex-A35 FSBL TF-A BL2
Cortex-A35 SSBL U-Boot
Cortex-A35 Linux kernel

This implies to configure SDMMC2 RISUP in non-secure, privilege and CID1 (CID filtering enabled).

Moreover, SDMMC2 shall be able to access any buffer allocated by the different SW components. It shall behave as an extension of Cortex-A35 non-secure.

This implies to configure associated RIMU in non-secure, unprivileged and CID inheritance.

Associated device tree configuration is the following one:

&rifsc {
	st,protreg = < 
		RIFPROT(STM32MP25_RIFSC_SDMMC2_ID, RIF_UNUSED, RIF_UNLOCK, RIF_NSEC, RIF_PRIV, RIF_CID1, RIF_SEM_DIS, RIF_CFEN)
	>;
	st,rimu = <
		RIMUPROT(RIMU_ID(2), RIF_UNUSED, RIF_NSEC, RIF_PRIV, RIF_CIDSEL_P)
	>;
};

In case of Cortex-A35 main processor secure boot, some security peripherals like SAES or PKA shall be accessible by

Cortex-A35 ROM code secure
Cortex-A35 FSBL TF-A BL2
Cortex-A35 Secure OS OP-TEE

This implies to configure SAES and PKA RISUP in secure, privilege and CID1 (CID filtering enabled).

Associated device tree configuration is the following one:

&rifsc {
	st,protreg = < 
		RIFPROT(STM32MP25_RIFSC_PKA_ID, RIF_UNUSED, RIF_UNLOCK, RIF_SEC, RIF_PRIV, RIF_CID1, RIF_SEM_DIS, RIF_CFEN)
		RIFPROT(STM32MP25_RIFSC_SAES_ID, RIF_UNUSED, RIF_UNLOCK, RIF_SEC, RIF_PRIV, RIF_CID1, RIF_SEM_DIS, RIF_CFEN)
	>;
};

In case of Cortex-A35 main processor secure boot and secondary secure OS running in Cortex-M33 secure context, some security peripherals like SAES or PKA shall be accessible by

Cortex-A35 ROM code secure
Cortex-A35 FSBL TF-A BL2
Cortex-A35 Secure OS OP-TEE
Cortex-M33 Secure OS TF-M

This implies to configureSAES and PKA RISUP in secure, privilege and shared between CID1 and CID2 thanks to RIF semaphore.

Associated device tree configuration is the following one:

&rifsc {
	st,protreg = < 
		RIFPROT(STM32MP25_RIFSC_PKA_ID, RIF_CID1_BF|RIF_CID2_BF, RIF_LOCK, RIF_SEC, RIF_PRIV, RIF_UNUSED, RIF_SEM_EN, RIF_CFEN)
		RIFPROT(STM32MP25_RIFSC_SAES_ID, RIF_CID1_BF|RIF_CID2_BF, RIF_LOCK, RIF_SEC, RIF_PRIV, RIF_UNUSED, RIF_SEM_EN, RIF_CFEN)
	>;
};

OSTL RIF ecosystem configuration for ST reference board is available in external device tree repository.

5. STM32MPU Embedded Software open configuration[edit source]

STM32MPU Embedded Software proposes also a minimal RIF firewall configuration named "open configuration". The objective of this configuration is to let resources as much as possible available to Cortex-A35 non-secure and Cortex-M33 non-secure contexts and allow all SW components execution. For that, this minimal configuration is following these rules:

Secure resources (peripherals and memory regions) used by either Cortex-A35 or Cortex-M33 secure OS are defined as secure. CID filtering may be enabled
Access to peripherals (and associated IOs) unused by secure OSes are defined as non-secure, unprivileged and CID filtering disabled
Bus master peripherals accesses remain at their default value (non-secure, unprivileged and CID0)
Memory regions unused by secure OSes are configured to allow accesses from any bus master peripherals (non-secure, unprivileged, RW for all CID)

STM32MPU Embedded Software RIF open configuration is available in https://github.com/STMicroelectronics/optee_os.git

6. How to configure RIF[edit source]

6.1. RIF configuration responsibility[edit source]

RIF main configuration is under the TDCID responsibility. CID filtering configuration registers can't be accessed by other masters. That means RIF configuration should be done by the secure OS running on main processor.

Nevertheless, almost all RIF registers are in read for all, that means any execution context can read them to check if it can access a resource or not.

It is also possible to delegate some sub-configurations to some execution contexts. For examples:

Secure master having access to a resource can change its security level
Privileged master having access to a resource can change its privilege level
Memory region can be delegated to one owner (defined by CID, secure and privilege levels) that can define new access rights and sub-regions. It is useful for memory sharing management.

6.2. How to generate RIF configuration[edit source]

The RIF configuration could be done via STM32CubeMX graphical tool. Indeed STM32CubeMX integrates natively RIF information in its different configuration panels:

Peripheral assignment between the different execution contexts allows to generate RIFSC RISUP configuration
RIF-aware configuration panels allow to assign each feature to the different execution contexts to generate associated configuration
RIF panel provides a way to configure the different master interfaces and generate RIFSC RIMU configuration, to create the different memory regions and to generate associated RISAF, RISAB and RISAL

The advantage of using STM32CubeMX is that consistencies between the different RIF components and between the different SW components running on the platform including ROM code are managed. RIF peripheral protection is extended to associated IOs, clock and reset. To guarantee the coherency between all the SW components, CubeMX generates device tree files for all SW components which include RIF and memory and clock tree configuration.

6.3. RIF drivers bindings[edit source]

For more information about RIF configuration in device tree files please refer to device tree configuration pages:

Coming soon