1. Article purpose[edit | edit source]
The purpose of this article is to:
- Briefly introduce the RIF (Resource Isolation Framework) and its main features
- List the different elements that make it up
- Explain how RIF is integrated at system level
2. What is Resource Isolation Framework?[edit | edit source]
The RIF is a fully integrated firewall solution, isolating execution contexts from each other. It protects access to:
- Internal memories
- External memories
- Internal peripherals
- Peripheral features when a peripheral provides multiple features that could be assigned to different execution contexts
And from:
- Any bus master peripherals
2.1. Some key definitions[edit | edit source]
It is important to define a few acronyms used in RIF:
- CID = Compartment IDentifier: identifier added to any bus master peripheral transaction for emitter identification and filtering.
- TDCID = Trusted Domain CID: it is the master owning the highest access rights of the platform, capable of configuring critical secure and system resources. It is the boot processor part of the trusted boot. The value is fixed after ROM code execution.
- DDCID = Debug Domain CID: it is a dedicated CID value, assignable only to the DAP (Debug Access Port) interface, which provides open access to any resource via the JTAG interface to ease platform debug. This configuration is only possible when the device is in "CLOSED_UNSECURED" state and debug is opened by TDCID secure OS during platform boot.
2.2. RIF concept[edit | edit source]
RIF can be seen as an extension of the bus interconnect, adding information at each transaction to identify the emitter and filter transactions in parallel with address decoding.
To do that, a CID is assigned to each bus master (CPU and peripherals) in addition to secure, read/write, execute, and address fields.
The following figure shows all the elements that compose a transaction and which are used to filter access to the different resources of the device.
2.3. RIF composition[edit | edit source]
RIF consists of different elements:
- RIFSC = RIF Security Controller: provide configuration registers for all RIMU, RISUP, and RISAL. Configuration is persistent in low power modes.
- RIMU = Resource Isolation Master Unit: located in front of each bus master port to make the transaction unique.
- RISUP = Resource Isolation Slave Unit Peripheral: located in front of each slave bus connector to filter transactions according to defined rules.
- RISAL = Resource Isolation Slave unit for Address space - Lite version: located in front of low power internal memories to filter access based on variable sized address space regions.
- RISAF = Resource Isolation Slave unit for Address space - Full version: located in front of external memories to filter access based on variable sized address space regions. Configuration lost in low power standby(1/2) modes.
- RISAB = Resource Isolation Slave unit for Address space - Block-based: located in front of internal SRAM to filter access based on fixed-sized embedded memory blocks Configuration lost in low power standby(1/2) modes.
- IAC= Illegal Access Controller: allow to configure and monitor RIF error events.
In addition, some peripherals cannot directly rely on this infrastructure because isolation granularity is not at the peripheral level but at the feature level. For example, RTC offers secure time but also several alarms. It should be possible to assign each RTC feature to a specific execution context. To achieve this, the RIF concept has been integrated directly inside the peripheral itself. Such peripherals are named RIF-aware peripherals. RIF-aware peripherals are in general system and communication peripherals like RCC, PWR, EXTI, GPIO, RTC, IPCC, HSEM, ...
The following figure shows a generic implementation of the RIF in a device.
2.4. RIF protection model[edit | edit source]
2.4.1. RIF access filtering policy[edit | edit source]
As shown below, the access filtering policy differs whether peripheral or memory is accessed:
2.4.2. RIF peripheral protection model[edit | edit source]
RIF offers different protection levels for each protected peripheral resource.
RIF filtering rules are based on:
- Secure level
- Privilege level
- CID
CID filtering has three modes:
- Disabled: any masters fitting secure and privilege levels can access the resource.
- Enabled in static mode: one authorized CID value is defined. Only masters fitting the CID value, secure, and privilege levels can access the resource.
- Enabled in semaphore mode: authorized CIDs are defined in the semaphore CID list. Masters with authorized CID should take the RIF hardware semaphore.
Note: semaphore mode is not present in some RIF-aware peripherals (EXTI, RTC, ...).
Note: in semaphore mode, if the semaphore CID list is empty, the resource cannot be accessed by any master.
2.4.3. RIF memory protection model[edit | edit source]
RIF offers different protection levels for each chunk of memory. Chunk of memory depends on the memory type and associated RISAx protection unit. It could be:
- Fixed pages and blocks for internal memories protected by RISAB
- Configurable region for internal and external memories protected by RISAL or by RISAF
For each chunk of memory, it is possible to define some RIF rules based on:
- Global Secure level
- Global Privilege level (if CID filtering is disabled)
- CID filtering activation
- Read access per CID (if filtering is activated)
- Write access per CID (if filtering is activated)
- Privilege level per CID (if CID filtering is activated)
2.4.4. RIF illegal access detection[edit | edit source]
When a master with bad access rights accesses a resource (peripheral, feature, or memory) RISUP or RISAx is:
- Ignoring write request
- Returning 0 to read request
In addition, IAC (Illegal Access Controller) notifies the TDCID processor when an illegal access occurs. Notification can be enabled peripheral per peripheral. On illegal access detection, TDCID receives an interruption from IAC and can read information about fault access in IAC status registers.
2.5. Master peripherals RIF protection[edit | edit source]
Master peripherals own two bus connections:
- One control port to access configuration registers. This port is protected by a RISUP to filter accesses according to rules defined in RIFSC.
- One initiator port to generate bus read/write accesses. This port is extended by a RIMU to add transaction identifiers (CID, Secure bit, Privilege bit).
To simplify the programming model, some inheritance and consistency checks have been implemented between the RISUP and the RIMU associated with a master peripheral:
- CID inheritance: master peripheral takes the CID of the processor controlling it.
- Secure bit consistency: master secure bit can be set only if it is controlled by a secure processor execution context.
2.6. Relationship between RIF and RCC[edit | edit source]
RCC is a RIF-aware peripheral. That means RCC is integrating some RIF RISUP to protect access to its different features. RCC offers reset and clock control for all the different peripherals present in the device.
To ease programming consistency between RIFSC and RCC RIF protection, a hardware inheritance between peripheral RISUP and RCC peripheral configuration register. That means only the execution context owning the peripheral can control associated clocks and reset.
This inheritance is not implemented for RIF-aware and system peripherals, which are used simultaneously by different execution contexts. Indeed, RCC supports peripheral auto clock gating according to the peripheral owner low power state. As soon as a processor enters (LP/LPLV)Stop low power mode, all peripherals (secure and nonsecure) owned by this processor are automatically clock gated. This feature is not valid for RIF-aware and system peripherals, and RCC implements a specific owning mechanism to link clock gating on state of the system instead of state of one processor.
2.7. RIFSC and RIF-aware RISUP properties[edit | edit source]
The following table summarizes the features implemented by RISUP in RIFSC and RIF-aware peripherals.
| RIF component | Max static CID | Semaphore CID filtering | RIF configuration lock |
|---|---|---|---|
| RIFSC RISUP | 7 | 
|
|
| EXTI | 7 | 
|
|
| FMC | 7 |
|
|
| HPDMA | 3 |
|
|
| IPCC | 2 |
|
|
| PWR | 7 |
|
|
| PWR wake-up pins | 7 |
|
|
| RCC | 7 |
|
|
| RTC | 7 |
|
|
2.8. RIF and low power modes[edit | edit source]
The following table summarizes which parts of the RIF configuration are preserved in the different low power modes.
| RIF component | Run(1/2) | (LP/LPLV)Stop(1/2) | Standby(1/2) |
|---|---|---|---|
| RIFSC | Preserved | Preserved | Preserved |
| RISAB | Preserved | Preserved | Lost |
| RISAF | Preserved | Preserved | Lost |
| RIF-aware peripherals | Preserved | Preserved | Lost |
2.9. RIF and debug[edit | edit source]
Thanks to RIF, it is possible to force JTAG DAP access rights according to the selected debug profile. The following table summarizes the possible configurations:
| Debug profile | Cortex-A debug | Cortex-M debug | DAP access |
|---|---|---|---|
| Microcontroller debug | No debug | Secure | Same as Cortex-M |
| Nonsecure | |||
| Microprocessor debug | Secure | No debug | Same a Cortex-A |
| Nonsecure | |||
| Global debug | Secure | Same as Cortex-M or same as Cortex-A or DDCID | |
| Nonsecure | |||
Setting DAP master CID to DDCID allows access to any platform resources via the DAP interface, regardless of their associated RIF rules configuration. This allows debugging the platform without modifying RIF configuration.
Of course, the secure and privilege level of the DAP interface could also be configured.
3. How to configure RIF[edit | edit source]
RIF configuration depends on several criteria:
- The RIF integration in the platform
- The execution contexts present in the platform
- The software components under execution in the different contexts
For STM32MP2 series, refer to STM32MP2 firewall configuration