Merge "docs(threat model): add Threat Model for RMM" into integration

docs/index.rst

@@ -35,6 +35,13 @@ Realm Management Monitor Documentation
             </a>
             <p>Design documentation for RMM.</p>
         </li>
+        <li class="grid-item">
+            <a href="security/index.html">
+               <img alt="" src="_static/images/rmm-documentation.png"/>
+               <h2>Security</h2>
+            </a>
+            <p>Security.</p>
+        </li>
     </ul>
 
 .. toctree::
@@ -46,4 +53,5 @@ Realm Management Monitor Documentation
    getting_started/index
    process/index
    design/index
+   security/index
    glossary

docs/security/index.rst

@@ -0,0 +1,11 @@
+.. SPDX-License-Identifier: BSD-3-Clause
+.. SPDX-FileCopyrightText: Copyright TF-RMM Contributors.
+
+Security
+========
+.. toctree::
+    :maxdepth: 1
+    :caption: Contents
+    :numbered:
+
+    threat_model/index

docs/security/threat_model/dfd.rst

@@ -0,0 +1,90 @@
+.. SPDX-License-Identifier: BSD-3-Clause
+.. SPDX-FileCopyrightText: Copyright TF-RMM Contributors.
+
+Data Flow Diagram
+=================
+
+This section describes the Data Flow Diagram for RMM.
+
+********************
+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.
+
+*****************
+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:: Table 1: RMM Data Flow Diagram Description
+
+  +-----------------+--------------------------------------------------------+
+  | Diagram Element | Description                                            |
+  +=================+========================================================+
+  |       DF1       | | 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.   |
+  +-----------------+--------------------------------------------------------+
+  |       DF2       | | RMM log system framework outputs debug messages      |
+  |                 |   over a UART interface.                               |
+  +-----------------+--------------------------------------------------------+
+  |       DF3       | | Debug and trace IP on a platform can allow access    |
+  |                 |   to registers and memory of RMM.                      |
+  +-----------------+--------------------------------------------------------+
+  |       DF4       | | Interface for RMM-EL3 communication as per documented|
+  |                 |   in `RMM-EL3 Runtime Interface`_. RMM trusts EL3,     |
+  |                 | | which is part of a trusted subsystem.                |
+  +-----------------+--------------------------------------------------------+
+  |       DF5       | | Realm software can interact with RMM to request      |
+  |                 |   services through the RSI (Realm Service Interface).  |
+  |                 | | This also includes the PSCI interface.               |
+  +-----------------+--------------------------------------------------------+
+  |       DF6       | | 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|
+  |                 | | attacks.                                             |
+  +-----------------+--------------------------------------------------------+
+  |       DF7       | | NS Host interacts with RMM by issuing SMCs that are  |
+  |                 |   then forwarded from EL3 Firmware to RMM.             |
+  +-----------------+--------------------------------------------------------+
+  |       DF8       | | 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.                                       |
+  +-----------------+--------------------------------------------------------+
+
+.. |DFD Diagram| image:: ./diagrams/rmm_dfd.drawio.png
+.. _RMM-EL3 Runtime Interface: https://trustedfirmware-a.readthedocs.io/en/latest/components/rmm-el3-comms-spec.html#rmm-el3-runtime-interface

docs/security/threat_model/index.rst

@@ -0,0 +1,13 @@
+.. SPDX-License-Identifier: BSD-3-Clause
+.. SPDX-FileCopyrightText: Copyright TF-RMM Contributors.
+
+Threat Model
+============
+.. toctree::
+    :maxdepth: 1
+    :caption: Contents
+
+    introduction
+    dfd
+    threat_analysis
+    threat_assessment

docs/security/threat_model/introduction.rst

@@ -0,0 +1,14 @@
+.. SPDX-License-Identifier: BSD-3-Clause
+.. SPDX-FileCopyrightText: Copyright TF-RMM Contributors.
+
+Introduction
+============
+
+Threat modeling is an important part of Secure Development Lifecycle (SDL)
+that helps us identify potential threats and mitigations affecting a system.
+
+In the next sections, we present the Threat Model for RMM, giving first a
+description of the target of evaluation using a data flow diagram.
+Then we provide a list of threats that we have identified based on the
+data flow diagram and potential threat mitigations.
+

docs/security/threat_model/threat_analysis.rst

@@ -0,0 +1,193 @@
+.. SPDX-License-Identifier: BSD-3-Clause
+.. SPDX-FileCopyrightText: Copyright TF-RMM Contributors.
+
+Threat Analysis components
+==========================
+
+In this section we identify all the possible *actors* involved in the Threat
+Model.
+
+For each threat, we will identify the *asset* that is under threat, the
+*threat agent* and the *threat type*. Each threat will be given a *risk rating*
+that represents the impact and likelihood of that threat.
+
+Any threat which needs to be mitigated by the RME hardware as well as by EL3 Root
+code is out of the scope of this Threat Model.
+
+******
+Assets
+******
+
+We have identified the following assets for RMM:
+
+.. table:: Table 2: RMM Assets
+
+  +--------------------+---------------------------------------------------+
+  | Asset              | Description                                       |
+  +====================+===================================================+
+  | Sensitive Data     | | These include sensitive RMM and Realm data that |
+  |                    |   an attacker must not be able to tamper with.    |
+  |                    | | Also, RMM should protect the confidentiality of |
+  |                    |   of such data.                                   |
+  +--------------------+---------------------------------------------------+
+  | Code Execution     | | This represents the requirement that Realms     |
+  |                    |   should only run code in R-EL1/EL0 that is       |
+  |                    | | allowed by the RMM ABI. The Realm code execution|
+  |                    |   cannot be hijacked by an attacker.              |
+  |                    | | This also represents the requirement that RMM   |
+  |                    |   should protect itself from privilege escalation |
+  |                    | | and code injection by an attacker into R-EL2.   |
+  |                    |   The RMM execution cannot be hijacked by an      |
+  |                    | | attacker through the use of the RMM ABI.        |
+  +--------------------+---------------------------------------------------+
+  | Availability       | | Availability of Realm world is out of scope for |
+  |                    |   this Threat Model. However, RMM should be       |
+  |                    | | designed in such a way that neither Realm nor   |
+  |                    |   RMM should significantly affect the availability|
+  |                    | | of NS Host and Secure World.                    |
+  +--------------------+---------------------------------------------------+
+
+*************
+Threat Agents
+*************
+
+To understand the attack surface, it is important to identify potential
+attackers, i.e. attack entry points. The following threat agents are
+in scope of this threat model.
+
+.. table:: Table 3: Threat Agents
+
+  +-------------------+-------------------------------------------------------+
+  | Threat Agent      | Description                                           |
+  +===================+=======================================================+
+  |   RealmCode       | | Malicious or faulty code running in the Realm       |
+  |                   |   world, including R-EL0 and R-EL1 levels.            |
+  +-------------------+-------------------------------------------------------+
+  |   HostSoftware    | | Malicious or faulty code running in the Secure or   |
+  |                   |   Non-Secure world, EL0 and EL1 levels.               |
+  +-------------------+-------------------------------------------------------+
+  |   AppDebug        | | Physical adversary using debug build of RMM or      |
+  |                   |   access to debug sources of the system.              |
+  +-------------------+-------------------------------------------------------+
+
+There is also a number of Threat Agents which are not covered by this Threat
+Model. These are listed in the table below.
+
+.. table:: Table 4: Threat Agents not covered by this Threat Model
+
+  +-------------------+-------------------------------------------------------+
+  | Threat Agent      | Description                                           |
+  +===================+=======================================================+
+  |   RootCode        | | Malicious or faulty code running at Root Level      |
+  |                   |   (e.g. EL3 Firmware). Since RootCode is part of TCB  |
+  |                   | | of the system, any fault in Root code is usually a  |
+  |                   |   critical vulnerability and not easily mitigated by  |
+  |                   | | RMM. This Threat is considered out-of-scope of      |
+  |                   |   analysis.                                           |
+  +-------------------+-------------------------------------------------------+
+  |  PhysicalAccess   | | Physical adversary having access to external device |
+  |                   |   communication bus and to external flash             |
+  |                   | | communication bus using common hardware.            |
+  |                   |                                                       |
+  |                   | | An advanced physical atacker that has the capability|
+  |                   |   to tamper with hardware (e.g. "rewiring" a chip     |
+  |                   | | using a focused ion beam -FIB- workstation or       |
+  |                   |   decapsulate the chip using chemicals).              |
+  +-------------------+-------------------------------------------------------+
+
+************
+Threat Types
+************
+
+In this threat model we categorize threats using the `STRIDE threat
+analysis technique`_. In this technique a threat is categorized as one
+or more of these types: ``Spoofing``, ``Tampering``, ``Repudiation``,
+``Information disclosure``, ``Denial of service`` or
+``Elevation of privilege``.
+
+*******************
+Threat Risk Ratings
+*******************
+
+For each threat identified, a risk rating that ranges
+from *informational* to *critical* is given based on the likelihood of the
+threat occurring if a mitigation is not in place, and the impact of the
+threat (i.e. how severe the consequences could be). Table 4 explains each
+rating in terms of score, impact and likelihood.
+
+.. table:: Table 4: Rating and score as applied to impact and likelihood
+
+  +-----------------------+-------------------------+---------------------------+
+  | **Rating (Score)**    | **Impact**              | **Likelihood**            |
+  +=======================+=========================+===========================+
+  | Critical (5)          | | Extreme impact to     | | Threat is almost        |
+  |                       |   entire organization   |   certain to be exploited.|
+  |                       |   if exploited.         |                           |
+  |                       |                         | | Knowledge of the threat |
+  |                       |                         |   and how to exploit it   |
+  |                       |                         |   are in the public       |
+  |                       |                         |   domain.                 |
+  +-----------------------+-------------------------+---------------------------+
+  | High (4)              | | Major impact to entire| | Threat is relatively    |
+  |                       |   organization or single|   easy to detect and      |
+  |                       |   line of business if   |   exploit by an attacker  |
+  |                       |   exploited             |   with little skill.      |
+  +-----------------------+-------------------------+---------------------------+
+  | Medium (3)            | | Noticeable impact to  | | A knowledgeable insider |
+  |                       |   line of business if   |   or expert attacker could|
+  |                       |   exploited.            |   exploit the threat      |
+  |                       |                         | | without much difficulty.|
+  +-----------------------+-------------------------+---------------------------+
+  | Low (2)               | | Minor damage if       | | Exploiting the threat   |
+  |                       |   exploited or could    |   would require           |
+  |                       |   be used in conjunction| | considerable expertise  |
+  |                       |   with other            |   and resources           |
+  |                       | | vulnerabilities to    |                           |
+  |                       |   perform a more serious|                           |
+  |                       |   attack                |                           |
+  +-----------------------+-------------------------+---------------------------+
+  | Informational (1)     | | Poor programming      | | Threat is not likely    |
+  |                       |   practice or poor      |   to be exploited on its  |
+  |                       |   design decision that  |   own, but may be used to |
+  |                       |   may not represent an  | | gain information for    |
+  |                       | | immediate risk on its |   launching another       |
+  |                       |   own, but may have     |   attack                  |
+  |                       |   security implications |                           |
+  |                       |   if multiplied and/or  |                           |
+  |                       | | combined with other   |                           |
+  |                       |   threats.              |                           |
+  +-----------------------+-------------------------+---------------------------+
+
+Aggregate risk scores are assigned to identified threats.
+Specifically, the impact score multiplied by the likelihood score.
+For example, a threat with high likelihood and low impact would have an
+aggregate risk score of eight (8); that is, four (4) for high likelihood
+multiplied by two (2) for low impact. The aggregate risk score determines
+the finding's overall risk level, as shown in the following table.
+
+.. table:: Table 5: Overall risk levels and corresponding aggregate scores
+
+  +---------------------+-----------------------------------+
+  | Overall Risk Level  | Aggregate Risk Score              |
+  |                     | (Impact multiplied by Likelihood) |
+  +=====================+===================================+
+  | Critical            | 20–25                             |
+  +---------------------+-----------------------------------+
+  | High                | 12–19                             |
+  +---------------------+-----------------------------------+
+  | Medium              | 6–11                              |
+  +---------------------+-----------------------------------+
+  | Low                 | 2–5                               |
+  +---------------------+-----------------------------------+
+  | Informational       | 1                                 |
+  +---------------------+-----------------------------------+
+
+The likelihood and impact of a threat depends on the
+target environment in which RMM is running. For example, attacks
+that require physical access are unlikely in server environments while
+they are more common in Internet of Things (IoT) environments.
+In this threat model we only consider ``Server`` target environments.
+
+--------------
+
+.. _STRIDE threat analysis technique: https://docs.microsoft.com/en-us/azure/security/develop/threat-modeling-tool-threats#stride-model