docs(threat-model): supply chain threat model TF-A
Software supply chain attacks aim to inject malicious code into a
software product. There are several ways a malicious code can be
injected into a software product (open-source project).
These include:
- Malicious code commits
- Malicious dependencies
- Malicious toolchains
This document provides analysis of software supply chain attack
threats for the TF-A project
Change-Id: I03545d65a38dc372f3868a16c725b7378640a771
Signed-off-by: Lauren Wehrmeister <lauren.wehrmeister@arm.com>
diff --git a/docs/threat_model/firmware_threat_model/index.rst b/docs/threat_model/firmware_threat_model/index.rst
new file mode 100644
index 0000000..05b6710
--- /dev/null
+++ b/docs/threat_model/firmware_threat_model/index.rst
@@ -0,0 +1,41 @@
+TF-A Firmware Threat Model
+==========================
+
+As the TF-A codebase is highly configurable to allow tailoring it best for each
+platform's needs, providing a holistic threat model covering all of its features
+is not necessarily the best approach. Instead, we provide a collection of
+documents which, together, form the project's threat model. These are
+articulated around a core document, called the :ref:`Generic Threat Model`,
+which focuses on the most common configuration we expect to see. The other
+documents typically focus on specific features not covered in the core document.
+
+As the TF-A codebase evolves and new features get added, these threat model
+documents will be updated and extended in parallel to reflect at best the
+current status of the code from a security standpoint.
+
+ .. note::
+
+ Although our aim is eventually to provide threat model material for all
+ features within the project, we have not reached that point yet. We expect
+ to gradually fill these gaps over time.
+
+Each of these documents give a description of the target of evaluation using a
+data flow diagram, as well as a list of threats we have identified using the
+`STRIDE threat modeling technique`_ and corresponding mitigations.
+
+.. toctree::
+ :maxdepth: 1
+ :caption: Contents
+
+ threat_model
+ threat_model_el3_spm
+ threat_model_fvp_r
+ threat_model_rss_interface
+ threat_model_arm_cca
+ threat_model_fw_update_and_recovery
+
+--------------
+
+*Copyright (c) 2021-2024, Arm Limited and Contributors. All rights reserved.*
+
+.. _STRIDE threat modeling technique: https://docs.microsoft.com/en-us/azure/security/develop/threat-modeling-tool-threats#stride-model
diff --git a/docs/threat_model/firmware_threat_model/threat_model.rst b/docs/threat_model/firmware_threat_model/threat_model.rst
new file mode 100644
index 0000000..d93547f
--- /dev/null
+++ b/docs/threat_model/firmware_threat_model/threat_model.rst
@@ -0,0 +1,1106 @@
+Generic Threat Model
+********************
+
+************
+Introduction
+************
+
+This document provides a generic threat model for TF-A firmware.
+
+.. _Target of Evaluation:
+
+********************
+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.
+
+- There are no Root and Realm worlds. These are introduced by :ref:`Realm
+ Management Extension (RME)`.
+
+ The :ref:`Threat Model for TF-A with Arm CCA support` covers these types of
+ configurations.
+
+- No experimental features are enabled. We do not consider threats that may come
+ from them.
+
+- The platform's hardware complies with the `PSR specification`_, defining the
+ bare-minimum security prerequisites for System-on-Chips (SoC).
+
+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 or |
+ | | informative messages over a UART interface. |
+ | | |
+ | | | Also, characters can be read from 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:
+
+***************
+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 occurring if a mitigation is not in place, and the impact of the
+threat (i.e. how severe the consequences could be). Table 4 explains each
+rating in terms of score, impact and likelihood.
+
+.. table:: Table 4: Rating and score as applied to impact and likelihood
+
+ +-----------------------+-------------------------+---------------------------+
+ | **Rating (Score)** | **Impact** | **Likelihood** |
+ +=======================+=========================+===========================+
+ | Critical (5) | | Extreme impact to | | Threat is almost |
+ | | entire organization | certain to be exploited.|
+ | | if exploited. | |
+ | | | | Knowledge of the threat |
+ | | | and how to exploit it |
+ | | | are in the public |
+ | | | domain. |
+ +-----------------------+-------------------------+---------------------------+
+ | High (4) | | Major impact to entire| | Threat is relatively |
+ | | organization or single| easy to detect and |
+ | | line of business if | exploit by an attacker |
+ | | exploited | with little skill. |
+ +-----------------------+-------------------------+---------------------------+
+ | Medium (3) | | Noticeable impact to | | A knowledgeable insider |
+ | | line of business if | or expert attacker could|
+ | | exploited. | exploit the threat |
+ | | | without much difficulty.|
+ +-----------------------+-------------------------+---------------------------+
+ | Low (2) | | Minor damage if | | Exploiting the threat |
+ | | exploited or could | would require |
+ | | be used in conjunction| considerable expertise |
+ | | with other | and resources |
+ | | vulnerabilities to | |
+ | | perform a more serious| |
+ | | attack | |
+ +-----------------------+-------------------------+---------------------------+
+ | Informational (1) | | Poor programming | | Threat is not likely |
+ | | practice or poor | to be exploited on its |
+ | | design decision that | own, but may be used to |
+ | | may not represent an | gain information for |
+ | | immediate risk on its | launching another |
+ | | own, but may have | attack |
+ | | security implications | |
+ | | if multiplied and/or | |
+ | | combined with other | |
+ | | threats. | |
+ +-----------------------+-------------------------+---------------------------+
+
+Aggregate risk scores are assigned to identified threats;
+specifically, the impact score multiplied by the likelihood score.
+For example, a threat with high likelihood and low impact would have an
+aggregate risk score of eight (8); that is, four (4) for high likelihood
+multiplied by two (2) for low impact. The aggregate risk score determines
+the finding's overall risk level, as shown in the following table.
+
+.. table:: Table 5: Overall risk levels and corresponding aggregate scores
+
+ +---------------------+-----------------------------------+
+ | Overall Risk Level | Aggregate Risk Score |
+ | | (Impact multiplied by Likelihood) |
+ +=====================+===================================+
+ | Critical | 20–25 |
+ +---------------------+-----------------------------------+
+ | High | 12–19 |
+ +---------------------+-----------------------------------+
+ | Medium | 6–11 |
+ +---------------------+-----------------------------------+
+ | Low | 2–5 |
+ +---------------------+-----------------------------------+
+ | Informational | 1 |
+ +---------------------+-----------------------------------+
+
+The likelihood and impact of a threat depends on the
+target environment in which 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.
+
+For each threat, we strive to indicate whether the mitigations are currently
+implemented or not. However, the answer to this question is not always straight
+forward. Some mitigations are partially implemented in the generic code but also
+rely on the platform code to implement some bits of it. This threat model aims
+to be platform-independent and it is important to keep in mind that such threats
+only get mitigated if the platform code properly fulfills its responsibilities.
+
+Also, some mitigations require enabling specific features, which must be
+explicitly turned on via a build flag.
+
+When such conditions must be met, these are highlighted in the ``Mitigations
+implemented?`` box.
+
+As our :ref:`Target of Evaluation` is made of several, distinct firmware images,
+some threats are confined in specific images, while others apply to each of
+them. To help developers implement mitigations in the right place, threats below
+are categorized based on the firmware image that should mitigate them.
+
+.. _General Threats:
+
+General Threats for All Firmware Images
+---------------------------------------
+
++------------------------+---------------------------------------------------+
+| ID | 05 |
++========================+===================================================+
+| Threat | | **Information leak via UART logs** |
+| | |
+| | | During the development stages of software it is |
+| | common to print all sorts of information on the |
+| | console, including sensitive or confidential |
+| | information such as crash reports with detailed |
+| | information of the CPU state, current registers |
+| | values, privilege level or 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 enabled in |
+| | the production version. |
+| | |
+| | | This happens when directly logging sensitive |
+| | information and more subtly when logging |
+| | side-channel information that can be used by an |
+| | attacker to learn about sensitive information. |
++------------------------+---------------------------------------------------+
+| 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 | | Remove sensitive information logging in |
+| | production releases. |
+| | |
+| | | Do not conditionally log information depending |
+| | on potentially sensitive data. |
+| | |
+| | | Do not log high precision timing information. |
++------------------------+---------------------------------------------------+
+| Mitigations | | Yes / Platform Specific. |
+| implemented? | Requires the right build options to be used. |
+| | |
+| | | Crash reporting is only enabled for debug |
+| | builds by default, see ``CRASH_REPORTING`` |
+| | build option. |
+| | |
+| | | The log level can be tuned at build time, from |
+| | very verbose to no output at all. See |
+| | ``LOG_LEVEL`` build option. By default, release |
+| | builds are a lot less verbose than debug ones |
+| | but still produce some output. |
+| | |
+| | | Messages produced by the platform code should |
+| | use the appropriate level of verbosity so as |
+| | not to leak sensitive information in production |
+| | builds. |
++------------------------+---------------------------------------------------+
+
++------------------------+----------------------------------------------------+
+| 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 | Disable the debug and trace capability for |
+| | production releases or enable proper debug |
+| | authentication as recommended by [`DEN0034`_]. |
++------------------------+----------------------------------------------------+
+| Mitigations | | Platform specific. |
+| implemented? | |
+| | | Configuration of debug and trace capabilities is |
+| | entirely platform specific. |
++------------------------+----------------------------------------------------+
+
++------------------------+------------------------------------------------------+
+| 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, TF-A has multiple points |
+| | where memory corruption security errors can arise. |
+| | |
+| | | 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 | | 1) Use proper input validation. |
+| | |
+| | | 2) Code reviews, testing. |
++------------------------+------------------------------------------------------+
+| Mitigations | | 1) Yes. |
+| implemented? | 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. |
+| | |
+| | | 2) Yes. |
+| | 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. |
++------------------------+------------------------------------------------------+
+
+
++------------------------+----------------------------------------------------+
+| ID | 11 |
++========================+====================================================+
+| Threat | | **Misconfiguration of the Memory Management Unit |
+| | (MMU) may allow a normal world software to |
+| | access sensitive data, execute arbitrary |
+| | code or access otherwise restricted HW |
+| | interface** |
+| | |
+| | | 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 | When configuring access permissions, the |
+| | principle of least privilege ought to be |
+| | enforced. This means we should not grant more |
+| | privileges than strictly needed, e.g. code |
+| | should be read-only executable, read-only data |
+| | should be read-only execute-never, and so on. |
++------------------------+----------------------------------------------------+
+| Mitigations | | Platform specific. |
+| implemented? | |
+| | | MMU configuration is platform specific, |
+| | therefore platforms need to make sure that the |
+| | correct attributes are assigned to memory |
+| | regions. |
+| | |
+| | | TF-A provides a library which abstracts the |
+| | low-level details of MMU configuration. It |
+| | provides well-defined and tested APIs. |
+| | Platforms are encouraged to use it to limit the |
+| | risk of misconfiguration. |
++------------------------+----------------------------------------------------+
+
+
++------------------------+-----------------------------------------------------+
+| ID | 13 |
++========================+=====================================================+
+| Threat | | **Leaving sensitive information in the memory, |
+| | can allow an attacker to retrieve them.** |
+| | |
+| | | Accidentally leaving not-needed sensitive data in |
+| | internal buffers can leak them if an attacker |
+| | gains access to memory due to a vulnerability. |
++------------------------+-----------------------------------------------------+
+| Diagram Elements | DF4, DF5 |
++------------------------+-----------------------------------------------------+
+| Affected TF-A | BL1, BL2, BL31 |
+| Components | |
++------------------------+-----------------------------------------------------+
+| Assets | Sensitive Data |
++------------------------+-----------------------------------------------------+
+| Threat Agent | NSCode, SecCode |
++------------------------+-----------------------------------------------------+
+| Threat Type | Information Disclosure |
++------------------------+-------------------+----------------+----------------+
+| 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 | Clear the sensitive data from internal buffers as |
+| | soon as they are not needed anymore. |
++------------------------+-----------------------------------------------------+
+| Mitigations | | Yes / Platform specific |
+| implemented? | |
++------------------------+-----------------------------------------------------+
+
+
++------------------------+-----------------------------------------------------+
+| ID | 15 |
++========================+=====================================================+
+| Threat | | **Improper handling of input data received over |
+| | a UART interface may allow an attacker to tamper |
+| | with TF-A execution environment.** |
+| | |
+| | | The consequences of the attack depend on the |
+| | the exact usage of input data received over UART. |
+| | Examples are injection of arbitrary data, |
+| | sensitive data tampering, influencing the |
+| | execution path, denial of service (if using |
+| | blocking I/O). This list may not be exhaustive. |
++------------------------+-----------------------------------------------------+
+| Diagram Elements | DF2, DF4, DF5 |
++------------------------+-----------------------------------------------------+
+| Affected TF-A | BL1, BL2, BL31 |
+| Components | |
++------------------------+-----------------------------------------------------+
+| Assets | Sensitive Data, Code Execution, Availability |
++------------------------+-----------------------------------------------------+
+| Threat Agent | NSCode, SecCode |
++------------------------+-----------------------------------------------------+
+| Threat Type | Tampering, Information Disclosure, Denial of |
+| | service, 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 | | By default, the code to read input data from UART |
+| | interfaces is disabled (see `ENABLE_CONSOLE_GETC` |
+| | build option). It should only be enabled on a |
+| | need basis. |
+| | |
+| | | Data received over UART interfaces should be |
+| | treated as untrusted data. As such, it should be |
+| | properly sanitized and handled with caution. |
++------------------------+-----------------------------------------------------+
+| Mitigations | | Platform specific. |
+| implemented? | |
+| | | Generic code does not read any input data from |
+| | UART interface(s). |
++------------------------+-----------------------------------------------------+
+
+
+.. _Boot Firmware Threats:
+
+Threats to be Mitigated by the Boot Firmware
+--------------------------------------------
+
+The boot firmware here refers to the boot ROM (BL1) and the trusted boot
+firmware (BL2). Typically it does not stay resident in memory and it is
+dismissed once execution has reached the runtime EL3 firmware (BL31). Thus, past
+that point in time, the threats below can no longer be exploited.
+
+Note, however, that this is not necessarily true on all platforms. Platform
+vendors should review these threats to make sure they cannot be exploited
+nonetheless once execution has reached the runtime EL3 firmware.
+
++------------------------+----------------------------------------------------+
+| 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 | | 1) Implement the `Trusted Board Boot (TBB)`_ |
+| | feature which prevents malicious firmware from |
+| | running on the platform by authenticating all |
+| | firmware images. |
+| | |
+| | | 2) Perform extra checks on unauthenticated data, |
+| | such as FIP metadata, prior to use. |
++------------------------+----------------------------------------------------+
+| Mitigations | | 1) Yes, provided that the ``TRUSTED_BOARD_BOOT`` |
+| implemented? | build option is set to 1. |
+| | |
+| | | 2) Yes. |
++------------------------+----------------------------------------------------+
+
++------------------------+----------------------------------------------------+
+| 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 | Implement anti-rollback protection using |
+| | non-volatile counters (NV counters) as required |
+| | by `TBBR-Client specification`_. |
++------------------------+----------------------------------------------------+
+| Mitigations | | Yes / Platform specific. |
+| implemented? | |
+| | | 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 than |
+| | 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 | Copy image to on-chip memory before authenticating |
+| | it. |
++------------------------+-------------------------------------------------------+
+| Mitigations | | Platform specific. |
+| implemented? | |
+| | | The list of images to load and their location is |
+| | platform specific. Platforms are responsible for |
+| | arranging images to be loaded in on-chip memory. |
++------------------------+-------------------------------------------------------+
+
+
++------------------------+-------------------------------------------------------+
+| 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 | Mechanisms to detect clock glitch and power |
+| | variations. |
++------------------------+-------------------------------------------------------+
+| Mitigations | | No. |
+| implemented? | |
+| | | 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.** |
++------------------------+-------------------------------------------------------+
+
+.. topic:: Measured Boot Threats (or lack of)
+
+ In the current Measured Boot design, BL1, BL2, and BL31, as well as the
+ secure world components, form the |SRTM|. Measurement data is currently
+ considered an asset to be protected against attack, and this is achieved
+ by storing them in the Secure Memory.
+ Beyond the measurements stored inside the TCG-compliant Event Log buffer,
+ there are no other assets to protect or threats to defend against that
+ could compromise |TF-A| execution environment's security.
+
+ There are general security assets and threats associated with remote/delegated
+ attestation. However, these are outside the |TF-A| security boundary and
+ should be dealt with by the appropriate agent in the platform/system.
+ Since current Measured Boot design does not use local attestation, there would
+ be no further assets to protect(like unsealed keys).
+
+ A limitation of the current Measured Boot design is that it is dependent upon
+ Secure Boot as implementation of Measured Boot does not extend measurements
+ into a discrete |TPM|, where they would be securely stored and protected
+ against tampering. This implies that if Secure-Boot is compromised, Measured
+ Boot may also be compromised.
+
+ Platforms must carefully evaluate the security of the default implementation
+ since the |SRTM| includes all secure world components.
+
+
+.. _Runtime Firmware Threats:
+
+Threats to be Mitigated by the Runtime EL3 Firmware
+---------------------------------------------------
+
++------------------------+------------------------------------------------------+
+| 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 | Validate SMC function ids and arguments before using |
+| | them. |
++------------------------+------------------------------------------------------+
+| Mitigations | | Yes / Platform specific. |
+| implemented? | |
+| | | For standard services, all input is validated. |
+| | |
+| | | Platforms that implement SiP services must also |
+| | validate SMC call arguments. |
++------------------------+------------------------------------------------------+
+
+
++------------------------+------------------------------------------------------+
+| ID | 09 |
++========================+======================================================+
+| Threat | | **Improperly handled SMC calls can leak register |
+| | contents** |
+| | |
+| | | When switching between worlds, TF-A register state |
+| | can leak to software in different security |
+| | contexts. |
++------------------------+------------------------------------------------------+
+| Diagram Elements | DF4, DF5 |
++------------------------+------------------------------------------------------+
+| Affected TF-A | BL31 |
+| Components | |
++------------------------+------------------------------------------------------+
+| Assets | Sensitive Data |
++------------------------+------------------------------------------------------+
+| Threat Agent | NSCode, SecCode |
++------------------------+------------------------------------------------------+
+| 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 | Save and restore registers when switching contexts. |
++------------------------+------------------------------------------------------+
+| Mitigations | | Yes. |
+| implemented? | |
+| | | This is the default behaviour in TF-A. |
+| | Build options are also provided to save/restore |
+| | additional registers such as floating-point |
+| | registers. These should be enabled if required. |
++------------------------+------------------------------------------------------+
+
++------------------------+-----------------------------------------------------+
+| 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 | Enable appropriate side-channel protections. |
++------------------------+-----------------------------------------------------+
+| Mitigations | | Yes / Platform specific. |
+| implemented? | |
+| | | 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 | 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 |
++------------------------+-------------------+----------------+----------------+
+| Application | Server | IoT | Mobile |
++------------------------+-------------------+----------------+----------------+
+| Impact | Medium (3) | Medium (3) | Medium (3) |
++------------------------+-------------------+----------------+----------------+
+| Likelihood | Low (2) | Low (2) | Low (2) |
++------------------------+-------------------+----------------+----------------+
+| Total Risk Rating | Medium (6) | Medium (6) | Medium (6) |
++------------------------+-------------------+----------------+----------------+
+| Mitigations | Follow mitigation strategies as described in |
+| | `Secure Development Guidelines`_. |
++------------------------+-----------------------------------------------------+
+| Mitigations | | Yes / platform specific. |
+| implemented? | |
+| | | 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. This |
+| | should be the case if threat #06 is properly |
+| | mitigated. |
++------------------------+-----------------------------------------------------+
+
+
+Threats to be Mitigated by an External Agent Outside of TF-A
+------------------------------------------------------------
+
++------------------------+-----------------------------------------------------+
+| ID | 14 |
++========================+=====================================================+
+| Threat | | **Attacker wants to execute an arbitrary or |
+| | untrusted binary as the secure OS.** |
+| | |
+| | | When the option OPTEE_ALLOW_SMC_LOAD is enabled, |
+| | this trusts the non-secure world up until the |
+| | point it issues the SMC call to load the Secure |
+| | BL32 payload. If a compromise occurs before the |
+| | SMC call is invoked, then arbitrary code execution|
+| | in S-EL1 can occur or arbitrary memory in EL3 can |
+| | be overwritten. |
++------------------------+-----------------------------------------------------+
+| Diagram Elements | DF5 |
++------------------------+-----------------------------------------------------+
+| Affected TF-A | BL31, BL32 |
+| Components | |
++------------------------+-----------------------------------------------------+
+| Assets | Code Execution, Sensitive Data |
++------------------------+-----------------------------------------------------+
+| Threat Agent | NSCode |
++------------------------+-----------------------------------------------------+
+| Threat Type | Tampering, 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 | When enabling the option OPTEE_ALLOW_SMC_LOAD, |
+| | the non-secure OS must be considered a closed |
+| | platform up until the point the SMC can be invoked |
+| | to load OP-TEE. |
++------------------------+-----------------------------------------------------+
+| Mitigations | | None in TF-A itself. This option is only used by |
+| implemented? | ChromeOS currently which has other mechanisms to |
+| | to mitigate this threat which are described in |
+| | `OP-TEE Dispatcher`_. |
++------------------------+-----------------------------------------------------+
+
+--------------
+
+*Copyright (c) 2021-2024, 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/
+.. _OP-TEE Dispatcher: https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/components/spd/optee-dispatcher.rst
+.. _PSR Specification: https://developer.arm.com/documentation/den0106/0100
diff --git a/docs/threat_model/firmware_threat_model/threat_model_arm_cca.rst b/docs/threat_model/firmware_threat_model/threat_model_arm_cca.rst
new file mode 100644
index 0000000..af38ea3
--- /dev/null
+++ b/docs/threat_model/firmware_threat_model/threat_model_arm_cca.rst
@@ -0,0 +1,225 @@
+Threat Model for TF-A with Arm CCA support
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Introduction
+************
+
+This document provides a threat model of TF-A firmware for platforms with Arm
+Realm Management Extension (RME) support which implement Arm Confidential
+Compute Architecture (Arm CCA).
+
+Although it is a separate document, it references the :ref:`Generic Threat
+Model` in a number of places, as some of the contents is commonly applicable to
+TF-A with or without Arm CCA support.
+
+Target of Evaluation
+********************
+
+In this threat model, the target of evaluation is the Trusted Firmware for
+A-class Processors (TF-A) with RME support and Arm CCA support. This includes
+the boot ROM (BL1), the trusted boot firmware (BL2) and the runtime EL3 firmware
+(BL31).
+
+Assumptions
+===========
+
+We make the following assumptions:
+
+- :ref:`Realm Management Extension (RME)` is enabled on the platform.
+
+- Arm CCA Hardware Enforced Security (HES) is available on the platform, as
+ recommended by `Arm CCA security model`_:
+
+ *[R0004] Arm strongly recommends that all implementations of CCA utilize*
+ *hardware enforced security (CCA HES).*
+
+- All TF-A images run from on-chip memory. Data used by these images also live
+ in on-chip memory. This means TF-A is not vulnerable to an attacker that can
+ probe or tamper with off-chip memory.
+
+ These are requirements of the `Arm CCA security model`_:
+
+ *[R0147] Monitor code executes entirely from on-chip memory.*
+
+ *[R0149] Any monitor data that may affect the CCA security guarantee, other*
+ *than GPT, is either held in on-chip memory, or in external memory but with*
+ *additional integrity protection.*
+
+ Note that this threat model hardens *[R0149]* requirement by forbidding to
+ hold data in external memory, even if it is integrity-protected - except for
+ GPT data.
+
+- TF-A BL1 image is immutable and thus implicitly trusted. It runs from
+ read-only memory or write-protected memory. This could be on-chip ROM, on-chip
+ OTP, locked on-chip flash, or write-protected on-chip RAM for example.
+
+ This is a requirement of the `Arm CCA security model`_:
+
+ *[R0158] Arm recommends that all initial boot code is immutable on a*
+ *secured system.*
+
+ *[R0050] If all or part of initial boot code is instantiated in on-chip*
+ *memory then other trusted subsystems or application PE cannot modify that*
+ *code before it has been executed.*
+
+- Trusted boot and measured boot are enabled. This means an attacker can't boot
+ arbitrary images that are not approved by platform providers.
+
+ These are requirements of the `Arm CCA security model`_:
+
+ *[R0048] A secured system can only load authorized CCA firmware.*
+
+ *[R0079] All Monitor firmware loaded by PE initial boot is measured and*
+ *verified as outlined in Verified boot.*
+
+- No experimental features are enabled. These are typically incomplete features,
+ which need more time to stabilize. Thus, we do not consider threats that may
+ come from them. It is not recommended to use these features in production
+ builds.
+
+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_arm_cca_dfd.puml
+ :caption: Figure 1: Data Flow Diagram
+
+.. table:: Table 1: Data Flow Diagram Description
+
+ +-----------------+--------------------------------------------------------+
+ | Diagram Element | Description |
+ +=================+========================================================+
+ | DF1 | | Refer to DF1 description in the |
+ | | :ref:`Generic Threat Model`. Additionally TF-A |
+ | | loads realm images. |
+ +-----------------+--------------------------------------------------------+
+ | DF2-DF6 | | Refer to DF2-DF6 descriptions in the |
+ | | :ref:`Generic Threat Model`. |
+ +-----------------+--------------------------------------------------------+
+ | DF7 | | Boot images interact with Arm CCA HES to record boot |
+ | | measurements and retrieve data used for AP images |
+ | | authentication. |
+ | | |
+ | | | The runtime firmware interacts with Arm CCA HES to |
+ | | obtain sensitive attestation data for the realm |
+ | | world. |
+ +-----------------+--------------------------------------------------------+
+ | DF8 | | Realm world software (e.g. TF-RMM) interact with |
+ | | TF-A through SMC call interface and/or shared |
+ | | memory. |
+ +-----------------+--------------------------------------------------------+
+
+Threat Analysis
+***************
+
+In this threat model, we use the same method to analyse threats as in the
+:ref:`Generic Threat Model`. This section only points out differences where
+applicable.
+
+- There is an additional threat agent: *RealmCode*. It takes the form of
+ malicious or faulty code running in the realm world, including R-EL2, R-EL1
+ and R-EL0 levels.
+
+- At this time we only consider the ``Server`` target environment. New threats
+ identified in this threat model will only be given a risk rating for this
+ environment. Other environments may be added in a future revision
+
+Threat Assessment
+=================
+
+General Threats for All Firmware Images
+---------------------------------------
+
+The following table analyses the :ref:`General Threats` in the context of this
+threat model. Only deltas are pointed out.
+
+ +----+-------------+-------------------------------------------------------+
+ | ID | Applicable? | Comments |
+ +====+=============+=======================================================+
+ | 05 | Yes | |
+ +----+-------------+-------------------------------------------------------+
+ | 06 | Yes | |
+ +----+-------------+-------------------------------------------------------+
+ | 08 | Yes | Additional diagram element: DF8. |
+ | | | |
+ | | | Additional threat agent: RealmCode. |
+ +----+-------------+-------------------------------------------------------+
+ | 11 | Yes | | Misconfiguration of the Memory Management Unit |
+ | | | (MMU) may allow a **normal/secure/realm** world |
+ | | | software to access sensitive data, execute arbitrary|
+ | | | code or access otherwise restricted HW interface. |
+ | | | |
+ | | | | **Note that on RME systems, MMU configuration also |
+ | | | includes Granule Protection Tables (GPT) setup.** |
+ | | | |
+ | | | | Additional diagram elements: DF4, DF7, DF8. |
+ | | | |
+ | | | | Additional threat agents: SecCode, RealmCode. |
+ +----+-------------+-------------------------------------------------------+
+ | 13 | Yes | Additional diagram element: DF8. |
+ | | | |
+ | | | Additional threat agent: RealmCode. |
+ +----+-------------+-------------------------------------------------------+
+ | 15 | Yes | Additional diagram element: DF8. |
+ | | | |
+ | | | Additional threat agent: RealmCode. |
+ +----+-------------+-------------------------------------------------------+
+
+Threats to be Mitigated by the Boot Firmware
+--------------------------------------------
+
+The following table analyses the :ref:`Boot Firmware Threats` in the context of
+this threat model. Only deltas are pointed out.
+
+ +----+-------------+-------------------------------------------------------+
+ | ID | Applicable? | Comments |
+ +====+=============+=======================================================+
+ | 01 | Yes | Additional diagram element: DF8. |
+ | | | |
+ | | | Additional threat agent: RealmCode. |
+ +----+-------------+-------------------------------------------------------+
+ | 02 | Yes | Additional diagram element: DF8. |
+ | | | |
+ | | | Additional threat agent: RealmCode. |
+ +----+-------------+-------------------------------------------------------+
+ | 03 | Yes | |
+ +----+-------------+-------------------------------------------------------+
+ | 04 | Yes | |
+ +----+-------------+-------------------------------------------------------+
+
+Threats to be Mitigated by the Runtime EL3 Firmware
+---------------------------------------------------
+
+The following table analyses the :ref:`Runtime Firmware Threats` in the context
+of this threat model. Only deltas are pointed out.
+
+ +----+-------------+-------------------------------------------------------+
+ | ID | Applicable? | Comments |
+ +====+=============+=======================================================+
+ | 07 | Yes | Additional diagram element: DF8. |
+ | | | |
+ | | | Additional threat agent: RealmCode. |
+ +----+-------------+-------------------------------------------------------+
+ | 09 | Yes | Additional diagram element: DF8. |
+ | | | |
+ | | | Additional threat agent: RealmCode. |
+ +----+-------------+-------------------------------------------------------+
+ | 10 | Yes | Additional diagram element: DF8. |
+ | | | |
+ | | | Additional threat agent: RealmCode. |
+ +----+-------------+-------------------------------------------------------+
+ | 12 | Yes | Additional diagram element: DF8. |
+ | | | |
+ | | | Additional threat agent: RealmCode. |
+ +----+-------------+-------------------------------------------------------+
+ | 14 | Yes | |
+ +----+-------------+-------------------------------------------------------+
+
+*Copyright (c) 2023-2024, Arm Limited. All rights reserved.*
+
+.. _Arm CCA Security Model: https://developer.arm.com/documentation/DEN0096/A_a
diff --git a/docs/threat_model/firmware_threat_model/threat_model_el3_spm.rst b/docs/threat_model/firmware_threat_model/threat_model_el3_spm.rst
new file mode 100644
index 0000000..a2d6798
--- /dev/null
+++ b/docs/threat_model/firmware_threat_model/threat_model_el3_spm.rst
@@ -0,0 +1,650 @@
+EL3 SPMC Threat Model
+*********************
+
+************
+Introduction
+************
+This document provides a threat model for the TF-A :ref:`EL3 Secure Partition Manager`
+(EL3 SPM) implementation. The EL3 SPM implementation is based on the
+`Arm Firmware Framework for Arm A-profile`_ specification.
+
+********************
+Target of Evaluation
+********************
+In this threat model, the target of evaluation is the ``Secure Partition Manager Core``
+component (SPMC) within the EL3 firmware.
+The monitor and SPMD at EL3 are covered by the :ref:`Generic TF-A threat model
+<threat_analysis>`.
+
+The scope for this threat model is:
+
+- The TF-A implementation for the EL3 SPMC
+- The implementation complies with the FF-A v1.1 specification.
+- Secure partition is statically provisioned at boot time.
+- Focus on the run-time part of the life-cycle (no specific emphasis on boot
+ time, factory firmware provisioning, firmware udpate etc.)
+- Not covering advanced or invasive physical attacks such as decapsulation,
+ FIB etc.
+
+Data Flow Diagram
+=================
+Figure 1 shows a high-level data flow diagram for the SPM split into an SPMD
+and SPMC component at EL3. The SPMD mostly acts as a relayer/pass-through between
+the normal world and the secure world. It is assumed to expose small attack surface.
+
+A description of each diagram element is given in Table 1. In the diagram, the
+red broken lines indicate trust boundaries.
+
+Components outside of the broken lines are considered untrusted.
+
+.. uml:: ../../resources/diagrams/plantuml/el3_spm_dfd.puml
+ :caption: Figure 1: EL3 SPMC Data Flow Diagram
+
+.. table:: Table 1: EL3 SPMC Data Flow Diagram Description
+
+ +---------------------+--------------------------------------------------------+
+ | Diagram Element | Description |
+ +=====================+========================================================+
+ | DF1 | SP to SPMC communication. FF-A function invocation or |
+ | | implementation-defined Hypervisor call. |
+ | | |
+ | | Note:- To communicate with LSP, SP1 performs a direct |
+ | | message request to SPMC targeting LSP as destination. |
+ +---------------------+--------------------------------------------------------+
+ | DF2 | SPMC to SPMD communication. |
+ +---------------------+--------------------------------------------------------+
+ | DF3 | SPMD to NS forwarding. |
+ +---------------------+--------------------------------------------------------+
+ | DF4 | SPMC to LSP communication. |
+ | | NWd to LSP communication happens through SPMC. |
+ | | LSP can send direct response SP1 or NWd through SPMC. |
+ +---------------------+--------------------------------------------------------+
+ | DF5 | HW control. |
+ +---------------------+--------------------------------------------------------+
+ | DF6 | Bootloader image loading. |
+ +---------------------+--------------------------------------------------------+
+ | DF7 | External memory access. |
+ +---------------------+--------------------------------------------------------+
+
+
+***************
+Threat Analysis
+***************
+
+This threat model follows a similar methodology to the :ref:`Generic TF-A threat model
+<threat_analysis>`. The following sections define:
+
+- Trust boundaries
+- Assets
+- Theat agents
+- Threat types
+
+Trust boundaries
+================
+
+- Normal world is untrusted.
+- Secure world and normal world are separate trust boundaries.
+- EL3 monitor, SPMD and SPMC are trusted.
+- Bootloaders (in particular BL1/BL2 if using TF-A) and run-time BL31 are
+ implicitely trusted by the usage of trusted boot.
+- EL3 monitor, SPMD, SPMC do not trust SPs.
+
+Assets
+======
+
+The following assets are identified:
+
+- SPMC state.
+- SP state.
+- Information exchange between endpoints (partition messages).
+- SPMC secrets (e.g. pointer authentication key when enabled)
+- SP secrets (e.g. application keys).
+- Scheduling cycles.
+- Shared memory.
+
+Threat Agents
+=============
+
+The following threat agents are identified:
+
+- Non-secure endpoint (referred NS-Endpoint later): normal world client at
+ NS-EL2 (Hypervisor) or NS-EL1 (VM or OS kernel).
+- Secure endpoint (referred as S-Endpoint later): typically a secure partition.
+- Hardware attacks (non-invasive) requiring a physical access to the device,
+ such as bus probing or DRAM stress.
+
+Threat types
+============
+
+The following threat categories as exposed in the :ref:`Generic TF-A threat model
+<threat_analysis>`
+are re-used:
+
+- Spoofing
+- Tampering
+- Repudiation
+- Information disclosure
+- Denial of service
+- Elevation of privileges
+
+Similarly this threat model re-uses the same threat risk ratings. The risk
+analysis is evaluated based on the environment being ``Server`` or ``Mobile``.
+IOT is not evaluated as the EL3 SPMC is primarily meant for use in Client.
+
+Threat Assessment
+=================
+
+The following threats are identified by applying STRIDE analysis on each diagram
+element of the data flow diagram.
+
++------------------------+----------------------------------------------------+
+| ID | 01 |
++========================+====================================================+
+| Threat | **An endpoint impersonates the sender |
+| | FF-A ID in a direct request/response invocation.** |
++------------------------+----------------------------------------------------+
+| Diagram Elements | DF1, DF2, DF3, DF4 |
++------------------------+----------------------------------------------------+
+| Affected TF-A | SPMD, SPMC |
+| Components | |
++------------------------+----------------------------------------------------+
+| Assets | SP state |
++------------------------+----------------------------------------------------+
+| Threat Agent | NS-Endpoint, S-Endpoint |
++------------------------+----------------------------------------------------+
+| Threat Type | Spoofing |
++------------------------+--------------------------+-------------------------+
+| Application | Server | Mobile |
++------------------------+--------------------------++------------------------+
+| Impact | Critical(5) | Critical(5) |
++------------------------+--------------------------++------------------------+
+| Likelihood | Critical(5) | Critical(5) |
++------------------------+--------------------------++------------------------+
+| Total Risk Rating | Critical(25) | Critical(25) |
++------------------------+--------------------------+-------------------------+
+| Mitigations | SPMC must be able to correctly identify an |
+| | endpoint and enforce checks to disallow spoofing. |
++------------------------+----------------------------------------------------+
+| Mitigations | Yes. |
+| implemented? | The SPMC enforces checks in the direct message |
+| | request/response interfaces such an endpoint cannot|
+| | spoof the origin and destination worlds (e.g. a NWd|
+| | originated message directed to the SWd cannot use a|
+| | SWd ID as the sender ID). |
+| | Also enforces check for direct response being sent |
+| | only to originator of request. |
++------------------------+----------------------------------------------------+
+
++------------------------+----------------------------------------------------+
+| ID | 02 |
++========================+====================================================+
+| Threat | **An endpoint impersonates the receiver |
+| | FF-A ID in a direct request/response invocation.** |
++------------------------+----------------------------------------------------+
+| Diagram Elements | DF1, DF2, DF3, DF4 |
++------------------------+----------------------------------------------------+
+| Affected TF-A | SPMD, SPMC |
+| Components | |
++------------------------+----------------------------------------------------+
+| Assets | SP state |
++------------------------+----------------------------------------------------+
+| Threat Agent | NS-Endpoint, S-Endpoint |
++------------------------+----------------------------------------------------+
+| Threat Type | Spoofing, Denial of Service |
++------------------------+--------------------------+-------------------------+
+| Application | Server | Mobile |
++------------------------+--------------------------++------------------------+
+| Impact | Critical(5) | Critical(5) |
++------------------------+--------------------------++------------------------+
+| Likelihood | Critical(5) | Critical(5) |
++------------------------+--------------------------++------------------------+
+| Total Risk Rating | Critical(25) | Critical(25) |
++------------------------+--------------------------+-------------------------+
+| Mitigations | Validate if endpoind has permission to send |
+| | request to other endpoint by implementation |
+| | defined means. |
++------------------------+----------------------------------------------------+
+| Mitigations | Platform specific. |
+| implemented? | |
+| | The guidance below is left for a system integrator |
+| | to implement as necessary. |
+| | |
+| | Additionally a software component residing in the |
+| | SPMC can be added for the purpose of direct |
+| | request/response filtering. |
+| | |
+| | It can be configured with the list of known IDs |
+| | and about which interaction can occur between one |
+| | and another endpoint (e.g. which NWd endpoint ID |
+| | sends a direct request to which SWd endpoint ID). |
+| | |
+| | This component checks the sender/receiver fields |
+| | for a legitimate communication between endpoints. |
+| | |
+| | A similar component can exist in the OS kernel |
+| | driver, or Hypervisor although it remains untrusted|
+| | by the SPMD/SPMC. |
++------------------------+----------------------------------------------------+
+
++------------------------+----------------------------------------------------+
+| ID | 03 |
++========================+====================================================+
+| Threat | **Tampering with memory shared between an endpoint |
+| | and the SPMC.** |
+| | |
+| | A malicious endpoint may attempt tampering with its|
+| | RX/TX buffer contents while the SPMC is processing |
+| | it (TOCTOU). |
++------------------------+----------------------------------------------------+
+| Diagram Elements | DF1, DF3, DF7 |
++------------------------+----------------------------------------------------+
+| Affected TF-A | SPMC |
+| Components | |
++------------------------+----------------------------------------------------+
+| Assets | Shared memory, Information exchange |
++------------------------+----------------------------------------------------+
+| Threat Agent | NS-Endpoint, S-Endpoint |
++------------------------+----------------------------------------------------+
+| Threat Type | Tampering |
++------------------------+--------------------------+-------------------------+
+| Application | Server | Mobile |
++------------------------+--------------------------+-------------------------+
+| Impact | High (4) | High (4) |
++------------------------+--------------------------+-------------------------+
+| Likelihood | High (4) | High (4) |
++------------------------+--------------------------+-------------------------+
+| Total Risk Rating | High (16) | High (16) |
++------------------------+--------------------------+-------------------------+
+| Mitigations | Validate all inputs, copy before use. |
++------------------------+----------------------------------------------------+
+| Mitigations | Yes. In context of FF-A v1.1 this is the case of |
+| implemented? | sharing the RX/TX buffer pair and usage in the |
+| | PARTITION_INFO_GET or memory sharing primitives. |
+| | |
+| | The SPMC copies the contents of the TX buffer |
+| | to an internal temporary buffer before processing |
+| | its contents. The SPMC implements hardened input |
+| | validation on data transmitted through the TX |
+| | buffer by an untrusted endpoint. |
+| | |
+| | The TF-A SPMC enforces |
+| | checks on data transmitted through RX/TX buffers. |
++------------------------+----------------------------------------------------+
+
++------------------------+----------------------------------------------------+
+| ID | 04 |
++========================+====================================================+
+| Threat | **An endpoint may tamper with its own state or the |
+| | state of another endpoint.** |
+| | |
+| | A malicious endpoint may attempt violating: |
+| | |
+| | - its own or another SP state by using an unusual |
+| | combination (or out-of-order) FF-A function |
+| | invocations. |
+| | This can also be an endpoint emitting FF-A |
+| | function invocations to another endpoint while |
+| | the latter in not in a state to receive it (e.g. |
+| | SP sends a direct request to the normal world |
+| | early while the normal world is not booted yet). |
+| | - the SPMC state itself by employing unexpected |
+| | transitions in FF-A memory sharing, direct |
+| | requests and responses, or handling of interrupts|
+| | This can be led by random stimuli injection or |
+| | fuzzing. |
++------------------------+----------------------------------------------------+
+| Diagram Elements | DF1, DF2, DF3 |
++------------------------+----------------------------------------------------+
+| Affected TF-A | SPMD, SPMC |
+| Components | |
++------------------------+----------------------------------------------------+
+| Assets | SP state, SPMC state |
++------------------------+----------------------------------------------------+
+| Threat Agent | NS-Endpoint, S-Endpoint |
++------------------------+----------------------------------------------------+
+| Threat Type | Tampering |
++------------------------+--------------------------+-------------------------+
+| Application | Server | Mobile |
++------------------------+--------------------------+-------------------------+
+| Impact | High (4) | High (4) |
++------------------------+--------------------------+-------------------------+
+| Likelihood | Medium (3) | Medium (3) |
++------------------------+--------------------------+-------------------------+
+| Total Risk Rating | High (12) | High (12) |
++------------------------+------------------+-----------------+---------------+
+| Mitigations | Follow guidelines in FF-A v1.1 specification on |
+| | state transitions (run-time model). |
++------------------------+----------------------------------------------------+
+| Mitigations | Yes. The TF-A SPMC is hardened to follow this |
+| implemented? | guidance. |
++------------------------+----------------------------------------------------+
+
++------------------------+----------------------------------------------------+
+| ID | 05 |
++========================+====================================================+
+| Threat | **Replay fragments of past communication between |
+| | endpoints.** |
+| | |
+| | A malicious endpoint may replay a message exchange |
+| | that occurred between two legitimate endpoints as |
+| | a matter of triggering a malfunction or extracting |
+| | secrets from the receiving endpoint. In particular |
+| | the memory sharing operation with fragmented |
+| | messages between an endpoint and the SPMC may be |
+| | replayed by a malicious agent as a matter of |
+| | getting access or gaining permissions to a memory |
+| | region which does not belong to this agent. |
++------------------------+----------------------------------------------------+
+| Diagram Elements | DF2, DF3 |
++------------------------+----------------------------------------------------+
+| Affected TF-A | SPMC |
+| Components | |
++------------------------+----------------------------------------------------+
+| Assets | Information exchange |
++------------------------+----------------------------------------------------+
+| Threat Agent | NS-Endpoint, S-Endpoint |
++------------------------+----------------------------------------------------+
+| Threat Type | Repudiation |
++------------------------+--------------------------+-------------------------+
+| Application | Server | Mobile |
++------------------------+--------------------------+-------------------------+
+| Impact | Medium (3) | Medium (3) |
++------------------------+--------------------------+-------------------------+
+| Likelihood | High (4) | High (4) |
++------------------------+--------------------------+-------------------------+
+| Total Risk Rating | High (12) | High (12) |
++------------------------+--------------------------+-------------------------+
+| Mitigations | Strict input validation and state tracking. |
++------------------------+----------------------------------------------------+
+| Mitigations | Platform specific. |
+| implemented? | |
++------------------------+----------------------------------------------------+
+
++------------------------+----------------------------------------------------+
+| ID | 06 |
++========================+====================================================+
+| Threat | **A malicious endpoint may attempt to extract data |
+| | or state information by the use of invalid or |
+| | incorrect input arguments.** |
+| | |
+| | Lack of input parameter validation or side effects |
+| | of maliciously forged input parameters might affect|
+| | the SPMC. |
++------------------------+----------------------------------------------------+
+| Diagram Elements | DF1, DF2, DF3 |
++------------------------+----------------------------------------------------+
+| Affected TF-A | SPMD, SPMC |
+| Components | |
++------------------------+----------------------------------------------------+
+| Assets | SP secrets, SPMC secrets, SP state, SPMC state |
++------------------------+----------------------------------------------------+
+| Threat Agent | NS-Endpoint, S-Endpoint |
++------------------------+----------------------------------------------------+
+| Threat Type | Information discolure |
++------------------------+--------------------------+-------------------------+
+| Application | Server | Mobile |
++------------------------+--------------------------+-------------------------+
+| Impact | High (4) | High (4) |
++------------------------+--------------------------+-------------------------+
+| Likelihood | Medium (3) | Medium (3) |
++------------------------+--------------------------+-------------------------+
+| Total Risk Rating | High (12) | High (12) |
++------------------------+--------------------------+-------------------------+
+| Mitigations | SPMC must be prepared to receive incorrect input |
+| | data from secure partitions and reject them |
+| | appropriately. |
+| | The use of software (canaries) or hardware |
+| | hardening techniques (XN, WXN, pointer |
+| | authentication) helps detecting and stopping |
+| | an exploitation early. |
++------------------------+----------------------------------------------------+
+| Mitigations | Yes. The TF-A SPMC mitigates this threat by |
+| implemented? | implementing stack protector, pointer |
+| | authentication, XN, WXN, security hardening |
+| | techniques. |
++------------------------+----------------------------------------------------+
+
++------------------------+----------------------------------------------------+
+| ID | 07 |
++========================+====================================================+
+| Threat | **A malicious endpoint may forge a direct message |
+| | request such that it reveals the internal state of |
+| | another endpoint through the direct message |
+| | response.** |
+| | |
+| | The secure partition or SPMC replies to a partition|
+| | message by a direct message response with |
+| | information which may reveal its internal state |
+| | (e.g. partition message response outside of |
+| | allowed bounds). |
++------------------------+----------------------------------------------------+
+| Diagram Elements | DF1, DF2, DF3 |
++------------------------+----------------------------------------------------+
+| Affected TF-A | SPMC |
+| Components | |
++------------------------+----------------------------------------------------+
+| Assets | SPMC or SP state |
++------------------------+----------------------------------------------------+
+| Threat Agent | NS-Endpoint, S-Endpoint |
++------------------------+----------------------------------------------------+
+| Threat Type | Information discolure |
++------------------------+--------------------------+-------------------------+
+| Application | Server | Mobile |
++------------------------+--------------------------+-------------------------+
+| Impact | Medium (3) | Medium (3) |
++------------------------+--------------------------+-------------------------+
+| Likelihood | Low (2) | Low (2) |
++------------------------+--------------------------+-------------------------+
+| Total Risk Rating | Medium (6) | Medium (6) |
++------------------------+--------------------------+-------------------------+
+| Mitigations | Follow FF-A specification about state transitions, |
+| | run time model, do input validation. |
++------------------------+----------------------------------------------------+
+| Mitigations | Yes. For the specific case of direct requests |
+| implemented? | targeting the SPMC, the latter is hardened to |
+| | prevent its internal state or the state of an SP |
+| | to be revealed through a direct message response. |
+| | Further FF-A v1.1 guidance about run time models |
+| | and partition states is followed. |
++------------------------+----------------------------------------------------+
+
++------------------------+----------------------------------------------------+
+| ID | 08 |
++========================+====================================================+
+| Threat | **Probing the FF-A communication between |
+| | endpoints.** |
+| | |
+| | SPMC and SPs are typically loaded to external |
+| | memory (protected by a TrustZone memory |
+| | controller). A malicious agent may use non invasive|
+| | methods to probe the external memory bus and |
+| | extract the traffic between an SP and the SPMC or |
+| | among SPs when shared buffers are held in external |
+| | memory. |
++------------------------+----------------------------------------------------+
+| Diagram Elements | DF7 |
++------------------------+----------------------------------------------------+
+| Affected TF-A | SPMC |
+| Components | |
++------------------------+----------------------------------------------------+
+| Assets | SP/SPMC state, SP/SPMC secrets |
++------------------------+----------------------------------------------------+
+| Threat Agent | Hardware attack |
++------------------------+----------------------------------------------------+
+| Threat Type | Information disclosure |
++------------------------+--------------------------+-------------------------+
+| Application | Server | Mobile |
++------------------------+--------------------------+-------------------------+
+| Impact | Medium (3) | Medium (3) |
++------------------------+--------------------------+-------------------------+
+| Likelihood | Low (2) | Medium (3) |
++------------------------+--------------------------+-------------------------+
+| Total Risk Rating | Medium (6) | Medium (9) |
++------------------------+--------------------------+-------------------------+
+| Mitigations | Implement DRAM protection techniques using |
+| | hardware countermeasures at platform or chip level.|
++------------------------+--------------------------+-------------------------+
+| Mitigations | Platform specific. |
+| implemented? | |
++------------------------+----------------------------------------------------+
+
++------------------------+----------------------------------------------------+
+| ID | 09 |
++========================+====================================================+
+| Threat | **A malicious agent may attempt revealing the SPMC |
+| | state or secrets by the use of software-based cache|
+| | side-channel attack techniques.** |
++------------------------+----------------------------------------------------+
+| Diagram Elements | DF7 |
++------------------------+----------------------------------------------------+
+| Affected TF-A | SPMC |
+| Components | |
++------------------------+----------------------------------------------------+
+| Assets | SP or SPMC state |
++------------------------+----------------------------------------------------+
+| Threat Agent | NS-Endpoint, S-Endpoint |
++------------------------+----------------------------------------------------+
+| Threat Type | Information disclosure |
++------------------------+--------------------------+-------------------------+
+| Application | Server | Mobile |
++------------------------+--------------------------+-------------------------+
+| Impact | Medium (3) | Medium (3) |
++------------------------+--------------------------+-------------------------+
+| Likelihood | Low (2) | Low (2) |
++------------------------+--------------------------+-------------------------+
+| Total Risk Rating | Medium (6) | Medium (6) |
++------------------------+--------------------------+-------------------------+
+| Mitigations | The SPMC may be hardened further with SW |
+| | mitigations (e.g. speculation barriers) for the |
+| | cases not covered in HW. Usage of hardened |
+| | compilers and appropriate options, code inspection |
+| | are recommended ways to mitigate Spectre types of |
+| | attacks. |
++------------------------+----------------------------------------------------+
+| Mitigations | No. |
+| implemented? | |
++------------------------+----------------------------------------------------+
+
+
++------------------------+----------------------------------------------------+
+| ID | 10 |
++========================+====================================================+
+| Threat | **A malicious endpoint may attempt flooding the |
+| | SPMC with requests targeting a service within an |
+| | endpoint such that it denies another endpoint to |
+| | access this service.** |
+| | |
+| | Similarly, the malicious endpoint may target a |
+| | a service within an endpoint such that the latter |
+| | is unable to request services from another |
+| | endpoint. |
++------------------------+----------------------------------------------------+
+| Diagram Elements | DF1, DF2, DF3 |
++------------------------+----------------------------------------------------+
+| Affected TF-A | SPMC |
+| Components | |
++------------------------+----------------------------------------------------+
+| Assets | SPMC state, Scheduling cycles |
++------------------------+----------------------------------------------------+
+| Threat Agent | NS-Endpoint, S-Endpoint |
++------------------------+----------------------------------------------------+
+| Threat Type | Denial of service |
++------------------------+--------------------------+-------------------------+
+| Application | Server | Mobile |
++------------------------+--------------------------+-------------------------+
+| Impact | Medium (3) | Medium (3) |
++------------------------+--------------------------+-------------------------+
+| Likelihood | Medium (3) | Medium (3) |
++------------------------+--------------------------+-------------------------+
+| Total Risk Rating | Medium (9) | Medium (9) |
++------------------------+--------------------------+-------------------------+
+| Mitigations | Bounding the time for operations to complete can |
+| | be achieved by the usage of a trusted watchdog. |
+| | Other quality of service monitoring can be achieved|
+| | in the SPMC such as counting a number of operations|
+| | in a limited timeframe. |
++------------------------+----------------------------------------------------+
+| Mitigations | Platform specific. |
+| implemented? | |
++------------------------+----------------------------------------------------+
+
++------------------------+----------------------------------------------------+
+| ID | 11 |
++========================+====================================================+
+| Threat | **Denying a lender endpoint to make progress if |
+| | borrower endpoint encountered a fatal exception. |
+| | Denying a new sender endpoint to make progress |
+| | if receiver encountered a fatal exception.** |
++------------------------+----------------------------------------------------+
+| Diagram Elements | DF1, DF2, DF3 |
++------------------------+----------------------------------------------------+
+| Affected TF-A | SPMC |
+| Components | |
++------------------------+----------------------------------------------------+
+| Assets | Shared resources, Scheduling cycles. |
++------------------------+----------------------------------------------------+
+| Threat Agent | NS-Endpoint, S-Endpoint |
++------------------------+----------------------------------------------------+
+| Threat Type | Denial of service |
++------------------------+--------------------------+-------------------------+
+| Application | Server | Mobile |
++------------------------+--------------------------+-------------------------+
+| Impact | Medium (3) | Medium (3) |
++------------------------+--------------------------+-------------------------+
+| Likelihood | Medium (3) | Medium (3) |
++------------------------+--------------------------+-------------------------+
+| Total Risk Rating | Medium (9) | Medium (9) |
++------------------------+--------------------------+-------------------------+
+| Mitigations | SPMC must be able to detect fatal error in SP and |
+| | take ownership of shared resources. It should |
+| | be able to relinquish the access to shared memory |
+| | regions to allow lender to proceed. |
+| | SPMC must return ABORTED if new direct requests are|
+| | targeted to SP which has had a fatal error. |
++------------------------+----------------------------------------------------+
+| Mitigations | Platform specific. |
+| implemented? | |
++------------------------+----------------------------------------------------+
+
++------------------------+----------------------------------------------------+
+| ID | 12 |
++========================+====================================================+
+| Threat | **A malicious endpoint may attempt to donate, |
+| | share, lend, relinquish or reclaim unauthorized |
+| | memory region.** |
++------------------------+----------------------------------------------------+
+| Diagram Elements | DF1, DF2, DF3 |
++------------------------+----------------------------------------------------+
+| Affected TF-A | SPMC |
+| Components | |
++------------------------+----------------------------------------------------+
+| Assets | SP secrets, SPMC secrets, SP state, SPMC state |
++------------------------+----------------------------------------------------+
+| Threat Agent | NS-Endpoint, S-Endpoint |
++------------------------+----------------------------------------------------+
+| Threat Type | Elevation of Privilege |
++------------------------+--------------------------+-------------------------+
+| Application | Server | Mobile |
++------------------------+--------------------------+-------------------------+
+| Impact | High (4) | High (4) |
++------------------------+--------------------------+-------------------------+
+| Likelihood | High (4) | High (4) |
++------------------------+--------------------------+-------------------------+
+| Total Risk Rating | High (16) | High (16) |
++------------------------+--------------------------+-------------------------+
+| Mitigations | Follow FF-A specification guidelines |
+| | on Memory management transactions. |
++------------------------+----------------------------------------------------+
+| Mitigations | Yes. The SPMC tracks ownership and access state |
+| implemented? | for memory transactions appropriately, and |
+| | validating the same for all operations. |
+| | SPMC follows FF-A v1.1 |
+| | guidance for memory transaction lifecycle. |
++------------------------+----------------------------------------------------+
+
+---------------
+
+*Copyright (c) 2022-2024, Arm Limited. All rights reserved.*
+
+.. _Arm Firmware Framework for Arm A-profile: https://developer.arm.com/docs/den0077/latest
+.. _FF-A ACS: https://github.com/ARM-software/ff-a-acs/releases
diff --git a/docs/threat_model/firmware_threat_model/threat_model_fvp_r.rst b/docs/threat_model/firmware_threat_model/threat_model_fvp_r.rst
new file mode 100644
index 0000000..0b71bf0
--- /dev/null
+++ b/docs/threat_model/firmware_threat_model/threat_model_fvp_r.rst
@@ -0,0 +1,99 @@
+fvp_r-Platform Threat Model
+***************************
+
+************************
+Introduction
+************************
+This document provides a threat model for TF-A fvp_r platform.
+
+************************
+Target of Evaluation
+************************
+In this threat model, the target of evaluation is the fvp_r platform of Trusted
+Firmware for A-class Processors (TF-A). The fvp_r platform provides limited
+support of AArch64 R-class Processors (v8-R64).
+
+This is a delta document, only pointing out differences from the general TF-A
+threat-model document, :ref:`Generic Threat Model`
+
+BL1 Only
+========
+The most fundamental difference between the threat model for the current fvp_r
+implementation compared to the general TF-A threat model, is that fvp_r is
+currently limited to BL1 only. Any threats from the general TF-A threat model
+unrelated to BL1 are therefore not relevant to the fvp_r implementation.
+
+The fvp_r BL1 implementation directly loads a customer/partner-defined runtime
+system. The threat model for that runtime system, being partner-defined, is
+out-of-scope for this threat-model.
+
+Relatedly, all exceptions, synchronous and asynchronous, are disabled during BL1
+execution. So, any references to exceptions are not relevant.
+
+EL3 is Unsupported and All Secure
+=================================
+v8-R64 cores do not support EL3, and (essentially) all operation is defined as
+Secure-mode. Therefore:
+
+ - Any threats regarding NS operation are not relevant.
+
+ - Any mentions of SMCs are also not relevant.
+
+ - Anything otherwise-relevant code running in EL3 is instead run in EL2.
+
+MPU instead of MMU
+==================
+v8-R64 cores, running in EL2, use an MPU for memory management, rather than an
+MMU. The MPU in the fvp_r implementation is configured to function effectively
+identically with the MMU for the usual BL1 implementation. There are
+memory-map differences, but the MPU configuration is functionally equivalent.
+
+No AArch32 Support
+==================
+Another substantial difference between v8-A and v8-R64 cores is that v8-R64 does
+not support AArch32. However, this is not believed to have any threat-modeling
+ramifications.
+
+
+Threat Assessment
+=================
+For this section, please reference the Threat Assessment under the general TF-A
+threat-model document, :ref:`Generic Threat Model`
+
+The following threats from that document are still relevant to the fvp_r
+implementation:
+
+ - ID 01: An attacker can mangle firmware images to execute arbitrary code.
+
+ - ID 03: An attacker can use Time-of-Check-Time-of-Use (TOCTOU) attack to
+ bypass image authentication during the boot process.
+
+ - ID 04: An attacker with physical access can execute arbitrary image by
+ bypassing the signature verification stage using clock- or power-glitching
+ techniques.
+
+ - ID 05: Information leak via UART logs such as crashes
+
+ - ID 06: An attacker can read sensitive data and execute arbitrary code
+ through the external debug and trace interface.
+
+ - ID 08: 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.
+
+ - ID 11: Misconfiguration of the Memory Protection Unit (MPU) may allow
+ normal world software to access sensitive data or execute arbitrary code.
+ Arguably, MPUs having fewer memory regions, there may be a temptation to
+ share memory regions, making this a greater threat. However, since the
+ fvp_r implementation is limited to BL1, since BL1's regions are fixed,
+ and since the MPU configuration is equivalent with that for the fvp
+ platform and others, this is not expected to be a concern.
+
+ - ID 15: Improper handling of input data received over a UART interface may
+ allow an attacker to tamper with TF-A execution environment.
+
+
+--------------
+
+*Copyright (c) 2021-2024, Arm Limited. All rights reserved.*
diff --git a/docs/threat_model/firmware_threat_model/threat_model_fw_update_and_recovery.rst b/docs/threat_model/firmware_threat_model/threat_model_fw_update_and_recovery.rst
new file mode 100644
index 0000000..7b55c74
--- /dev/null
+++ b/docs/threat_model/firmware_threat_model/threat_model_fw_update_and_recovery.rst
@@ -0,0 +1,103 @@
+Threat Model for TF-A with PSA FWU or TBBR FWU support
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Introduction
+************
+
+This document provides a threat model of TF-A firmware for platforms with
+the feature PSA firmware update or TBBR firmware update or both enabled.
+To understand the design of the firmware update refer
+:ref:`Firmware Update (FWU)`.
+
+Although it is a separate document, it references the :ref:`Generic Threat
+Model` in a number of places, as some of the contents are applicable to this
+threat model.
+
+Target of Evaluation
+********************
+
+In this threat model, the target of evaluation is the Trusted Firmware for
+A-class Processors (TF-A) when PSA FWU support is enabled or TBBR FWU mode
+is enabled. This includes the boot ROM (BL1), the trusted boot firmware (BL2).
+
+Threat Assessment
+*****************
+
+For this section, please reference the Threat Assessment under the
+:ref:`Generic Threat Model`. Here only the differences are highlighted.
+
+PSA FWU
+*******
+
+Threats to be Mitigated by the Boot Firmware
+--------------------------------------------
+
+The following table analyses the :ref:`Boot Firmware Threats` in the context
+of this threat model. Only additional details are pointed out.
+
++----+-------------+-------------------------------------------------------+
+| ID | Applicable? | Comments |
++====+=============+=======================================================+
+| 01 | Yes | | Attacker can use arbitrary images to update the |
+| | | system. |
++----+-------------+-------------------------------------------------------+
+| 02 | Yes | | Attacker tries to update the system with the |
+| | | vulnerable/older firmware. |
++----+-------------+-------------------------------------------------------+
+| 03 | Yes | |
++----+-------------+-------------------------------------------------------+
+| 04 | Yes | |
++----+-------------+-------------------------------------------------------+
+
+
+Threats to be mitigated by platform design
+------------------------------------------
+
+PSA FWU is driven by metadata stored in non-volatile storage. This metadata
+is not cryptographically signed. Also, depending on the hardware design,
+it may be stored in untrusted storage, which makes it possible for software
+outside of TF-A security boundary or for a physical attacker to modify it
+in order to change the behaviour of the FWU process.
+
+Below we provide some possible FWU metadata corruption scenarios:
+
+1. The FWU metadata includes the firmware bank for booting; the attacker
+ tries to modify it to prevent the execution of the updated firmware.
+2. The FWU metadata features a field indicating the firmware's status, either
+ in trial run or accepted run. The attacker tries to manipulate this field,
+ ensuring the updated firmware consistently runs in trial mode, with the
+ intention of preventing the anti-rollback update.
+
+By design, no software mitigations exist to prevent this. The safeguarding
+of FWU metadata relies on the platform's hardware design to mitigate potential
+attacks on it, if this is a concern in the platform's threat model.
+For example, FWU metadata may be stored in secure storage under exclusive
+access from secure software, protecting it from physical, unauthenticated
+accesses and from non-secure software accesses.
+
+TBBR FWU - Firmware Recovery
+****************************
+
+Threats to be Mitigated by the Boot Firmware
+--------------------------------------------
+
+The following table analyses the :ref:`Boot Firmware Threats` in the context
+of this threat model. Only additional details are pointed out.
+
++----+-------------+-------------------------------------------------------+
+| ID | Applicable? | Comments |
++====+=============+=======================================================+
+| 01 | Yes | | Attacker can use arbitrary images to recover the |
+| | | system. |
++----+-------------+-------------------------------------------------------+
+| 02 | Yes | | Attacker tries to recover the system with the |
+| | | vulnerable/older firmware. |
++----+-------------+-------------------------------------------------------+
+| 03 | Yes | |
++----+-------------+-------------------------------------------------------+
+| 04 | Yes | |
++----+-------------+-------------------------------------------------------+
+
+--------------
+
+*Copyright (c) 2024, Arm Limited. All rights reserved.*
diff --git a/docs/threat_model/firmware_threat_model/threat_model_rss_interface.rst b/docs/threat_model/firmware_threat_model/threat_model_rss_interface.rst
new file mode 100644
index 0000000..025d2d9
--- /dev/null
+++ b/docs/threat_model/firmware_threat_model/threat_model_rss_interface.rst
@@ -0,0 +1,59 @@
+Threat Model for RSS - AP interface
+***********************************
+
+************
+Introduction
+************
+This document is an extension for the general TF-A threat-model. It considers
+those platforms where a Runtime Security Subsystem (RSS) is included in the SoC
+next to the Application Processor (AP).
+
+********************
+Target of Evaluation
+********************
+The scope of this threat model only includes the interface between the RSS and
+AP. Otherwise, the TF-A :ref:`Generic Threat Model` document is applicable for
+the AP core. The threat model for the RSS firmware will be provided by the RSS
+firmware project in the future.
+
+
+Data Flow Diagram
+=================
+This diagram is different only from the general TF-A data flow diagram in that
+it includes the RSS and highlights the interface between the AP and the RSS
+cores. The interface description only focuses on the AP-RSS interface the rest
+is the same as in the general TF-A threat-model document.
+
+.. uml:: ../../resources/diagrams/plantuml/tfa_rss_dfd.puml
+ :caption: Figure 1: TF-A Data Flow Diagram including RSS
+
+.. table:: Table 1: TF-A - RSS data flow diagram
+
+ +-----------------+--------------------------------------------------------+
+ | Diagram Element | Description |
+ +=================+========================================================+
+ | DF7 | | Boot images interact with RSS over a communication |
+ | | channel to record boot measurements and get image |
+ | | verification keys. At runtime, BL31 obtains the |
+ | | realm world attestation signing key from RSS. |
+ +-----------------+--------------------------------------------------------+
+
+Threat Assessment
+=================
+For this section, please reference the Threat Assessment under the general TF-A
+threat-model document, :ref:`Generic Threat Model`. All the threats listed there
+are applicable for the AP core, here only the differences are highlighted.
+
+ - ID 11: The access to the communication interface between AP and RSS is
+ allowed only for firmware running at EL3. Accidentally exposing this
+ interface to NSCode can allow malicious code to interact with RSS and
+ gain access to sensitive data.
+ - ID 13: Relevant in the context of the realm attestation key, which can be
+ retrieved by BL31 through DF7. The RSS communication protocol layer
+ mitigates against this by clearing its internal buffer when reply is
+ received. The caller of the API must do the same if data is not needed
+ anymore.
+
+--------------
+
+*Copyright (c) 2022-2024, Arm Limited. All rights reserved.*