1. Article purpose[edit source]
The purpose of this article is to:
- briefly introduce the 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 source]
The Resource Isolation Framework (aka RIF) is a fully integrated firewall solution, isolating execution contexts from each other. It allows to protect access to:
- Internal memories
- External memories
- Internal peripherals
- Peripheral features when a peripheral is providing multiple features that could be assigned to different execution contexts
and from:
- any bus master peripherals
2.1. Some key definitions[edit source]
It is important to define 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 to configure critical secure and system resources. It is the boot processor part of the trusted boot. Value is fixed after ROM code execution.
- DDCID = Debug Domain CID: It is dedicated CID value, assignable only to DAP interface which provide open access to any resource via Jtag interface to ease platform debug. This configuration is only possible when device is in "CLOSED_UNSECURED" state and debug opened by TDCID secure OS during platform boot.
2.2. RIF concept[edit source]
RIF could be seen as an extension of the bus interconnect, adding information at each transaction to identify emitter and being to able to filter transaction in parallel of address decoding.
To do that, a Compartment Identifier (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 on the different resources of the device.
2.3. RIF composition[edit source]
RIF is made up of different elements:
- RIMU = Resource Isolation Master Unit: They are located in front of each bus master port to make transaction unique.
- RISUP = Resource Isolation Slave Unit Peripheral: They are located in front of each slave bus connector to filter transaction according to defined rules.
- RISAL = Resource Isolation Save Address Light: Located in front of low power internal memories to filter access based on variable sized address space regions.
- RIFSC= RIF Security Controller: Provide configuration registers for all RIMU, RISUP and RISAL. Configuration is persistent in low power modes.
- RISAF= Resource Isolation Save Address Full: 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 Save Address Block: 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 can't directly rely on this infrastructure because isolation granularity is not at peripheral level but feature one. For example RTC is offering secure time but also several alarms. It should be possible to assign each RTC feature to a specific execution context. To do that, 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. Master peripherals RIF protection[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 programming model, some inheritance and consistency checks have been implemented between the RISUP and the RIMU associated to 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.5. Relationship between RIF and RCC[edit source]
RCC is a RIF-aware peripheral. That means RCC is integrating some RIF RISUP to protect access to its different features. RCC is offering reset and clock control for all the different peripherals present in the device. To ease programming consistency between RIFSC and RCC RIF protection, a HW inheritance between peripheral RISUP and RCC peripheral configuration register. That means only 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 at the same time by different execution contexts. Indeed, RCC supports peripheral auto clock gating according as soon as peripheral owner is entering in (LP/LPLV)Stop low power mode. 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.6. RIF and low power modes[edit source]
The following table sums up which part of RIF configuration is 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 |
3. Peripheral usage[edit source]
4. Software frameworks and drivers[edit source]
Below are listed the software frameworks and drivers managing the CRC peripheral for the embedded software components listed in the above tables.
- Linux®: crypto framework
- STM32Cube: CRC HAL driver and header file of CRC HAL module