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