1.2. Data Flow Diagram

This section describes the Data Flow Diagram for RMM.

1.2.1. Target of Evaluation

In this threat model, the target of evaluation is the Realm Management Monitor (RMM) in a system context for an Arm A-Class CPU with Realm Management Extension, as shown on Figure 1. Everything else on Figure 1 is outside of the scope of the evaluation.

RMM can be configured in various ways. In this threat model we consider only the most basic configuration. To that end we make the following assumptions:

  • RMM image is run from either ROM, on-chip trusted SRAM or off-chip DRAM. Any memory shared with EL3 Firmware is located inside on-chip trusted SRAM. If RMM runs from off-chip DRAM, then RMM is vulnerable to DRAM attacks (such as rowhammer) and attacks which can probe and tamper off-chip memory.

  • No experimental features are enabled. We do not consider threats that may come from them.

  • RME hardware threats and threats covered by the RMM ABI will be covered in a dedicated Security Risk Analysis document (to be published in the future). Although there is some overlap with threats mitigated by RME hardware and RMM ABI, this threat model focuses on covering threats specific to the RMM implementation and associated data flows.

1.2.2. Data Flow Diagram

Figure 1 shows a high-level data flow diagram for RMM. The diagram shows a model of the different components of a RMM system and their interactions with other FW/SW components. A description of each diagram element is given in Table 1. In the diagram, the red broken lines indicate trust boundaries. Components outside of the broken lines are considered untrusted by RMM. Components inside the broken lines must be trusted by RMM, as they provide security foundations for its functionality.

DFD Diagram

Table 1: RMM Data Flow Diagram Description

Diagram Element



At boot time, EL3 Firmware configures RMM through parameters stored in registers x0 to x3. It also
passes a Boot Manifest using secure shared memory.


RMM log system framework outputs debug messages over a UART interface.


Debug and trace IP on a platform can allow access to registers and memory of RMM.


Interface for RMM-EL3 communication as per documented in RMM-EL3 Runtime Interface. RMM trusts EL3,
which is part of a trusted subsystem.


Realm software can interact with RMM to request services through the RSI (Realm Service Interface).
This also includes the PSCI interface.


Regardless of the type of memory from where RMM is executed, off-chip dynamic RAM (considered
Non-Secure) may be used to store large data structures. This memory might be subject to different


NS Host interacts with RMM by issuing SMCs that are then forwarded from EL3 Firmware to RMM.


This path represents the interaction between RMM and various hardware IPs such as MMU controller and GIC.
At boot time, RMM configures/initializes the IPs and interacts with them at runtime through interrupts
and registers.