Merge "docs(threat model): add TF-A threat model" into integration
diff --git a/docs/_static/css/custom.css b/docs/_static/css/custom.css
new file mode 100644
index 0000000..f6f5fa0
--- /dev/null
+++ b/docs/_static/css/custom.css
@@ -0,0 +1,15 @@
+/*
+ * Copyright (c) 2021, Arm Limited. All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+/*
+ * Set the white-space property of tables to normal.
+ * With this setting sequences of whitespace inside
+ * a table will collapse into a single whitespace,
+ * and text will wrap when necessary.
+ */
+.wy-table-responsive table td {
+white-space: normal;
+}
diff --git a/docs/conf.py b/docs/conf.py
index a100241..356be99 100644
--- a/docs/conf.py
+++ b/docs/conf.py
@@ -1,6 +1,6 @@
# -*- coding: utf-8 -*-
#
-# Copyright (c) 2019, Arm Limited. All rights reserved.
+# Copyright (c) 2019-2021, Arm Limited. All rights reserved.
#
# SPDX-License-Identifier: BSD-3-Clause
#
@@ -76,6 +76,14 @@
'style_external_links': True # Display an icon next to external links
}
+# Path to _static directory
+html_static_path = ['_static']
+
+# Path to css file relative to html_static_path
+html_css_files = [
+ 'css/custom.css',
+]
+
# -- Options for autosectionlabel --------------------------------------------
# Only generate automatic section labels for document titles
diff --git a/docs/index.rst b/docs/index.rst
index cb53127..3760855 100644
--- a/docs/index.rst
+++ b/docs/index.rst
@@ -15,6 +15,7 @@
perf/index
security_advisories/index
design_documents/index
+ threat_model/index
change-log
change-log-upcoming
glossary
@@ -83,7 +84,7 @@
--------------
-*Copyright (c) 2013-2020, Arm Limited and Contributors. All rights reserved.*
+*Copyright (c) 2013-2021, Arm Limited and Contributors. All rights reserved.*
.. _Armv7-A and Armv8-A: https://developer.arm.com/products/architecture/a-profile
.. _Secure Monitor: http://www.arm.com/products/processors/technologies/trustzone/tee-smc.php
diff --git a/docs/resources/diagrams/plantuml/tfa_dfd.puml b/docs/resources/diagrams/plantuml/tfa_dfd.puml
new file mode 100644
index 0000000..0007911
--- /dev/null
+++ b/docs/resources/diagrams/plantuml/tfa_dfd.puml
@@ -0,0 +1,66 @@
+/'
+ ' Copyright (c) 2021, Arm Limited. All rights reserved.
+ '
+ ' SPDX-License-Identifier: BSD-3-Clause
+ '/
+
+/'
+TF-A Data Flow Diagram
+'/
+
+@startuml
+digraph tfa_dfd {
+
+ # Arrange nodes from left to right
+ rankdir="LR"
+
+ # Allow arrows to end on cluster boundaries
+ compound=true
+
+ # Default settings for edges and nodes
+ edge [minlen=2 color="#8c1b07"]
+ node [fillcolor="#ffb866" style=filled shape=box fixedsize=true width=1.6 height=0.7]
+
+ # Nodes outside of the trust boundary
+ nsec [label="Non-secure\nClients"]
+ sec [label="Secure\nClients"]
+ dbg [label="Debug & Trace"]
+ logs [label="Logs\n(UART)"]
+ nvm [label="Non-volatile\nMemory"]
+
+ # Trust boundary cluster
+ subgraph cluster_trusted{
+ graph [style=dashed color="#f22430"]
+
+ # HW IPs cluster
+ subgraph cluster_ip{
+ label ="Hardware IPs";
+ graph [style=filled color="#000000" fillcolor="#ffd29e"]
+
+ rank="same"
+ gic [label="GIC" width=1.2 height=0.5]
+ tzc [label="TZ\nController" width=1.2 height=0.5]
+ etc [label="..." shape=none style=none height=0.5]
+ }
+
+ # TF-A cluster
+ subgraph cluster_tfa{
+ label ="TF-A";
+ graph [style=filled color="#000000" fillcolor="#faf9cd"]
+
+ bl1 [label="Boot ROM\n(BL1)" fillcolor="#ddffb3"];
+ bl2 [label="Trusted Boot\nFirmware\n(BL2)" fillcolor="#ddffb3" height=1]
+ bl31 [label="TF-A Runtime\n(BL31)" fillcolor="#ddffb3"]
+ }
+ }
+
+ # Interactions between nodes
+ nvm -> bl31 [lhead=cluster_tfa label="DF1"]
+ logs -> bl31 [dir="back" lhead=cluster_tfa label="DF2"]
+ dbg -> bl2 [dir="both" lhead=cluster_tfa label="DF3"]
+ sec -> bl2 [dir="both" lhead=cluster_tfa label="DF4"]
+ nsec -> bl1 [dir="both" lhead=cluster_tfa, label="DF5"]
+ bl2 -> tzc [dir="both" ltail=cluster_tfa lhead=cluster_ip label="DF6" minlen=1]
+}
+
+@enduml
diff --git a/docs/threat_model/index.rst b/docs/threat_model/index.rst
new file mode 100644
index 0000000..e8f09b9
--- /dev/null
+++ b/docs/threat_model/index.rst
@@ -0,0 +1,13 @@
+Threat Model
+=============
+
+.. toctree::
+ :maxdepth: 1
+ :caption: Contents
+ :numbered:
+
+ threat_model
+
+--------------
+
+*Copyright (c) 2021, Arm Limited and Contributors. All rights reserved.*
diff --git a/docs/threat_model/threat_model.rst b/docs/threat_model/threat_model.rst
new file mode 100644
index 0000000..9cee104
--- /dev/null
+++ b/docs/threat_model/threat_model.rst
@@ -0,0 +1,784 @@
+*****************
+Introduction
+*****************
+Threat modeling is an important part of Secure Development Lifecycle (SDL)
+that helps us identify potential threats and mitigations affecting a system.
+
+This document provides a generic threat model for TF-A firmware. In the
+next sections, we first give a description of the target of evaluation
+using a data flow diagram. Then we provide a list of threats we have
+identified based on the data flow diagram and potential threat mitigations.
+
+************************
+Target of Evaluation
+************************
+In this threat model, the target of evaluation is the Trusted
+Firmware for A-class Processors (TF-A). This includes the boot ROM (BL1),
+the trusted boot firmware (BL2) and the runtime EL3 firmware (BL31) as
+shown on Figure 1. Everything else on Figure 1 is outside of the scope of
+the evaluation.
+
+TF-A 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:
+
+- All TF-A images are run from either ROM or on-chip trusted SRAM. This means
+ TF-A is not vulnerable to an attacker that can probe or tamper with off-chip
+ memory.
+- Trusted boot is enabled. This means an attacker can't boot arbitrary images
+ that are not approved by platform providers.
+- There is no Secure-EL2. We don't consider threats that may come with
+ Secure-EL2 software.
+
+Data Flow Diagram
+======================
+Figure 1 shows a high-level data flow diagram for TF-A. The diagram
+shows a model of the different components of a TF-A-based system and
+their interactions with TF-A. A description of each diagram element
+is given on Table 1. On the diagram, the red broken lines indicate
+trust boundaries. Components outside of the broken lines
+are considered untrusted by TF-A.
+
+.. uml:: ../resources/diagrams/plantuml/tfa_dfd.puml
+ :caption: Figure 1: TF-A Data Flow Diagram
+
+.. table:: Table 1: TF-A Data Flow Diagram Description
+
+ +-----------------+--------------------------------------------------------+
+ | Diagram Element | Description |
+ +=================+========================================================+
+ | ``DF1`` | | At boot time, images are loaded from non-volatile |
+ | | memory and verified by TF-A boot firmware. These |
+ | | images include TF-A BL2 and BL31 images, as well as |
+ | | other secure and non-secure images. |
+ +-----------------+--------------------------------------------------------+
+ | ``DF2`` | | TF-A 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 TF-A. |
+ +-----------------+--------------------------------------------------------+
+ | ``DF4`` | | Secure world software (e.g. trusted OS) interact |
+ | | with TF-A through SMC call interface and/or shared |
+ | | memory. |
+ +-----------------+--------------------------------------------------------+
+ | ``DF5`` | | Non-secure world software (e.g. rich OS) interact |
+ | | with TF-A through SMC call interface and/or shared |
+ | | memory. |
+ +-----------------+--------------------------------------------------------+
+ | ``DF6`` | | This path represents the interaction between TF-A and|
+ | | various hardware IPs such as TrustZone controller |
+ | | and GIC. At boot time TF-A configures/initializes the|
+ | | IPs and interacts with them at runtime through |
+ | | interrupts and registers. |
+ +-----------------+--------------------------------------------------------+
+
+
+*********************
+Threat Analysis
+*********************
+In this section we identify and provide assessment of potential threats to TF-A
+firmware. The threats are identified for each diagram element on the
+data flow diagram above.
+
+For each threat, we identify the *asset* that is under threat, the
+*threat agent* and the *threat type*. Each threat is given a *risk rating*
+that represents the impact and likelihood of that threat. We also discuss
+potential mitigations.
+
+Assets
+==================
+We have identified the following assets for TF-A:
+
+.. table:: Table 2: TF-A Assets
+
+ +--------------------+---------------------------------------------------+
+ | Asset | Description |
+ +====================+===================================================+
+ | ``Sensitive Data`` | | These include sensitive data that an attacker |
+ | | must not be able to tamper with (e.g. the Root |
+ | | of Trust Public Key) or see (e.g. secure logs, |
+ | | debugging information such as crash reports). |
+ +--------------------+---------------------------------------------------+
+ | ``Code Execution`` | | This represents the requirement that the |
+ | | platform should run only TF-A code approved by |
+ | | the platform provider. |
+ +--------------------+---------------------------------------------------+
+ | ``Availability`` | | This represents the requirement that TF-A |
+ | | services should always be available for use. |
+ +--------------------+---------------------------------------------------+
+
+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 |
+ +===================+=======================================================+
+ | ``NSCode`` | | Malicious or faulty code running in the Non-secure |
+ | | world, including NS-EL0 NS-EL1 and NS-EL2 levels |
+ +-------------------+-------------------------------------------------------+
+ | ``SecCode`` | | Malicious or faulty code running in the secure |
+ | | world, including S-EL0 and S-EL1 levels |
+ +-------------------+-------------------------------------------------------+
+ | ``AppDebug`` | | Physical attacker using debug signals to access |
+ | | TF-A resources |
+ +-------------------+-------------------------------------------------------+
+ | ``PhysicalAccess``| | Physical attacker having access to external device |
+ | | communication bus and to external flash |
+ | | communication bus using common hardware |
+ +-------------------+-------------------------------------------------------+
+
+.. note::
+
+ In this threat model an advanced physical attacker that has the capability
+ to tamper with a hardware (e.g. "rewiring" a chip using a focused
+ ion beam (FIB) workstation or decapsulate the chip using chemicals) is
+ considered out-of-scope.
+
+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 occuring 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 TF-A 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 consider three target environments:
+``Internet of Things(IoT)``, ``Mobile`` and ``Server``.
+
+Threat Assessment
+============================
+The following threats were identified by applying STRIDE analysis on
+each diagram element of the data flow diagram.
+
++------------------------+----------------------------------------------------+
+| ID | 01 |
++========================+====================================================+
+| ``Threat`` | | **An attacker can mangle firmware images to |
+| | execute arbitrary code** |
+| | |
+| | | Some TF-A images are loaded from external |
+| | storage. It is possible for an attacker to access|
+| | the external flash memory and change its contents|
+| | physically, through the Rich OS, or using the |
+| | updating mechanism to modify the non-volatile |
+| | images to execute arbitrary code. |
++------------------------+----------------------------------------------------+
+| ``Diagram Elements`` | DF1, DF4, DF5 |
++------------------------+----------------------------------------------------+
+| ``Affected TF-A | BL2, BL31 |
+| Components`` | |
++------------------------+----------------------------------------------------+
+| ``Assets`` | Code Execution |
++------------------------+----------------------------------------------------+
+| ``Threat Agent`` | PhysicalAccess, NSCode, SecCode |
++------------------------+----------------------------------------------------+
+| ``Threat Type`` | Tampering, Elevation of Privilege |
++------------------------+------------------+-----------------+---------------+
+| ``Application`` | ``Server`` | ``IoT`` | ``Mobile`` |
++------------------------+------------------+-----------------+---------------+
+| ``Impact`` | Critical (5) | Critical (5) | Critical (5) |
++------------------------+------------------+-----------------+---------------+
+| ``Likelihood`` | Critical (5) | Critical (5) | Critical (5) |
++------------------------+------------------+-----------------+---------------+
+| ``Total Risk Rating`` | Critical (25) | Critical (25) | Critical (25) |
++------------------------+------------------+-----------------+---------------+
+| ``Mitigations`` | | TF-A implements the `Trusted Board Boot (TBB)`_ |
+| | feature which prevents malicious firmware from |
+| | running on the platform by authenticating all |
+| | firmware images. In addition to this, the TF-A |
+| | boot firmware performs extra checks on |
+| | unauthenticated data, such as FIP metadata, prior|
+| | to use. |
++------------------------+----------------------------------------------------+
+
++------------------------+----------------------------------------------------+
+| ID | 02 |
++========================+====================================================+
+| ``Threat`` | | **An attacker may attempt to boot outdated, |
+| | potentially vulnerable firmware image** |
+| | |
+| | | When updating firmware, an attacker may attempt |
+| | to rollback to an older version that has unfixed |
+| | vulnerabilities. |
++------------------------+----------------------------------------------------+
+| ``Diagram Elements`` | DF1, DF4, DF5 |
++------------------------+----------------------------------------------------+
+| ``Affected TF-A | BL2, BL31 |
+| Components`` | |
++------------------------+----------------------------------------------------+
+| ``Assets`` | Code Execution |
++------------------------+----------------------------------------------------+
+| ``Threat Agent`` | PhysicalAccess, NSCode, SecCode |
++------------------------+----------------------------------------------------+
+| ``Threat Type`` | Tampering |
++------------------------+------------------+-----------------+---------------+
+| ``Application`` | ``Server`` | ``IoT`` | ``Mobile`` |
++------------------------+------------------+-----------------+---------------+
+| ``Impact`` | Critical (5) | Critical (5) | Critical (5) |
++------------------------+------------------+-----------------+---------------+
+| ``Likelihood`` | Critical (5) | Critical (5) | Critical (5) |
++------------------------+------------------+-----------------+---------------+
+| ``Total Risk Rating`` | Critical (25) | Critical (25) | Critical (25) |
++------------------------+------------------+-----------------+---------------+
+| ``Mitigations`` | | TF-A supports anti-rollback protection using |
+| | non-volatile counters (NV counters) as required |
+| | by `TBBR-Client specification`_. After a firmware|
+| | image is validated, the image revision number |
+| | taken from a certificate extension field is |
+| | compared with the corresponding NV counter stored|
+| | in hardware to make sure the new counter value is|
+| | larger or equal to the current counter value. |
+| | Platforms must implement this protection using |
+| | platform specific hardware NV counters. |
++------------------------+----------------------------------------------------+
+
++------------------------+-------------------------------------------------------+
+| ID | 03 |
++========================+=======================================================+
+| ``Threat`` | | **An attacker can use Time-of-Check-Time-of-Use |
+| | (TOCTOU) attack to bypass image authentication |
+| | during the boot process** |
+| | |
+| | | Time-of-Check-Time-of-Use (TOCTOU) threats occur |
+| | when the security check is produced before the time |
+| | the resource is accessed. If an attacker is sitting |
+| | in the middle of the off-chip images, they could |
+| | change the binary containing executable code right |
+| | after the integrity and authentication check has |
+| | been performed. |
++------------------------+-------------------------------------------------------+
+| ``Diagram Elements`` | DF1 |
++------------------------+-------------------------------------------------------+
+| ``Affected TF-A | BL1, BL2 |
+| Components`` | |
++------------------------+-------------------------------------------------------+
+| ``Assets`` | Code Execution, Sensitive Data |
++------------------------+-------------------------------------------------------+
+| ``Threat Agent`` | PhysicalAccess |
++------------------------+-------------------------------------------------------+
+| ``Threat Type`` | Elevation of Privilege |
++------------------------+---------------------+-----------------+---------------+
+| ``Application`` | ``Server`` | ``IoT`` | ``Mobile`` |
++------------------------+---------------------+-----------------+---------------+
+| ``Impact`` | N/A | Critical (5) | Critical (5) |
++------------------------+---------------------+-----------------+---------------+
+| ``Likelihood`` | N/A | Medium (3) | Medium (3) |
++------------------------+---------------------+-----------------+---------------+
+| ``Total Risk Rating`` | N/A | High (15) | High (15) |
++------------------------+---------------------+-----------------+---------------+
+| ``Mitigations`` | | TF-A boot firmware copies image to on-chip |
+| | memory before authenticating an image. |
++------------------------+-------------------------------------------------------+
+
++------------------------+-------------------------------------------------------+
+| ID | 04 |
++========================+=======================================================+
+| ``Threat`` | | **An attacker with physical access can execute |
+| | arbitrary image by bypassing the signature |
+| | verification stage using glitching techniques** |
+| | |
+| | | Glitching (Fault injection) attacks attempt to put |
+| | a hardware into a undefined state by manipulating an|
+| | environmental variable such as power supply. |
+| | |
+| | | TF-A relies on a chain of trust that starts with the|
+| | ROTPK, which is the key stored inside the chip and |
+| | the root of all validation processes. If an attacker|
+| | can break this chain of trust, they could execute |
+| | arbitrary code on the device. This could be |
+| | achieved with physical access to the device by |
+| | attacking the normal execution flow of the |
+| | process using glitching techniques that target |
+| | points where the image is validated against the |
+| | signature. |
++------------------------+-------------------------------------------------------+
+| ``Diagram Elements`` | DF1 |
++------------------------+-------------------------------------------------------+
+| ``Affected TF-A | BL1, BL2 |
+| Components`` | |
++------------------------+-------------------------------------------------------+
+| ``Assets`` | Code Execution |
++------------------------+-------------------------------------------------------+
+| ``Threat Agent`` | PhysicalAccess |
++------------------------+-------------------------------------------------------+
+| ``Threat Type`` | Tampering, Elevation of Privilege |
++------------------------+---------------------+-----------------+---------------+
+| ``Application`` | ``Server`` | ``IoT`` | ``Mobile`` |
++------------------------+---------------------+-----------------+---------------+
+| ``Impact`` | N/A | Critical (5) | Critical (5) |
++------------------------+---------------------+-----------------+---------------+
+| ``Likelihood`` | N/A | Medium (3) | Medium (3) |
++------------------------+---------------------+-----------------+---------------+
+| ``Total Risk Rating`` | N/A | High (15) | High (15) |
++------------------------+---------------------+-----------------+---------------+
+| ``Mitigations`` | | The most effective mitigation is adding glitching |
+| | detection and mitigation circuit at the hardware |
+| | level. However, software techniques, |
+| | such as adding redundant checks when performing |
+| | conditional branches that are security sensitive, |
+| | can be used to harden TF-A against such attacks. |
+| | **At the moment TF-A doesn't implement such |
+| | mitigations.** |
++------------------------+-------------------------------------------------------+
+
++------------------------+---------------------------------------------------+
+| ID | 05 |
++========================+===================================================+
+| ``Threat`` | | **Information leak via UART logs such as |
+| | crashes** |
+| | |
+| | | During the development stages of software it is |
+| | common to include crash reports with detailed |
+| | information of the CPU state including current |
+| | values of the registers, privilege level and |
+| | stack dumps. This information is useful when |
+| | debugging problems before releasing the |
+| | production version, but it could be used by an |
+| | attacker to develop a working exploit if left |
+| | in the production version. |
++------------------------+---------------------------------------------------+
+| ``Diagram Elements`` | DF2 |
++------------------------+---------------------------------------------------+
+| ``Affected TF-A | BL1, BL2, BL31 |
+| Components`` | |
++------------------------+---------------------------------------------------+
+| ``Assets`` | Sensitive Data |
++------------------------+---------------------------------------------------+
+| ``Threat Agent`` | AppDebug |
++------------------------+---------------------------------------------------+
+| ``Threat Type`` | Information Disclosure |
++------------------------+------------------+----------------+---------------+
+| ``Application`` | ``Server`` | ``IoT`` | ``Mobile`` |
++------------------------+------------------+----------------+---------------+
+| ``Impact`` | N/A | Low (2) | Low (2) |
++------------------------+------------------+----------------+---------------+
+| ``Likelihood`` | N/A | High (4) | High (4) |
++------------------------+------------------+----------------+---------------+
+| ``Total Risk Rating`` | N/A | Medium (8) | Medium (8) |
++------------------------+------------------+----------------+---------------+
+| ``Mitigations`` | | In TF-A, crash reporting is only enabled for |
+| | debug builds by default. Alternatively, the log |
+| | level can be tuned at build time (from verbose |
+| | to no output at all), independently of the |
+| | build type. |
++------------------------+---------------------------------------------------+
+
++------------------------+----------------------------------------------------+
+| ID | 06 |
++========================+====================================================+
+| ``Threat`` | | **An attacker can read sensitive data and |
+| | execute arbitrary code through the external |
+| | debug and trace interface** |
+| | |
+| | | Arm processors include hardware-assisted debug |
+| | and trace features that can be controlled without|
+| | the need for software operating on the platform. |
+| | If left enabled without authentication, this |
+| | feature can be used by an attacker to inspect and|
+| | modify TF-A registers and memory allowing the |
+| | attacker to read sensitive data and execute |
+| | arbitrary code. |
++------------------------+----------------------------------------------------+
+| ``Diagram Elements`` | DF3 |
++------------------------+----------------------------------------------------+
+| ``Affected TF-A | BL1, BL2, BL31 |
+| Components`` | |
++------------------------+----------------------------------------------------+
+| ``Assets`` | Code Execution, Sensitive Data |
++------------------------+----------------------------------------------------+
+| ``Threat Agent`` | AppDebug |
++------------------------+----------------------------------------------------+
+| ``Threat Type`` | Tampering, Information Disclosure, |
+| | Elevation of privilege |
++------------------------+------------------+---------------+-----------------+
+| ``Application`` | ``Server`` | ``IoT`` | ``Mobile`` |
++------------------------+------------------+---------------+-----------------+
+| ``Impact`` | N/A | High (4) | High (4) |
++------------------------+------------------+---------------+-----------------+
+| ``Likelihood`` | N/A | Critical (5) | Critical (5) |
++------------------------+------------------+---------------+-----------------+
+| ``Total Risk Rating`` | N/A | Critical (20) | Critical (20) |
++------------------------+------------------+---------------+-----------------+
+| ``Mitigations`` | | Configuration of debug and trace capabilities is |
+| | platform specific. Therefore, platforms must |
+| | disable the debug and trace capability for |
+| | production releases or enable proper debug |
+| | authentication as recommended by [`DEN0034`_]. |
++------------------------+----------------------------------------------------+
+
++------------------------+------------------------------------------------------+
+| ID | 07 |
++========================+======================================================+
+| ``Threat`` | | **An attacker can perform a denial-of-service |
+| | attack by using a broken SMC call that causes the |
+| | system to reboot or enter into unknown state.** |
+| | |
+| | | Secure and non-secure clients access TF-A services |
+| | through SMC calls. Malicious code can attempt to |
+| | place the TF-A runtime into an inconsistent state |
+| | by calling unimplemented SMC call or by passing |
+| | invalid arguments. |
++------------------------+------------------------------------------------------+
+| ``Diagram Elements`` | DF4, DF5 |
++------------------------+------------------------------------------------------+
+| ``Affected TF-A | BL31 |
+| Components`` | |
++------------------------+------------------------------------------------------+
+| ``Assets`` | Availability |
++------------------------+------------------------------------------------------+
+| ``Threat Agent`` | NSCode, SecCode |
++------------------------+------------------------------------------------------+
+| ``Threat Type`` | Denial of Service |
++------------------------+-------------------+----------------+-----------------+
+| ``Application`` | ``Server`` | ``IoT`` | ``Mobile`` |
++------------------------+-------------------+----------------+-----------------+
+| ``Impact`` | Medium (3) | Medium (3) | Medium (3) |
++------------------------+-------------------+----------------+-----------------+
+| ``Likelihood`` | High (4) | High (4) | High (4) |
++------------------------+-------------------+----------------+-----------------+
+| ``Total Risk Rating`` | High (12) | High (12) | High (12) |
++------------------------+-------------------+----------------+-----------------+
+| ``Mitigations`` | | The generic TF-A code validates SMC function ids |
+| | and arguments before using them. |
+| | Platforms that implement SiP services must also |
+| | validate SMC call arguments. |
++------------------------+------------------------------------------------------+
+
++------------------------+------------------------------------------------------+
+| ID | 08 |
++========================+======================================================+
+| ``Threat`` | | **Memory corruption due to memory overflows and |
+| | lack of boundary checking when accessing resources |
+| | could allow an attacker to execute arbitrary code, |
+| | modify some state variable to change the normal |
+| | flow of the program, or leak sensitive |
+| | information** |
+| | |
+| | | Like in other software, the Trusted Firmware has |
+| | multiple points where memory corruption security |
+| | errors can arise. Memory corruption is a dangerous |
+| | security issue since it could allow an attacker |
+| | to execute arbitrary code, modify some state |
+| | variable to change the normal flow of the program, |
+| | or leak sensitive information. |
+| | |
+| | | Some of the errors include integer overflow, |
+| | buffer overflow, incorrect array boundary checks, |
+| | and incorrect error management. |
+| | Improper use of asserts instead of proper input |
+| | validations might also result in these kinds of |
+| | errors in release builds. |
++------------------------+------------------------------------------------------+
+| ``Diagram Elements`` | DF4, DF5 |
++------------------------+------------------------------------------------------+
+| ``Affected TF-A | BL1, BL2, BL31 |
+| Components`` | |
++------------------------+------------------------------------------------------+
+| ``Assets`` | Code Execution, Sensitive Data |
++------------------------+------------------------------------------------------+
+| ``Threat Agent`` | NSCode, SecCode |
++------------------------+------------------------------------------------------+
+| ``Threat Type`` | Tampering, Information Disclosure, |
+| | Elevation of Privilege |
++------------------------+-------------------+-----------------+----------------+
+| ``Application`` | ``Server`` | ``IoT`` | ``Mobile`` |
++------------------------+-------------------+-----------------+----------------+
+| ``Impact`` | Critical (5) | Critical (5) | Critical (5) |
++------------------------+-------------------+-----------------+----------------+
+| ``Likelihood`` | Medium (3 | Medium (3) | Medium (3) |
++------------------------+-------------------+-----------------+----------------+
+| ``Total Risk Rating`` | High (15) | High (15) | High (15) |
++------------------------+-------------------+-----------------+----------------+
+| ``Mitigations`` | | TF-A uses a combination of manual code reviews and |
+| | automated program analysis and testing to detect |
+| | and fix memory corruption bugs. All TF-A code |
+| | including platform code go through manual code |
+| | reviews. Additionally, static code analysis is |
+| | performed using Coverity Scan on all TF-A code. |
+| | The code is also tested with |
+| | `Trusted Firmware-A Tests`_ on Juno and FVP |
+| | platforms. |
+| | |
+| | | Data received from normal world, such as addresses |
+| | and sizes identifying memory regions, are |
+| | sanitized before being used. These security checks |
+| | make sure that the normal world software does not |
+| | access memory beyond its limit. |
+| | |
+| | | By default *asserts* are only used to check for |
+| | programming errors in debug builds. Other types of |
+| | errors are handled through condition checks that |
+| | remain enabled in release builds. See |
+| | `TF-A error handling policy`_. TF-A provides an |
+| | option to use *asserts* in release builds, however |
+| | we recommend using proper runtime checks instead |
+| | of relying on asserts in release builds. |
++------------------------+------------------------------------------------------+
+
++------------------------+------------------------------------------------------+
+| ID | 09 |
++========================+======================================================+
+| ``Threat`` | | **Improperly handled SMC calls can leak register |
+| | contents** |
+| | |
+| | | When switching between secure and non-secure |
+| | states, register contents of Secure world or |
+| | register contents of other normal world clients |
+| | can be leaked. |
++------------------------+------------------------------------------------------+
+| ``Diagram Elements`` | DF5 |
++------------------------+------------------------------------------------------+
+| ``Affected TF-A | BL31 |
+| Components`` | |
++------------------------+------------------------------------------------------+
+| ``Assets`` | Sensitive Data |
++------------------------+------------------------------------------------------+
+| ``Threat Agent`` | NSCode |
++------------------------+------------------------------------------------------+
+| ``Threat Type`` | Information Disclosure |
++------------------------+-------------------+----------------+-----------------+
+| ``Application`` | ``Server`` | ``IoT`` | ``Mobile`` |
++------------------------+-------------------+----------------+-----------------+
+| ``Impact`` | Medium (3) | Medium (3) | Medium (3) |
++------------------------+-------------------+----------------+-----------------+
+| ``Likelihood`` | High (4) | High (4) | High (4) |
++------------------------+-------------------+----------------+-----------------+
+| ``Total Risk Rating`` | High (12) | High (12) | High (12) |
++------------------------+-------------------+----------------+-----------------+
+| ``Mitigations`` | | TF-A saves and restores registers |
+| | by default when switching contexts. Build options |
+| | are also provided to save/restore additional |
+| | registers such as floating-point registers. |
++------------------------+------------------------------------------------------+
+
++------------------------+-----------------------------------------------------+
+| ID | 10 |
++========================+=====================================================+
+| ``Threat`` | | **SMC calls can leak sensitive information from |
+| | TF-A memory via microarchitectural side channels**|
+| | |
+| | | Microarchitectural side-channel attacks such as |
+| | `Spectre`_ can be used to leak data across |
+| | security boundaries. An attacker might attempt to |
+| | use this kind of attack to leak sensitive |
+| | data from TF-A memory. |
++------------------------+-----------------------------------------------------+
+| ``Diagram Elements`` | DF4, DF5 |
++------------------------+-----------------------------------------------------+
+| ``Affected TF-A | BL31 |
+| Components`` | |
++------------------------+-----------------------------------------------------+
+| ``Assets`` | Sensitive Data |
++------------------------+-----------------------------------------------------+
+| ``Threat Agent`` | SecCode, NSCode |
++------------------------+-----------------------------------------------------+
+| ``Threat Type`` | Information Disclosure |
++------------------------+-------------------+----------------+----------------+
+| ``Application`` | ``Server`` | ``IoT`` | ``Mobile`` |
++------------------------+-------------------+----------------+----------------+
+| ``Impact`` | Medium (3) | Medium (3) | Medium (3) |
++------------------------+-------------------+----------------+----------------+
+| ``Likelihood`` | Medium (3) | Medium (3) | Medium (3) |
++------------------------+-------------------+----------------+----------------+
+| ``Total Risk Rating`` | Medium (9) | Medium (9) | Medium (9) |
++------------------------+-------------------+----------------+----------------+
+| ``Mitigations`` | | TF-A implements software mitigations for Spectre |
+| | type attacks as recommended by `Cache Speculation |
+| | Side-channels`_ for the generic code. SiPs should |
+| | implement similar mitigations for code that is |
+| | deemed to be vulnerable to such attacks. |
++------------------------+-----------------------------------------------------+
+
++------------------------+----------------------------------------------------+
+| ID | 11 |
++========================+====================================================+
+| ``Threat`` | | **Misconfiguration of the Memory Management Unit |
+| | (MMU) may allow a normal world software to |
+| | access sensitive data or execute arbitrary |
+| | code** |
+| | |
+| | | A misconfiguration of the MMU could |
+| | lead to an open door for software running in the |
+| | normal world to access sensitive data or even |
+| | execute code if the proper security mechanisms |
+| | are not in place. |
++------------------------+----------------------------------------------------+
+| ``Diagram Elements`` | DF5, DF6 |
++------------------------+----------------------------------------------------+
+| ``Affected TF-A | BL1, BL2, BL31 |
+| Components`` | |
++------------------------+----------------------------------------------------+
+| ``Assets`` | Sensitive Data, Code execution |
++------------------------+----------------------------------------------------+
+| ``Threat Agent`` | NSCode |
++------------------------+----------------------------------------------------+
+| ``Threat Type`` | Information Disclosure, Elevation of Privilege |
++------------------------+-----------------+-----------------+----------------+
+| ``Application`` | ``Server`` | ``IoT`` | ``Mobile`` |
++------------------------+-----------------+-----------------+----------------+
+| ``Impact`` | Critical (5) | Critical (5) | Critical (5) |
++------------------------+-----------------+-----------------+----------------+
+| ``Likelihood`` | High (4) | High (4) | High (4) |
++------------------------+-----------------+-----------------+----------------+
+| ``Total Risk Rating`` | Critical (20) | Critical (20) | Critical (20) |
++------------------------+-----------------+-----------------+----------------+
+| ``Mitigations`` | | In TF-A, configuration of the MMU is done |
+| | through a translation tables library. The |
+| | library provides APIs to define memory regions |
+| | and assign attributes including memory types and |
+| | access permissions. Memory configurations are |
+| | platform specific, therefore platforms need make |
+| | sure the correct attributes are assigned to |
+| | memory regions. When assigning access |
+| | permissions, principle of least privilege ought |
+| | to be enforced, i.e. we should not grant more |
+| | privileges than strictly needed, e.g. code |
+| | should be read-only executable, RO data should |
+| | be read-only XN, and so on. |
++------------------------+----------------------------------------------------+
+
++------------------------+-----------------------------------------------------+
+| ID | 12 |
++========================+=====================================================+
+| ``Threat`` | | **Incorrect configuration of Performance Monitor |
+| | Unit (PMU) counters can allow an attacker to |
+| | mount side-channel attacks using information |
+| | exposed by the counters** |
+| | |
+| | | Non-secure software can configure PMU registers |
+| | to count events at any exception level and in |
+| | both Secure and Non-secure states. This allows |
+| | a Non-secure software (or a lower-level Secure |
+| | software) to potentially carry out |
+| | side-channel timing attacks against TF-A. |
++------------------------+-----------------------------------------------------+
+| ``Diagram Elements`` | DF5, DF6 |
++------------------------+-----------------------------------------------------+
+| ``Affected TF-A | BL31 |
+| Components`` | |
++------------------------+-----------------------------------------------------+
+| ``Assets`` | Sensitive Data |
++------------------------+-----------------------------------------------------+
+| ``Threat Agent`` | NSCode |
++------------------------+-----------------------------------------------------+
+| ``Threat Type`` | Information Disclosure |
++------------------------+-------------------+----------------+----------------+
+| ``Impact`` | Medium (3) | Medium (3) | Medium (3) |
++------------------------+-------------------+----------------+----------------+
+| ``Likelihood`` | Low (2) | Low (2) | Low (2) |
++------------------------+-------------------+----------------+----------------+
+| ``Total Risk Rating`` | Medium (6) | Medium (6) | Medium (6) |
++------------------------+-------------------+----------------+----------------+
+| ``Mitigations`` | | TF-A follows mitigation strategies as described |
+| | in `Secure Development Guidelines`_. General |
+| | events and cycle counting in the Secure world is |
+| | prohibited by default when applicable. However, |
+| | on some implementations (e.g. PMUv3) Secure world |
+| | event counting depends on external debug interface|
+| | signals, i.e. Secure world event counting is |
+| | enabled if external debug is enabled. |
+| | Configuration of debug signals is platform |
+| | specific, therefore platforms need to make sure |
+| | that external debug is disabled in production or |
+| | proper debug authentication is in place. |
++------------------------+-----------------------------------------------------+
+
+--------------
+
+*Copyright (c) 2021, Arm Limited. All rights reserved.*
+
+
+.. _STRIDE threat analysis technique: https://docs.microsoft.com/en-us/azure/security/develop/threat-modeling-tool-threats#stride-model
+.. _DEN0034: https://developer.arm.com/documentation/den0034/latest
+.. _Cache Speculation Side-channels: https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability
+.. _Spectre: https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability
+.. _TBBR-Client specification: https://developer.arm.com/documentation/den0006/d/
+.. _Trusted Board Boot (TBB): https://trustedfirmware-a.readthedocs.io/en/latest/design/trusted-board-boot.html
+.. _TF-A error handling policy: https://trustedfirmware-a.readthedocs.io/en/latest/process/coding-guidelines.html#error-handling-and-robustness
+.. _Secure Development Guidelines: https://trustedfirmware-a.readthedocs.io/en/latest/process/security-hardening.html#secure-development-guidelines
+.. _Trusted Firmware-A Tests: https://git.trustedfirmware.org/TF-A/tf-a-tests.git/about/
\ No newline at end of file