Docs: Add a generic threat model of TF-M
Add a generic threat model document of TF-M.
Create a dedicated folder under docs to contain threat models.
Change-Id: Ifb332d20e1667082d054959bb7d890eda5ce025d
Signed-off-by: David Hu <david.hu@arm.com>
diff --git a/docs/index.rst b/docs/index.rst
index 59dfb30..1318d1a 100644
--- a/docs/index.rst
+++ b/docs/index.rst
@@ -89,6 +89,7 @@
docs/reference/index
docs/design_documents/index
platform/ext/index
+ docs/threat_models/index
.. toctree::
diff --git a/docs/threat_models/TF-M-block-diagram.png b/docs/threat_models/TF-M-block-diagram.png
new file mode 100644
index 0000000..e5d0371
--- /dev/null
+++ b/docs/threat_models/TF-M-block-diagram.png
Binary files differ
diff --git a/docs/threat_models/generic_thread_model.rst b/docs/threat_models/generic_thread_model.rst
new file mode 100644
index 0000000..dbbf605
--- /dev/null
+++ b/docs/threat_models/generic_thread_model.rst
@@ -0,0 +1,1095 @@
+#######################################
+Trusted Firmware-M Generic Threat Model
+#######################################
+
+************
+Introduction
+************
+
+This document introduces a generic thread model of Trusted Firmware-M (TF-M).
+This generic thread model provides an overall analysis of TF-M implementation
+and identifies general threats and mitigation.
+
+.. note::
+
+ If you think a security vulnerability is found, please follow
+ Trustedfirmware.org [Security-Incident-Process]_ to contact TF-M security
+ team.
+
+Scope
+=====
+
+TF-M supports diverse models and topologies. It also implements multiple
+isolation levels. Each case may focus on different target of evaluation (TOE)
+and identify different assets and threats.
+TF-M implementation consists of several secure services, defined as
+Root of Trust (RoT) service. Those RoT services belong to diverse RoT
+(Application RoT or PSA RoT) and access different assets and hardware. Therefore
+each RoT service may require a dedicated threat model.
+
+The analysis on specific models, topologies or RoT services may be covered in
+dedicated thread model documents. Those threat models are out of the scope of
+this document.
+
+Methodology
+===========
+
+The threat modeling in this document follows the process listed below to
+build up the threat model.
+
+- Target of Evaluation (TOE)
+- Assets identification
+- Data Flow Diagram (DFD)
+- Threats Prioritization
+- Threats identification
+
+TOE is the entity on which threat modeling is performed. The logic behind this
+process is to firstly investigate the TOE which could be a system, solution or
+use case. This first step helps to identify the assets to be protected in TOE.
+
+According to TOE and assets, Trust Boundaries can be determined. The Data Flow
+Diagram (DFD) across Trust Boundaries is then defined to help identify the
+threats.
+
+Those threats should be prioritized based on a specific group of principals and
+metrics. The principals and metrics should also be specified.
+
+********************
+Target of Evaluation
+********************
+
+A typical TF-M system diagram from a high-level overview is shown below. TF-M is
+running in the Secure Processing Environment (SPE) and NS software is running in
+Non-secure Processing Environment (NSPE). For more details, please refer to
+Platform Security Architecture Firmware Framework for M (FF-M) [FF-M]_.
+
+.. figure:: TF-M-block-diagram.png
+
+The TOE in this general model is the SPE, including TF-M and other components
+running in SPE.
+
+The TOE can vary in different TF-M models, RoT services and usage scenarios.
+Refer to dedicated thread models for the specific TOE definitions.
+
+********************
+Asset identification
+********************
+
+In this threat model, assets include the general items listed below:
+
+- Hardware Root of Trust data, e.g.
+
+ - Hardware Unique Key (HUK)
+ - Root authentication key
+ - Other embedded root keys
+
+- Software RoT data, e.g.
+
+ - Secure Partition Manager (SPM) code and data
+ - Secure partition code and data
+ - NSPE data stored in SPE
+ - Data generated in SPE as requested by NSPE
+
+- Availability of entire RoT service
+
+- Secure logs, including event logs
+
+Assets may vary in different use cases and implementations. Additional assets
+can be defined in an actual usage scenario and a dedicated threat model.
+
+For example, in a network camera use case, the following data can be defined as
+assets too:
+
+- Certificate for connecting to cloud
+- Session keys for encryption/decryption in the communication with cloud
+- Keys to encrypt/decrypt the videos and photos
+
+*****************
+Data Flow Diagram
+*****************
+
+The Trust Boundary isolates SPE from NSPE, according to the TOE definition in
+`Target of Evaluation`_. The Trust Boundary mapped to block diagram is shown
+in the figure below. Other modules inside SPE stay in the same TOE as TF-M does.
+
+Valid Data flows across the Trust Boundary are also shown in the figure below.
+This thread model only focuses on the data flows related to TF-M.
+
+.. figure:: overall-DFD.png
+
+More details of data flows are listed below.
+
+.. _data-flow-table:
+
+.. table:: TF-M Data Flows between NSPE and SPE
+
+ +-----------+----------------------------------------------------------------+
+ | Data flow | Description |
+ +===========+================================================================+
+ | ``DF1`` | TF-M initializes NS entry and activates NSPE. |
+ | | |
+ | | - On single Armv8-M core platforms, TF-M will hand over the |
+ | | control to Non-secure state. |
+ | | - On dual-cpu platforms, Secure core starts NS core booting. |
+ +-----------+----------------------------------------------------------------+
+ | ``DF2`` | NSPE requests TF-M RoT services. |
+ | | |
+ | | - In TF-M Library model, NS invokes Secure Function calls |
+ | | - In TF-M IPC model, NS invokes PSA Client calls based on IPC |
+ | | protocol defined in [FF-M]_. |
+ | | |
+ | | In single Armv8-M core scenarios, SG instruction is executed |
+ | | in Non-secure Callable region to trigger a transition from |
+ | | Non-secure state to Secure state. |
+ | | |
+ | | On dual-cpu platforms, non-secure core sends PSA Client calls |
+ | | to secure core via mailbox. |
+ +-----------+----------------------------------------------------------------+
+ | ``DF3`` | Secure Partitions fetch input data from NS and write back |
+ | | output data to NS. |
+ | | |
+ | | In TF-M IPC model, as required in [FF-M]_, Secure Partitions |
+ | | should not directly access NSPE memory. Instead, RoT services |
+ | | relies on TF-M SPM to access NSPE memory. |
+ +-----------+----------------------------------------------------------------+
+ | ``DF4`` | TF-M returns RoT service results to NSPE after NS request to |
+ | | RoT service is completed. |
+ | | |
+ | | In single Armv8-M core scenarios, it also trigger a transition |
+ | | from Secure state back to Non-secure state. |
+ | | |
+ | | On dual-cpu platforms, secure core returns the result to |
+ | | non-secure core via mailbox. |
+ +-----------+----------------------------------------------------------------+
+ | ``DF5`` | Non-secure interrupts preempt SPE execution in single Armv8-M |
+ | | core scenarios. |
+ +-----------+----------------------------------------------------------------+
+ | ``DF6`` | Secure interrupts preempt NSPE execution in single Armv8-M |
+ | | core scenarios. |
+ +-----------+----------------------------------------------------------------+
+
+.. note::
+
+ All the other data flows across the Trusted Boundary besides the valid ones
+ mentioned above should be prohibited by default.
+ Proper isolation must be configured to prevent NSPE directly accessing SPE.
+
+ Threats irrelevant to data flows in
+ :ref:`TF-M Data Flows between NSPE and SPE <data-flow-table>` may be specified
+ in `Miscellaneous threats`_.
+
+Data flows inside SPE (informative)
+===================================
+
+Since all the SPE components stay in the TOE within the same Trust Boundary in
+this threat model, the data flows between SPE components are not covered in this
+threat model. Instead, those data flows and corresponding threats will be
+identified in the dedicated threat model documents of TF-M RoT services and
+usage scenarios.
+
+Those data flows inside SPE include following examples:
+
+- Data flows between TF-M and BL2
+- Data flows between RoT services and SPM
+- Data flows between RoT services and corresponding secure hardware and assets,
+ such as secure storage device, crypto hardware accelerator and Hardware Unique
+ Key (HUK).
+
+*********************
+Threat identification
+*********************
+
+Threat priority
+===============
+
+Threat priority is indicated by the score calculated via Common Vulnerability
+Scoring System (CVSS) Version 3.1 [CVSS]_. The higher the threat scores, the
+greater severity the threat is with and the higher the priority is.
+
+CVSS scores can be mapped to qualitative severity ratings defined in CVSS 3.1
+specification [CVSS_SPEC]_. This threat model follows the same mapping between
+CVSS scores and threat priority rating.
+
+As a generic threat model, this document focuses on *Base Score* which reflects
+the constant and general severity of a threat according to its intrinsic
+characteristics.
+
+The *Impacted Component* defined in [CVSS_SPEC]_ refers to the assets listed in
+`Asset identification`_.
+
+Threats and mitigation list
+===========================
+
+This section lists generic threats and corresponding mitigation, based on the
+the analysis of data flows in `Data Flow Diagram`_.
+
+Threats are identified following ``STRIDE`` model. Please refer to [STRIDE]_ for
+more details.
+
+The field ``CVSS Score`` reflects the threat priority defined in
+`Threat priority`_. The field ``CVSS Vector String`` contains the textual
+representation of the CVSS metric values used to score the threat. Refer to
+[CVSS_SPEC]_ for more details of CVSS vector string.
+
+.. note::
+
+ A generic threat may have different behaviors and therefore require different
+ mitigation, in diverse TF-M models and usage scenarios.
+
+ This threat model document focuses on general analysis of the following
+ threats. For the details in a specific configuration and usage scenario,
+ please refer to the dedicated threat model document.
+
+NS entry initialization
+-----------------------
+
+This section identifies threats on ``DF1`` defined in `Data Flow Diagram`_.
+
+.. table:: TFM-GENERIC-NS-INIT-T-1
+ :widths: 10 50
+
+ +---------------+------------------------------------------------------------+
+ | Index | **TFM-GENERIC-NS-INIT-T-1** |
+ +---------------+------------------------------------------------------------+
+ | Description | The NS image can be tampered by an attacker |
+ +---------------+------------------------------------------------------------+
+ | Justification | An attack may tamper the NS image to inject malicious code |
+ +---------------+------------------------------------------------------------+
+ | Category | Tampering |
+ +---------------+------------------------------------------------------------+
+ | Mitigation | By default TF-M relies on MCUBoot to validate NS image. |
+ | | The validation of NS image integrity and authenticity is |
+ | | completed in secure boot before jumping to NS entry or |
+ | | booting up NS core. |
+ | | Refer to [SECURE-BOOT]_ for more details. |
+ | | |
+ | | The validation may vary in diverse vendor platforms |
+ | | specific Chain of Trust (CoT) implementation. |
+ +---------------+------------------------------------------------------------+
+ | CVSS Score | 3.5 (Low) |
+ +---------------+------------------------------------------------------------+
+ | CVSS Vector | CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N |
+ | String | |
+ +---------------+------------------------------------------------------------+
+
+.. table:: TFM-GENERIC-NS-INIT-T-2
+ :widths: 10 50
+
+ +---------------+------------------------------------------------------------+
+ | Index | **TFM-GENERIC-NS-INIT-T-2** |
+ +---------------+------------------------------------------------------------+
+ | Description | An attacker may replace the current NS image with an older |
+ | | version. |
+ +---------------+------------------------------------------------------------+
+ | Justification | The attacker downgrades the NS image with an older version |
+ | | which has been deprecated due to known security issues. |
+ | | |
+ | | The older version image can pass the image signature |
+ | | validation and its vulnerabilities can be exploited by |
+ | | attackers. |
+ +---------------+------------------------------------------------------------+
+ | Category | Tampering |
+ +---------------+------------------------------------------------------------+
+ | Mitigation | TF-M relies on MCUBoot to perform anti-rollback |
+ | | protection. |
+ | | |
+ | | TF-M defines a non-volatile counter API to support |
+ | | anti-rollback. Each platform must implement it using |
+ | | specific trusted hardware non-volatile counters. |
+ | | For more details, refer to [ROLLBACK-PROTECT]_. |
+ | | |
+ | | The anti-rollback protection implementation can vary on |
+ | | diverse platforms. |
+ +---------------+------------------------------------------------------------+
+ | CVSS Score | 3.5 (Low) |
+ +---------------+------------------------------------------------------------+
+ | CVSS Vector | CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N |
+ | String | |
+ +---------------+------------------------------------------------------------+
+
+.. table:: TFM-GENERIC-NS-INIT-T-I-1
+ :widths: 10 50
+
+ +---------------+------------------------------------------------------------+
+ | Index | **TFM-GENERIC-NS-INIT-T-I-1** |
+ +---------------+------------------------------------------------------------+
+ | Description | If SPE doesn't complete isolation configuration before |
+ | | NSPE starts, NSPE can access secure regions which it is |
+ | | disallowed to. |
+ +---------------+------------------------------------------------------------+
+ | Justification | Secure data can be tampered or disclosed if NSPE is |
+ | | activated and accesses secure regions before isolation |
+ | | configuration is completed by SPE. |
+ +---------------+------------------------------------------------------------+
+ | Category | Tampering/Information disclosure |
+ +---------------+------------------------------------------------------------+
+ | Mitigation | SPE must complete and enable proper isolation to protect |
+ | | secure regions from being accessed by NSPE, before jumping |
+ | | to NS entry or booting up NS core. |
+ | | |
+ | | TF-M executes isolation configuration at early stage of |
+ | | secure initialization before NS initialization starts. |
+ | | |
+ | | On dual-cpu platform, platform specific initialization |
+ | | must halt NS core until isolation is completed, as defined |
+ | | in [DUAL-CPU-BOOT]_. |
+ | | |
+ | | TF-M defines isolation configuration HALs for platform |
+ | | implementation. The specific isolation configuration |
+ | | depends on platform specific implementation. |
+ +---------------+------------------------------------------------------------+
+ | CVSS Score | 9.0 (Critical) |
+ +---------------+------------------------------------------------------------+
+ | CVSS Vector | CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N |
+ | String | |
+ +---------------+------------------------------------------------------------+
+
+.. table:: TFM-GENERIC-NS-INIT-T-I-2
+ :widths: 10 50
+
+ +---------------+------------------------------------------------------------+
+ | Index | **TFM-GENERIC-NS-INIT-T-I-2** |
+ +---------------+------------------------------------------------------------+
+ | Description | If SPE doesn't complete isolation configuration before |
+ | | NSPE starts, NSPE can control devices or peripherals which |
+ | | it is disallowed to. |
+ +---------------+------------------------------------------------------------+
+ | Justification | On some platforms, devices and peripherals can be |
+ | | configured as Secure state in runtime. If security status |
+ | | configuration of those device and peripherals are not |
+ | | properly completed before NSPE starts, NSPE can control |
+ | | those device and peripherals and may be able to tamper |
+ | | data or access secure data. |
+ +---------------+------------------------------------------------------------+
+ | Category | Tampering/Information disclosure |
+ +---------------+------------------------------------------------------------+
+ | Mitigation | SPE must complete and enable proper configuration and |
+ | | isolation to protect critical devices and peripherals from |
+ | | being accessed by NSPE, before jumping to NS entry or |
+ | | booting up NS core. |
+ | | |
+ | | TF-M executes isolation configuration of devices and |
+ | | peripherals at early stage of secure initialization before |
+ | | NS initialization starts. |
+ | | |
+ | | The specific isolation configuration depends on platform |
+ | | specific implementation. |
+ +---------------+------------------------------------------------------------+
+ | CVSS Score | 9.0 (Critical) |
+ +---------------+------------------------------------------------------------+
+ | CVSS Vector | CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N |
+ | String | |
+ +---------------+------------------------------------------------------------+
+
+.. table:: TFM-GENERIC-NS-INIT-I-2
+ :widths: 10 50
+
+ +---------------+------------------------------------------------------------+
+ | Index | **TFM-GENERIC-NS-INIT-I-2** |
+ +---------------+------------------------------------------------------------+
+ | Description | If SPE leaves some SPE information in non-secure memory |
+ | | or shared registers when NSPE starts, NSPE may access |
+ | | those SPE information. |
+ +---------------+------------------------------------------------------------+
+ | Justification | If NSPE can access those SPE information from shared |
+ | | registers or non-secure memory, secure information may be |
+ | | disclosed. |
+ +---------------+------------------------------------------------------------+
+ | Category | Information disclosure |
+ +---------------+------------------------------------------------------------+
+ | Mitigation | SPE must clean up the secure information from shared |
+ | | registers before NS starts. |
+ | | |
+ | | TF-M invalidates registers not banked before handing over |
+ | | the system to NSPE on single Armv8-M platform. |
+ | | |
+ | | On dual-cpu platforms, shared registers are implementation |
+ | | defined, such as Inter-Processor Communication registers. |
+ | | Dual-cpu platforms must not store any data which may |
+ | | disclose secure information in the shared registers. |
+ | | |
+ | | SPE must avoid storing SPE information in non-secure |
+ | | memory. |
+ +---------------+------------------------------------------------------------+
+ | CVSS Score | 4.3 (Medium) |
+ +---------------+------------------------------------------------------------+
+ | CVSS Vector | CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N |
+ | String | |
+ +---------------+------------------------------------------------------------+
+
+.. table:: TFM-GENERIC-NS-INIT-D-1
+ :widths: 10 50
+
+ +---------------+------------------------------------------------------------+
+ | Index | **TFM-GENERIC-NS-INIT-D-1** |
+ +---------------+------------------------------------------------------------+
+ | Description | An attacker may block NS to boot up |
+ +---------------+------------------------------------------------------------+
+ | Justification | An attacker may block NS to boot up, such as by corrupting |
+ | | NS image, to stop the whole system from performing normal |
+ | | functionalities. |
+ +---------------+------------------------------------------------------------+
+ | Category | Denial of service |
+ +---------------+------------------------------------------------------------+
+ | Mitigation | No SPE information will be disclosed and TF-M won't be |
+ | | directly impacted. |
+ | | |
+ | | It relies on NSPE and platform specific implementation to |
+ | | mitigate this threat. It is out of scope of this threat |
+ | | model. |
+ +---------------+------------------------------------------------------------+
+ | CVSS Score | 4.0 (Medium) |
+ +---------------+------------------------------------------------------------+
+ | CVSS Vector | CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L |
+ | String | |
+ +---------------+------------------------------------------------------------+
+
+NSPE requests TF-M secure service
+---------------------------------
+
+This section identifies threats on ``DF2`` defined in `Data Flow Diagram`_.
+
+.. table:: TFM-GENERIC-REQUEST-SERVICE-S-1
+ :widths: 10 50
+
+ +---------------+------------------------------------------------------------+
+ | Index | **TFM-GENERIC-REQUEST-SERVICE-S-1** |
+ +---------------+------------------------------------------------------------+
+ | Description | A malicious NS application may pretend as a secure client |
+ | | to access secure data which NSPE must not directly access. |
+ +---------------+------------------------------------------------------------+
+ | Justification | [FF-M]_ defines ``Client ID`` to distinguish clients which |
+ | | request RoT services. Secure clients are assigned with |
+ | | positive IDs and non-secure clients are assigned with |
+ | | negative ones. |
+ | | |
+ | | A malicious NS application may provide a positive |
+ | | ``Client ID`` to pretend as a secure client to access |
+ | | secure data. |
+ +---------------+------------------------------------------------------------+
+ | Category | Spoofing |
+ +---------------+------------------------------------------------------------+
+ | Mitigation | TF-M checks the ``Client ID`` from NSPE. If the NS |
+ | | ``Client ID`` is not a valid one, TF-M will report this as |
+ | | a security error. |
+ +---------------+------------------------------------------------------------+
+ | CVSS Score | 8.4 (High) |
+ +---------------+------------------------------------------------------------+
+ | CVSS Vector | CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N |
+ | String | |
+ +---------------+------------------------------------------------------------+
+
+.. table:: TFM-GENERIC-REQUEST-SERVICE-T-1
+ :widths: 10 50
+
+ +---------------+------------------------------------------------------------+
+ | Index | **TFM-GENERIC-REQUEST-SERVICE-T-1** |
+ +---------------+------------------------------------------------------------+
+ | Description | An attacker in NSPE may tamper the service request input |
+ | | or output vectors between check and use |
+ | | (Time-Of-Check-to-Time-Of-Use (TOCTOU)). |
+ +---------------+------------------------------------------------------------+
+ | Justification | If SPE validates the content in input/output vectors |
+ | | locally in NSPE memory, an attacker in NSPE can have a |
+ | | chance to tamper the content after the validation |
+ | | successfully passes. Then SPE will provide RoT service |
+ | | according to the corrupted parameters and it may cause |
+ | | further security issues. |
+ +---------------+------------------------------------------------------------+
+ | Category | Tampering |
+ +---------------+------------------------------------------------------------+
+ | Mitigation | In TF-M implementation, the validation of NS input/output |
+ | | vectors are only executed after those vectors are copied |
+ | | from NSPE into SPE. It prevents an attack from NSPE to |
+ | | tamper those parameters after validation in TF-M. |
+ +---------------+------------------------------------------------------------+
+ | CVSS Score | 7.8 (High) |
+ +---------------+------------------------------------------------------------+
+ | CVSS Vector | CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N |
+ | String | |
+ +---------------+------------------------------------------------------------+
+
+.. table:: TFM-GENERIC-REQUEST-SERVICE-T-2
+ :widths: 10 50
+
+ +---------------+------------------------------------------------------------+
+ | Index | **TFM-GENERIC-REQUEST-SERVICE-T-2** |
+ +---------------+------------------------------------------------------------+
+ | Description | A malicious NS application may request to tamper data |
+ | | belonging to SPE. |
+ +---------------+------------------------------------------------------------+
+ | Justification | A malicious NS application may request SPE RoT services to |
+ | | write malicious value to SPE data. The malicious NS |
+ | | application may try to tamper SPE assets, such as keys, or |
+ | | modify configurations in SPE. The SPE data belongs to |
+ | | components in SPE and must not be accessed by NSPE. |
+ +---------------+------------------------------------------------------------+
+ | Category | Tampering |
+ +---------------+------------------------------------------------------------+
+ | Mitigation | TF-M executes memory access check to all the RoT service |
+ | | requests. If a request doesn't have enough permission to |
+ | | access the target memory region, TF-M will refuse this |
+ | | request and assert a security error. |
+ +---------------+------------------------------------------------------------+
+ | CVSS Score | 7.1 (High) |
+ +---------------+------------------------------------------------------------+
+ | CVSS Vector | CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:N |
+ | String | |
+ +---------------+------------------------------------------------------------+
+
+.. table:: TFM-GENERIC-REQUEST-SERVICE-R-1
+ :widths: 10 50
+
+ +---------------+------------------------------------------------------------+
+ | Index | **TFM-GENERIC-REQUEST-SERVICE-R-1** |
+ +---------------+------------------------------------------------------------+
+ | Description | A NS application may repudiate that it has requested |
+ | | services from a RoT service. |
+ +---------------+------------------------------------------------------------+
+ | Justification | A malicious NS application may call a RoT service to |
+ | | access critical data in SPE, which it is disallowed to, |
+ | | via a non-public vulnerability. It may refuse to admit |
+ | | that it has accessed that data. |
+ +---------------+------------------------------------------------------------+
+ | Category | Repudiation |
+ +---------------+------------------------------------------------------------+
+ | Mitigation | TF-M implements an event logging secure service to record |
+ | | the critical events, such as the access to critical data. |
+ +---------------+------------------------------------------------------------+
+ | CVSS Score | 0.0 (None) |
+ +---------------+------------------------------------------------------------+
+ | CVSS Vector | CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:N |
+ | String | |
+ +---------------+------------------------------------------------------------+
+
+.. table:: TFM-GENERIC-REQUEST-SERVICE-I-1
+ :widths: 10 50
+
+ +---------------+------------------------------------------------------------+
+ | Index | **TFM-GENERIC-REQUEST-SERVICE-I-1** |
+ +---------------+------------------------------------------------------------+
+ | Description | A malicious NS application may request to read data |
+ | | belonging to SPE. |
+ +---------------+------------------------------------------------------------+
+ | Justification | A malicious NS application may request SPE RoT services to |
+ | | copy SPE data to NS memory. The SPE data belongs to |
+ | | components in SPE and must not be disclosed to NSPE, such |
+ | | as root keys. |
+ +---------------+------------------------------------------------------------+
+ | Category | Information disclosure |
+ +---------------+------------------------------------------------------------+
+ | Mitigation | TF-M executes memory access check to all the RoT service |
+ | | requests. If a request doesn't have enough permission to |
+ | | access the target memory region, TF-M will refuse this |
+ | | request and assert a security error. |
+ +---------------+------------------------------------------------------------+
+ | CVSS Score | 7.1 (High) |
+ +---------------+------------------------------------------------------------+
+ | CVSS Vector | CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N |
+ | String | |
+ +---------------+------------------------------------------------------------+
+
+.. table:: TFM-GENERIC-REQUEST-SERVICE-T-I-1
+ :widths: 10 50
+
+ +---------------+------------------------------------------------------------+
+ | Index | **TFM-GENERIC-REQUEST-SERVICE-T-I-1** |
+ +---------------+------------------------------------------------------------+
+ | Description | A malicious NS application may request to control secure |
+ | | device and peripherals, on which it doesn't have the |
+ | | permission. |
+ +---------------+------------------------------------------------------------+
+ | Justification | A malicious NS application may request RoT services to |
+ | | control secure device and peripherals, on which it doesn't |
+ | | have the permission. |
+ +---------------+------------------------------------------------------------+
+ | Category | Tampering/Information disclose |
+ +---------------+------------------------------------------------------------+
+ | Mitigation | TF-M performs client check to validate whether the client |
+ | | has the permission to access the secure device and |
+ | | peripherals. |
+ +---------------+------------------------------------------------------------+
+ | CVSS Score | 9.0 (Critical) |
+ +---------------+------------------------------------------------------------+
+ | CVSS Vector | CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N |
+ | String | |
+ +---------------+------------------------------------------------------------+
+
+.. table:: TFM-GENERIC-REQUEST-SERVICE-D-1
+ :widths: 10 50
+
+ +---------------+------------------------------------------------------------+
+ | Index | **TFM-GENERIC-REQUEST-SERVICE-D-1** |
+ +---------------+------------------------------------------------------------+
+ | Description | A Malicious NS applications may frequently call secure |
+ | | services to block secure service requests from other NS |
+ | | applications. |
+ +---------------+------------------------------------------------------------+
+ | Justification | TF-M runs on IoT devices with constrained resource. Even |
+ | | though multiple outstanding NS PSA Client calls can be |
+ | | supported in system, the number of NS PSA client calls |
+ | | served by TF-M simultaneously are still limited. |
+ | | |
+ | | Therefore, if a malicious NS application or multiple |
+ | | malicious NS applications continue calling TF-M secure |
+ | | services frequently, it may block other NS applications to |
+ | | request secure service from TF-M. |
+ +---------------+------------------------------------------------------------+
+ | Category | Denial of service |
+ +---------------+------------------------------------------------------------+
+ | Mitigation | TF-M is unable to manage behavior of NS applications. |
+ | | Assets are not disclosed and TF-M is neither directly |
+ | | impacted in this threat. |
+ | | |
+ | | It relies on NS OS to enhance scheduling policy and |
+ | | prevent a single NS application to occupy entire CPU time. |
+ | | It is beyond the scope of this threat model. |
+ +---------------+------------------------------------------------------------+
+ | CVSS Score | 4.0 (Medium) |
+ +---------------+------------------------------------------------------------+
+ | CVSS Vector | CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L |
+ | String | |
+ +---------------+------------------------------------------------------------+
+
+.. table:: TFM-GENERIC-REQUEST-SERVICE-D-2
+ :widths: 10 50
+
+ +---------------+------------------------------------------------------------+
+ | Index | **TFM-GENERIC-REQUEST-SERVICE-D-2** |
+ +---------------+------------------------------------------------------------+
+ | Description | A malicious NS application may provide invalid NS memory |
+ | | addresses as the addresses of input and output data in RoT |
+ | | service requests. |
+ +---------------+------------------------------------------------------------+
+ | Justification | SPE may be unable to achieve full knowledge of NS memory |
+ | | mapping. SPE may fail to capture those invalid NS memory |
+ | | addresses during memory access check since those invalid |
+ | | addresses may not be included in isolation configuration. |
+ | | |
+ | | In that case, SPE will access those invalid NS memory |
+ | | addresses later to read or write data. It may trigger a |
+ | | system error to crash the whole system immediately. |
+ | | |
+ | | The malicious NS application may be blocked by NS MPU from |
+ | | directly accessing that invalid NS memory address. But it |
+ | | may manipulate SPE to access that address instead. |
+ +---------------+------------------------------------------------------------+
+ | Category | Denial of service |
+ +---------------+------------------------------------------------------------+
+ | Mitigation | TF-M executes memory access check to the memory addresses |
+ | | in all the NS requests. |
+ | | |
+ | | On single Armv8-M core platforms, TF-M invokes ``TT`` |
+ | | instructions to execute memory address check. If a NS |
+ | | memory area is not matched in any valid SAU or MPU region, |
+ | | it will be marked as invalid and any access permission is |
+ | | disallowed. Therefore, SPM will reject any NS request |
+ | | containing invalid NS memory addresses and reports it as |
+ | | as a security error. |
+ | | |
+ | | On dual-core platforms, TF-M implements a default memory |
+ | | access check. If a NS memory area is not found in any |
+ | | memory region configured for isolation, it will be marked |
+ | | as invalid and therefore SPM will reject the corresponding |
+ | | NS request. It will be reported as a security error. |
+ | | |
+ | | Dual-core platforms may implement platform specific memory |
+ | | check to replace the default one. It relies on platform |
+ | | specific implementation to capture invalid memory address. |
+ | | It is out of the scope of this document. |
+ +---------------+------------------------------------------------------------+
+ | CVSS Score | 3.2 (Low) |
+ +---------------+------------------------------------------------------------+
+ | CVSS Vector | CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:N/I:N/A:L |
+ | String | |
+ +---------------+------------------------------------------------------------+
+
+RoT services read and write NS data
+-----------------------------------
+
+This section identifies threats on ``DF3`` defined in `Data Flow Diagram`_.
+
+According to [FF-M]_, in TF-M IPC model, RoT services should rely on TF-M SPM to
+obtain NS input data and send response data back to NS memory.
+
+In Library model, RoT services directly read and write NS memory to simplify the
+implementation and decrease latency.
+
+.. _TFM-GENERIC-SECURE-SERVICE-RW-T-1:
+
+.. table:: TFM-GENERIC-SECURE-SERVICE-RW-T-1
+ :widths: 10 50
+
+ +---------------+------------------------------------------------------------+
+ | Index | **TFM-GENERIC-SECURE-SERVICE-RW-T-1** |
+ +---------------+------------------------------------------------------------+
+ | Description | An attacker may tamper NS input data while the RoT service |
+ | | is processing those data. |
+ +---------------+------------------------------------------------------------+
+ | Justification | A RoT service may access NS input data multiple times |
+ | | during its data processing. For example, it may validate |
+ | | or authenticate the NS input data before it performs |
+ | | further processing. |
+ | | |
+ | | If the NS input data remains in NSPE memory during the RoT |
+ | | service execution, an attacker may tamper the NS input |
+ | | data in NSPE memory after the validation passes. |
+ +---------------+------------------------------------------------------------+
+ | Category | Tampering |
+ +---------------+------------------------------------------------------------+
+ | Mitigation | In TF-M IPC model, RoT services request SPM to read and |
+ | | write NS data. TF-M SPM follows [FF-M]_ to copy the NS |
+ | | input data into SPE memory region owned by the RoT |
+ | | service, before the RoT service processes the data. |
+ | | Therefore, the NS input data is protected during the RoT |
+ | | service execution from being tampered. |
+ | | |
+ | | In TF-M Library model, RoT services can directly access NS |
+ | | memory. If a RoT service accesses NS input data multiple |
+ | | times during data processing, it is required to review and |
+ | | confirm Library model implementation of the RoT service |
+ | | copies NS input data into SPE memory area before it |
+ | | processes the data. |
+ +---------------+------------------------------------------------------------+
+ | CVSS Score | 3.2 (Low) |
+ +---------------+------------------------------------------------------------+
+ | CVSS Vector | CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:N/I:L/A:N |
+ | String | |
+ +---------------+------------------------------------------------------------+
+
+.. _TFM-GENERIC-SECURE-SERVICE-RW-T-2:
+
+.. table:: TFM-GENERIC-SECURE-SERVICE-RW-T-2
+ :widths: 10 50
+
+ +---------------+------------------------------------------------------------+
+ | Index | **TFM-GENERIC-SECURE-SERVICE-RW-T-2** |
+ +---------------+------------------------------------------------------------+
+ | Description | A malicious NS application may embed secure memory |
+ | | addresses into a structure in RoT service request input |
+ | | vectors, to tamper secure memory which the NS application |
+ | | must not access. |
+ +---------------+------------------------------------------------------------+
+ | Justification | [FF-M]_ limits the total number of input/output vectors to |
+ | | 4. If a RoT service requires more input/output vectors, it |
+ | | may define a parameter structure which embeds multiple |
+ | | input/output buffers addresses. |
+ | | |
+ | | However, as a potential security risk, a malicious NS |
+ | | application can put secure memory addresses into a valid |
+ | | parameter structure to bypass TF-M validation on those |
+ | | memory addresses. |
+ | | |
+ | | The parameter structure can pass TF-M memory access check |
+ | | since itself is valid. However, if the RoT service parses |
+ | | the structure and directly write malicious data from NSPE |
+ | | to the secure memory addresses in parameter structure, the |
+ | | secure data will be tampered. |
+ +---------------+------------------------------------------------------------+
+ | Category | Tampering |
+ +---------------+------------------------------------------------------------+
+ | Mitigation | It should be avoided to embed memory addresses into a |
+ | | single input/output vector. If more than 4 memory |
+ | | addresses are required in a RoT service request, it is |
+ | | recommended to split this request into two or multiple |
+ | | service calls and therefore each service call requires no |
+ | | more than 4 input/output vectors. |
+ | | |
+ | | In TF-M IPC model, RoT services request SPM to read and |
+ | | write NS data. SPM will validate the target addresses and |
+ | | can detect the invalid addresses to mitigate this threat. |
+ | | |
+ | | In TF-M Library model, RoT services can directly access NS |
+ | | memory. It is required to review and confirm Library model |
+ | | implementation of RoT service request doesn't embed memory |
+ | | addresses. |
+ +---------------+------------------------------------------------------------+
+ | CVSS Score | 6.3 (Medium) |
+ +---------------+------------------------------------------------------------+
+ | CVSS Vector | CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:N/I:H/A:N |
+ | String | |
+ +---------------+------------------------------------------------------------+
+
+.. table:: TFM-GENERIC-SECURE-SERVICE-RW-I-1
+ :widths: 10 50
+
+ +---------------+------------------------------------------------------------+
+ | Index | **TFM-GENERIC-SECURE-SERVICE-RW-I-1** |
+ +---------------+------------------------------------------------------------+
+ | Description | Similar to TFM-GENERIC-SECURE-SERVICE-RW-T-2_, a malicious |
+ | | NS application can embed secure memory addresses in a |
+ | | parameter structure in RoT service request input vectors, |
+ | | to read secure data which the NS application must not |
+ | | access. |
+ +---------------+------------------------------------------------------------+
+ | Justification | Similar to the description in |
+ | | TFM-GENERIC-SECURE-SERVICE-RW-T-2_, the secure memory |
+ | | addresses hidden in the RoT service input/output vector |
+ | | structure may bypass TF-M validation. Without a proper |
+ | | check, the RoT service may copy secure data to NSPE |
+ | | according to the secure memory addresses in structure, |
+ | | secure information can be disclosed. |
+ +---------------+------------------------------------------------------------+
+ | Category | Information disclosure |
+ +---------------+------------------------------------------------------------+
+ | Mitigation | It should be avoided to embed memory addresses into a |
+ | | single input/output vector. If more than 4 memory |
+ | | addresses are required in a RoT service request, it is |
+ | | recommended to split this request into two or multiple |
+ | | service calls and therefore each service call requires no |
+ | | more than 4 input/output vectors. |
+ | | |
+ | | In TF-M IPC model, RoT services request SPM to read and |
+ | | write NS data. SPM will validate the target addresses and |
+ | | can detect the invalid addresses to mitigate this threat. |
+ | | |
+ | | In TF-M Library model, RoT services can directly access NS |
+ | | memory. It is required to review and confirm Library model |
+ | | implementation of RoT service request doesn't embed memory |
+ | | addresses. |
+ +---------------+------------------------------------------------------------+
+ | CVSS Score | 6.3 (Medium) |
+ +---------------+------------------------------------------------------------+
+ | CVSS Vector | CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N |
+ | String | |
+ +---------------+------------------------------------------------------------+
+
+TF-M returns secure service result
+----------------------------------
+
+This section identifies threats on ``DF4`` defined in `Data Flow Diagram`_.
+
+When RoT service completes the request from NSPE, TF-M returns the success or
+failure error code to NS application.
+
+In single Armv8-M core scenario, TF-M writes the return code value in the
+general purpose register and returns to Non-secure state.
+
+On dual-cpu platforms, TF-M writes the return code to NSPE mailbox message queue
+via mailbox.
+
+.. table:: TFM-GENERIC-RETURN-CODE-I-1
+ :widths: 10 50
+
+ +---------------+------------------------------------------------------------+
+ | Index | **TFM-GENERIC-RETURN-CODE-I-1** |
+ +---------------+------------------------------------------------------------+
+ | Description | SPE may leave secure data in the registers not banked |
+ | | after the SPE completes PSA Client calls and executes |
+ | | ``BXNS`` to switch Armv8-M back to Non-secure state. |
+ +---------------+------------------------------------------------------------+
+ | Justification | If SPE doesn't clean up the secure data in registers not |
+ | | banked before switching into NSPE in Armv8-M core, NSPE |
+ | | can read the SPE context from those registers. |
+ +---------------+------------------------------------------------------------+
+ | Category | Information disclosure |
+ +---------------+------------------------------------------------------------+
+ | Mitigation | In single Armv8-M core scenario, TF-M cleans general |
+ | | purpose registers not banked before switching into NSPE to |
+ | | prevent NSPE probing secure context from the registers. |
+ | | |
+ | | Current TF-M implementation doesn't support FPU in SPE. |
+ | | TF-M build will stop if FPU is enabled on platform. |
+ | | Therefore, FPU registers doesn't contain data that needs |
+ | | to be protected from NSPE. |
+ +---------------+------------------------------------------------------------+
+ | CVSS Score | 4.3 (Medium) |
+ +---------------+------------------------------------------------------------+
+ | CVSS Vector | CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N |
+ | String | |
+ +---------------+------------------------------------------------------------+
+
+NS interrupts preempts SPE execution
+------------------------------------
+
+This section identifies threats on ``DF5`` defined in `Data Flow Diagram`_.
+
+.. table:: TFM-GENERIC-NS-INTERRUPT-I-1
+ :widths: 10 50
+
+ +---------------+------------------------------------------------------------+
+ | Index | **TFM-GENERIC-NS-INTERRUPT-I-1** |
+ +---------------+------------------------------------------------------------+
+ | Description | Shared registers may contain secure data when NS |
+ | | interrupts occur. |
+ +---------------+------------------------------------------------------------+
+ | Justification | The secure data in shared registers should be cleaned up |
+ | | before NSPE can access shared registers. Otherwise, secure |
+ | | data leakage may occur. |
+ +---------------+------------------------------------------------------------+
+ | Category | Information disclosure |
+ +---------------+------------------------------------------------------------+
+ | Mitigation | In single Armv8-M core scenario, Armv8-M architecture |
+ | | automatically cleans up the registers not banked before |
+ | | switching to Non-secure state while taking NS interrupts. |
+ | | |
+ | | Current TF-M implementation doesn't support FPU in SPE. |
+ | | TF-M build will stop if FPU is enabled on platform. |
+ | | Therefore, FPU registers doesn't contain data that needs |
+ | | to be protected from NSPE. |
+ | | |
+ | | On dual-cpu platforms, shared registers are implementation |
+ | | defined, such as Inter-Processor Communication registers. |
+ | | Dual-cpu platforms must not store any data which may |
+ | | disclose secure information in the shared registers. |
+ +---------------+------------------------------------------------------------+
+ | CVSS Score | 4.3 (Medium) |
+ +---------------+------------------------------------------------------------+
+ | CVSS Vector | CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N |
+ | String | |
+ +---------------+------------------------------------------------------------+
+
+.. table:: TFM-GENERIC-NS-INTERRUPT-D-1
+ :widths: 10 50
+
+ +---------------+------------------------------------------------------------+
+ | Index | **TFM-GENERIC-NS-INTERRUPT-D-1** |
+ +---------------+------------------------------------------------------------+
+ | Description | An attacker may trigger spurious NS interrupts frequently |
+ | | to block SPE execution. |
+ +---------------+------------------------------------------------------------+
+ | Justification | In single Armv8-M core scenario, an attacker may inject a |
+ | | malicious NS application or hijack a NS hardware to |
+ | | frequently trigger spurious NS interrupts to keep |
+ | | preempting SPE and block SPE to perform normal secure |
+ | | execution. |
+ +---------------+------------------------------------------------------------+
+ | Category | Denial of service |
+ +---------------+------------------------------------------------------------+
+ | Mitigation | It is out of scope of TF-M. |
+ | | |
+ | | Assets protected by TF-M won't be leaked. TF-M won't be |
+ | | directly impacted. |
+ +---------------+------------------------------------------------------------+
+ | CVSS Score | 4.0 (Medium) |
+ +---------------+------------------------------------------------------------+
+ | CVSS Vector | CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L |
+ | String | |
+ +---------------+------------------------------------------------------------+
+
+Secure interrupts preempts NSPE execution
+-----------------------------------------
+
+This section identifies threats on ``DF6`` defined in `Data Flow Diagram`_.
+
+.. table:: TFM-GENERIC-S-INTERRUPT-I-1
+ :widths: 10 50
+
+ +---------------+------------------------------------------------------------+
+ | Index | **TFM-GENERIC-S-INTERRUPT-I-1** |
+ +---------------+------------------------------------------------------------+
+ | Description | Shared registers may contain secure data when Armv8-M core |
+ | | switches back to Non-secure state on Secure interrupt |
+ | | return. |
+ +---------------+------------------------------------------------------------+
+ | Justification | Armv8-M architecture doesn't automatically clean up shared |
+ | | registers while returning to Non-secure state during |
+ | | Secure interrupt return. |
+ | | |
+ | | If SPE leaves critical data in the Armv8-M registers not |
+ | | banked, NSPE can read secure context from those registers |
+ | | and secure data leakage may occur. |
+ +---------------+------------------------------------------------------------+
+ | Category | Information disclosure |
+ +---------------+------------------------------------------------------------+
+ | Mitigation | TF-M saves NPSE context in general purpose register R4~R11 |
+ | | into secure stack during secure interrupt entry. |
+ | | After secure interrupt handling completes, TF-M unstacks |
+ | | NSPE context from secure stack to overwrite secure context |
+ | | in R4~R11 before secure interrupt return. |
+ | | |
+ | | Armv8-M architecture will automatically unstack NSPE |
+ | | context from non-secure stack to overwrite other registers |
+ | | not banked, such as R0~R3 and R12, during secure interrupt |
+ | | return, before NSPE software can access those registers. |
+ | | |
+ | | Current TF-M implementation doesn't support FPU in SPE. |
+ | | TF-M build will stop if FPU is enabled on platform. |
+ | | Therefore, FPU registers doesn't contain data that needs |
+ | | to be protected from NSPE. |
+ +---------------+------------------------------------------------------------+
+ | CVSS Score | 4.3 (Medium) |
+ +---------------+------------------------------------------------------------+
+ | CVSS Vector | CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N |
+ | String | |
+ +---------------+------------------------------------------------------------+
+
+Miscellaneous threats
+---------------------
+
+This section collects threats irrelevant to the valid TF-M data flows shown
+above.
+
+.. table:: TFM-GENERIC-STACK-SEAL
+ :widths: 10 50
+
+ +---------------+------------------------------------------------------------+
+ | Index | **TFM-GENERIC-STACK_SEAL** |
+ +---------------+------------------------------------------------------------+
+ | Description | Armv8-M processor Secure software Stack Sealing |
+ | | vulnerability. |
+ +---------------+------------------------------------------------------------+
+ | Justification | On Armv8-M based processors with TrustZone, if Secure |
+ | | software does not properly manage the Secure stacks when |
+ | | the stacks are created, or when performing non-standard |
+ | | transitioning between states or modes, for example, |
+ | | creating a fake exception return stack frame to |
+ | | de-privilege an interrupt, it is possible for Non-secure |
+ | | world software to manipulate the Secure Stacks, and |
+ | | potentially influence Secure control flow. |
+ | | |
+ | | Refer to [STACK-SEAL]_ for details. |
+ +---------------+------------------------------------------------------------+
+ | Category | Elevation of privilege |
+ +---------------+------------------------------------------------------------+
+ | Mitigation | TF-M has implemented common mitigation against stack seal |
+ | | vulnerability. |
+ | | |
+ | | Refer to [ADVISORY-TFMV-1]_ for details on analysis and |
+ | | mitigation in TF-M. |
+ +---------------+------------------------------------------------------------+
+ | CVSS Score | 5.3 (Medium) |
+ +---------------+------------------------------------------------------------+
+ | CVSS Vector | CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:L |
+ | String | |
+ +---------------+------------------------------------------------------------+
+
+***************
+Version control
+***************
+
+.. table:: Version control
+
+ +---------+--------------------------------------------------+---------------+
+ | Version | Description | TF-M version |
+ +=========+==================================================+===============+
+ | v0.1 | Initial draft | TF-M v1.1 |
+ +---------+--------------------------------------------------+---------------+
+
+*********
+Reference
+*********
+
+.. [Security-Incident-Process] `Security Incident Process <https://developer.trustedfirmware.org/w/collaboration/security_center/reporting/>`_
+
+.. [FF-M] `Arm® Platform Security Architecture Firmware Framework 1.0 <https://developer.arm.com/-/media/Files/pdf/PlatformSecurityArchitecture/Architect/DEN0063-PSA_Firmware_Framework-1.0.0-2.pdf?revision=2d1429fa-4b5b-461a-a60e-4ef3d8f7f4b4>`_
+
+.. [DUAL-CPU-BOOT] :doc:`Booting a dual core system </docs/design_documents/dual-cpu/booting_a_dual_core_system>`
+
+.. [CVSS] `Common Vulnerability Scoring System Version 3.1 Calculator <https://www.first.org/cvss/calculator/3.1>`_
+
+.. [CVSS_SPEC] `CVSS v3.1 Specification Document <https://www.first.org/cvss/v3-1/cvss-v31-specification_r1.pdf>`_
+
+.. [STRIDE] `The STRIDE Threat Model <https://docs.microsoft.com/en-us/previous-versions/commerce-server/ee823878(v=cs.20)?redirectedfrom=MSDN>`_
+
+.. [SECURE-BOOT] :doc:`Secure boot </docs/getting_started/tfm_secure_boot>`
+
+.. [ROLLBACK-PROTECT] :doc:`Rollback protection in TF-M secure boot </docs/design_documents/secure_boot_rollback_protection>`
+
+.. [STACK-SEAL] `Armv8-M processor Secure software Stack Sealing vulnerability <https://developer.arm.com/support/arm-security-updates/armv8-m-stack-sealing>`_
+
+.. [ADVISORY-TFMV-1] :doc:`Advisory TFMV-1 </docs/reference/security_advisories/stack_seal_vulnerability>`
+
+--------------------
+
+*Copyright (c) 2020 Arm Limited. All Rights Reserved.*
diff --git a/docs/threat_models/index.rst b/docs/threat_models/index.rst
new file mode 100644
index 0000000..227d4d4
--- /dev/null
+++ b/docs/threat_models/index.rst
@@ -0,0 +1,12 @@
+Threat Models
+=============
+
+.. toctree::
+ :maxdepth: 1
+ :glob:
+
+ *
+
+--------------
+
+*Copyright (c) 2020, Arm Limited. All rights reserved.*
diff --git a/docs/threat_models/overall-DFD.png b/docs/threat_models/overall-DFD.png
new file mode 100644
index 0000000..39cf4c8
--- /dev/null
+++ b/docs/threat_models/overall-DFD.png
Binary files differ
