aboutsummaryrefslogtreecommitdiff
path: root/docs/security
diff options
context:
space:
mode:
authorSummer Qin <summer.qin@arm.com>2021-04-06 17:22:15 +0800
committerSummer Qin <summer.qin@arm.com>2021-04-21 10:34:53 +0800
commitabf6698dd6b916de5aea971783aa80776bf296dd (patch)
tree7e1727767491c52d7bce438d2bf88c89fb05da78 /docs/security
parentcdaec9c383182052b8535b74e92a4799b98236cd (diff)
downloadtrusted-firmware-m-abf6698dd6b916de5aea971783aa80776bf296dd.tar.gz
Docs: Restructure the documents
Restructure the file category to let it more friendly to users. Signed-off-by: Summer Qin <summer.qin@arm.com> Change-Id: I7ced0e2d700ce03423e472e0098608f3445ba169
Diffstat (limited to 'docs/security')
-rw-r--r--docs/security/index.rst12
-rw-r--r--docs/security/security.rst65
-rw-r--r--docs/security/security_advisories/index.rst12
-rw-r--r--docs/security/security_advisories/stack_seal_vulnerability.rst113
-rw-r--r--docs/security/security_advisories/svc_caller_sp_fetching_vulnerability.rst125
-rw-r--r--docs/security/threat_models/TF-M-block-diagram.pngbin0 -> 124526 bytes
-rw-r--r--docs/security/threat_models/generic_threat_model.rst1130
-rw-r--r--docs/security/threat_models/index.rst12
-rw-r--r--docs/security/threat_models/overall-DFD.pngbin0 -> 17954 bytes
9 files changed, 1469 insertions, 0 deletions
diff --git a/docs/security/index.rst b/docs/security/index.rst
new file mode 100644
index 0000000000..22bdcba82a
--- /dev/null
+++ b/docs/security/index.rst
@@ -0,0 +1,12 @@
+Security
+========
+.. toctree::
+ :maxdepth: 1
+ :glob:
+
+ */index
+ *
+
+--------------
+
+*Copyright (c) 2021, Arm Limited. All rights reserved.*
diff --git a/docs/security/security.rst b/docs/security/security.rst
new file mode 100644
index 0000000000..bab72f2fa4
--- /dev/null
+++ b/docs/security/security.rst
@@ -0,0 +1,65 @@
+Security Handling
+=================
+
+Security Disclosures
+--------------------
+
+Trusted Firmware-M(TF-M) disclose all security vulnerabilities, or are advised
+about, that are relevant to TF-M. TF-M encourage responsible disclosure of
+vulnerabilities and try the best to inform users about all possible issues.
+
+The TF-M vulnerabilities are disclosed as Security Advisories, all of which are
+listed at the bottom of this page.
+
+Found a Security Issue?
+-----------------------
+
+Although TF-M try to keep secure, it can only do so with the help of the
+community of developers and security researchers.
+
+.. warning::
+ If any security vulnerability was found, please **do not**
+ report it in the `issue tracker`_ or on the `mailing list`_. Instead, please
+ follow the `TrustedFirmware.org security incident process`_.
+
+One of the goals of this process is to ensure providers of products that use
+TF-M have a chance to consider the implications of the vulnerability and its
+remedy before it is made public. As such, please follow the disclosure plan
+outlined in the `Security Incident Process`_. TF-M do the best to respond and
+fix any issues quickly.
+
+Afterwards, write-up all the findings about the TF-M source code is highly
+encouraged.
+
+Attribution
+-----------
+
+TF-M values researchers and community members who report vulnerabilities and
+TF-M policy is to credit the contributor's name in the published security advisory.
+
+Security Advisories
+-------------------
+
++------------+-----------------------------------------------------------------+
+| ID | Title |
++============+=================================================================+
+| |TFMV-1| | NS world may cause the CPU to perform an unexpected return |
+| | operation due to unsealed stacks. |
++------------+-----------------------------------------------------------------+
+| |TFMV-2| | Invoking Secure functions from handler mode may cause TF-M IPC |
+| | model to behave unexpectedly. |
++------------+-----------------------------------------------------------------+
+
+.. _issue tracker: https://developer.trustedfirmware.org/project/view/2/
+.. _mailing list: https://lists.trustedfirmware.org/mailman/listinfo/tf-m
+
+.. |TFMV-1| replace:: :ref:`docs/security/security_advisories/stack_seal_vulnerability:Advisory TFMV-1`
+.. |TFMV-2| replace:: :ref:`docs/security/security_advisories/svc_caller_sp_fetching_vulnerability:Advisory TFMV-2`
+
+.. _TrustedFirmware.org security incident process: https://developer.trustedfirmware.org/w/collaboration/security_center/
+
+.. _Security Incident Process: https://developer.trustedfirmware.org/w/collaboration/security_center/reporting/
+
+--------------
+
+*Copyright (c) 2020-2021, Arm Limited. All rights reserved.*
diff --git a/docs/security/security_advisories/index.rst b/docs/security/security_advisories/index.rst
new file mode 100644
index 0000000000..85119084e2
--- /dev/null
+++ b/docs/security/security_advisories/index.rst
@@ -0,0 +1,12 @@
+Security Advisories
+===================
+
+.. toctree::
+ :maxdepth: 1
+ :glob:
+
+ *
+
+--------------
+
+*Copyright (c) 2020, Arm Limited. All rights reserved.*
diff --git a/docs/security/security_advisories/stack_seal_vulnerability.rst b/docs/security/security_advisories/stack_seal_vulnerability.rst
new file mode 100644
index 0000000000..2bf9d1a254
--- /dev/null
+++ b/docs/security/security_advisories/stack_seal_vulnerability.rst
@@ -0,0 +1,113 @@
+Advisory TFMV-1
+===============
+
++----------------+-------------------------------------------------------------+
+| Title | NS world may cause the CPU to perform an unexpected return |
+| | operation due to unsealed stacks. |
++================+=============================================================+
+| CVE ID | CVE-2020-16273 |
++----------------+-------------------------------------------------------------+
+| Date | 16 October 2020 |
++----------------+-------------------------------------------------------------+
+| Versions | All versions up to and including TF-M v1.1 |
+| Affected | |
++----------------+-------------------------------------------------------------+
+| Configurations | All |
++----------------+-------------------------------------------------------------+
+| Impact | Most likely a crash in secure world with a very low |
+| | likelihood of hijacking secure world execution flow via a |
+| | separate vulnerability. |
++----------------+-------------------------------------------------------------+
+| Fix Version | commit `92e46a3abd0e328fac29ccd1cf161cd482397567`_ |
++----------------+-------------------------------------------------------------+
+| Credit | Matvey Mukha |
++----------------+-------------------------------------------------------------+
+
+Background
+----------
+
+When the Non-Secure world returns to Secure after a callback (FNC_RETURN) or
+Non-Secure interrupt handling (EXC_RETURN), the hardware pops the secure return
+address and RET_PSR from the respective secure stack. The hardware performs a
+set of integrity checks at this point and will raise a fault if the checks
+fail. There is a potential vulnerability if the NS attempts a wrong FNC_RETURN
+or EXC_RETURN and causes the PE to pop from the unexpected stack. Please
+refer to `ARMv8-M Secure stack sealing advisory notice`_ for more
+details on the vulnerability.
+
+To prevent such an attack, the architecture expects the secure software to
+`seal` the stacks. The `ARMv8-M ARM`_ states that the stack should be sealed
+with the special value, 0xFEF5EDA5 (informative IGJGL).
+
+Both the MSP_S and the PSP_S stacks need to be sealed to mitigate stack
+underflow attacks and this is not done currently in TF-M.
+
+Impact
+------
+
+This section analyses the impact of this vulnerability on the upstream
+TF-M implementation.
+
+All requests coming in from the Non-Secure world uses ARM_LIB_STACK as the
+PSP_S and then switches to MSP_S as part of SPM scheduling. The MSP_S is fully
+unwound when the scheduled partition is executing. All partitions run using
+the PSP_S and this stack can be separate for each partition or be a common
+stack depending on whether TF-M is in library mode or IPC mode. When the
+partition execution using PSP_S switches to non-secure world due to a
+non-secure interrupt or a non-secure callback invocation, the non-secure
+world on return back to secure can use a fake EXC_RETURN or FNC_RETURN
+operation to trigger an MSP_S stack underflow, and the CPU could fetch
+the return PC and PSR from the memory just above MSP_S stack (stack grows
+from higher to lower address).
+
+The memory above MSP_S is the ARM_LIB_STACK (as described by
+tfm_common_s.sct/ld), which because of overlaying or zero initialization
+is most likely to be initialized memory for most platforms. This is the stack
+used to run the initialization code of TF-M and usually there will some
+unused free space in the stack. Any underflow of MSP_S will be into this stack
+and hence is likely to be a deterministic crash given that this memory is
+initialized. In theory, a separate vulnerability that allows an attacker to
+control the memory above MSP_S in concert with this vulnerability could
+enable an attacker to hijack the secure world execution flow but the
+likelihood of that is very low.
+
+Through analysing TF-M specific initialization and execution flow, we have
+not found any scenario in TF-M in which Non-secure world can fake a return
+operation back to secure world and cause underflow of PSP_S.
+
+As described in the white paper, de-privileged interrupt handling is
+also vulnerable to this problem. The Library mode of TF-M uses de-privileged
+interrupt handling and does not allow non-secure interrupt to pre-empt the
+secure interrupt handling. But if the de-privileged handler makes a
+Non-Secure callback then there is a chance that Non-Secure world could
+return back to Secure world via a fake FNC_RETURN. Under certain
+conditions, this can force the CPU to use the 2 words on top of stack as
+return PC and PSR. Sealing the top of MSP_S before switching to PSP_S as
+part of de-privileged interrupt handling mitigates this vulnerability.
+
+The interrupt handling in IPC mode uses PSA signal to signal the partition
+and does not use de-privileged interrupt handling mechanism. The PSA signal
+gets handled by the partition when it is scheduled to run by the SPM. Hence
+during interrupt handling in IPC mode, there is no additional threat caused
+by this vulnerability, compared to regular partition execution.
+
+Conclusion
+----------
+
+Overall, from analysis of upstream TF-M implementation, the severity of this
+vulnerability is low, given that the values popped out from secure stack
+(either via underflow of MSP_S or from top of MSP_S stack in de-privileged
+interrupt handling) cannot be influenced by the Non Secure world. To mitigate
+the risk completely, the fix in TF-M is to follow the recommendation in
+`ARMv8-M ARM`_ which is to seal the base of both handler mode stack (MSP_S)
+and thread stacks (PSP_S) and, in case of library mode, also seal the top
+of MSP_S before handing control over to de-privileged interrupt handler.
+
+
+.. _ARMv8-M ARM: https://developer.arm.com/documentation/ddi0553/latest
+.. _ARMv8-M Secure stack sealing advisory notice: https://developer.arm.com/support/arm-security-updates/armv8-m-stack-sealing
+.. _92e46a3abd0e328fac29ccd1cf161cd482397567: https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/commit/?id=92e46a3abd0e328fac29ccd1cf161cd482397567
+
+--------------
+
+*Copyright (c) 2020, Arm Limited. All rights reserved.*
diff --git a/docs/security/security_advisories/svc_caller_sp_fetching_vulnerability.rst b/docs/security/security_advisories/svc_caller_sp_fetching_vulnerability.rst
new file mode 100644
index 0000000000..4a117243fe
--- /dev/null
+++ b/docs/security/security_advisories/svc_caller_sp_fetching_vulnerability.rst
@@ -0,0 +1,125 @@
+Advisory TFMV-2
+===============
+
++----------------+-------------------------------------------------------------+
+| Title | Invoking Secure functions from handler mode may cause TF-M |
+| | IPC model to behave unexpectedly. |
++================+=============================================================+
+| CVE ID | CVE-2021-27562 |
++----------------+-------------------------------------------------------------+
+| Date | Mar 5, 2021 |
++----------------+-------------------------------------------------------------+
+| Versions | Affected All versions up to and including TF-M v1.2 |
+| Affected | |
++----------------+-------------------------------------------------------------+
+| Configurations | IPC Model (TFM_PSA_API=ON) on Armv8-M |
++----------------+-------------------------------------------------------------+
+| Impact | Most likely a crash in secure world or reset whole system, |
+| | with a very low likelihood of overwriting some memory |
+| | contents. |
++----------------+-------------------------------------------------------------+
+| Fix Version | commit `e212ea1637a66255b44d0e7c19ebe9786ab56ccb`_ |
++----------------+-------------------------------------------------------------+
+| Credit | Øyvind Rønningstad, |
+| | Senior SW Engineer from Nordic Semiconductor |
++----------------+-------------------------------------------------------------+
+
+Background
+----------
+
+When a non-secure caller calls the secure function, the execution switches the
+security state via Secure Gateway (SG), then arrived at the TF-M secure entry
+if the SG is successful. After SG, TF-M invokes SVC to SPM at first because SPM
+handles requests from SPE and NSPE in a unified SVC handler. The TF-M SVC
+handler code relies on the 'SPSEL' bit in 'EXC_RETURN' to get the caller stack
+pointer:
+
+.. code-block:: asm
+
+ ; Armv8m mainline as the example
+ mrs r2, msp ; r2 = msp;
+ tst lr, #4 ; EXC_RETURN.SPSEL == ?
+ ite eq ; condition preparation
+ moveq r0, r2 ; if (EXC_RETURN.SPSEL == 0) r0 = msp;
+ movne r0, psp ; if (EXC_RETURN.SPSEL == 1) r0 = psp;
+ mov r1, lr ; r1 = EXC_RETURN;
+ bl tfm_core_svc_handler ; r0 = sp(context), r1 = EXC_RETURN, r2 = msp
+
+If NSPE calls the secure function in 'Handler mode', the TF-M secure entry runs
+in 'Handler mode' before invoking SVC because PE mode does not change during
+the transition from non-secure state to secure state via the successful SG.
+Main stack pointer (MSP) is always used in 'Handler mode', which is irrelevant
+to the value of SPSEL. However, the code above selects secure process stack
+pointer (PSP_S, S suffix here indicates the security state) for further SVC
+handling based on EXC_RETURN.SPSEL, hence the SVC handler accesses the wrong
+stack for handling the request in the NSPE caller in 'Handler mode' case.
+To prevent this vulnerability, TF-M secure SVC handler should fetch the right
+stack pointer register by checking both the PE mode and SPSEL bit. The handler
+should also prevent callers in non-secure `Handler mode` from calling TF-M
+SVC functionalities. The following section analysis impact of the IPC model.
+Library model is not vulnerable to this attack because it checks the PE mode
+in the TF-M secure entry.
+
+Impact
+------
+
+When the vulnerability is happening, PSP_S is the incorrect stack pointer
+fetched, the impact is decided by the content PSP_S is pointing to. The SVC
+handler gets the SVC number by referencing the memory at the 2 bytes subtracted
+position of member 'Return Address' in the PSP_S pointing context, and uses the
+caller saved registers in the context as parameters for the subsequent
+functions indicated by the SVC number. The PSP_S may point to the bottom
+(higher address) of secure thread stack if there is no ongoing secure function
+call, or it points to a preempted context caused by non-secure preempting
+secure execution.
+When PSP_S is pointing to the stack bottom when this issue happens, the caller
+context is pointing to the underflowed stack of which the top 2 words are stack
+seal, and the rest of the context is unpredictable. These underflowed content
+are ZERO initialized for most platforms, hence when fetching the SVC Number at
+memory address 'Return Address - 2', a 'MemFault' or 'HardFault' would happen.
+Even if a valid SVC number is returned, the stack seal values are part of the
+parameters for the subsequent functions that have parameters, which cannot pass
+the validation for the parameters.
+When PSP_S is pointing to a preempted context, the preempted place can be the
+TF-M secure entry area or internal thread space. If the preemption happens when
+the execution is in the TF-M secure entry area, the PSP_S will point to an NS
+preemption stack frame and hence will fail the context size validation through
+this entry into TF-M SVC Handler. In the other scenario that TF-M internal
+thread is preempted, there is a very remote chance that the exception stack
+frame will contain a context with a valid SVC Number with valid parameters.
+As a summary, the impacts of the vulnerability depend on whether an SVC number
+could be fetched from the incorrect stack and what operation the fetched SVC
+number corresponds to:
+
+- A memory access fault when fetching the SVC number from memory. This fault
+ halts the whole system. A reset can recover the system back to normal.
+- The SVC number corresponds to the initialization process in TF-M. SPM
+ initialization is called for the second time. This re-initialization process
+ will fail and halt the whole system. A reset can recover the system back to
+ normal.
+- The SVC number corresponds to the boot data fetching function. If the
+ unpredictable data in stack triggers boot data fetching and passes the
+ parameter validation under a very rare case, boot data is copied into an
+ unpredictable memory address. One note here, the TF-M default boot data has
+ no sensitive information.
+- The SVC number corresponds to the log output function. If the unpredictable
+ data in stack triggers log output under a very rare case, secure data at
+ unpredictable address might be printed out through the log interface.
+- The SVC number corresponds to other valid numbers other than above. The
+ system resets because of parameter validation fail.
+
+Conclusion
+----------
+
+Overall, from the analysis of upstream TF-M implementation, the severity of
+this vulnerability is Medium, given that a software crash or system reset
+happen most of the time. The probability for causing secure data leakage via
+log output or tampering of secure memory with boot data is extremely low as the
+TF-M internal thread exception stack frame contents have to pass all the
+validations performed by SPM.
+
+.. _e212ea1637a66255b44d0e7c19ebe9786ab56ccb: https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/commit/?id=e212ea1637a66255b44d0e7c19ebe9786ab56ccb
+
+--------------
+
+*Copyright (c) 2021, Arm Limited. All rights reserved.*
diff --git a/docs/security/threat_models/TF-M-block-diagram.png b/docs/security/threat_models/TF-M-block-diagram.png
new file mode 100644
index 0000000000..e5d0371e26
--- /dev/null
+++ b/docs/security/threat_models/TF-M-block-diagram.png
Binary files differ
diff --git a/docs/security/threat_models/generic_threat_model.rst b/docs/security/threat_models/generic_threat_model.rst
new file mode 100644
index 0000000000..5659c243ea
--- /dev/null
+++ b/docs/security/threat_models/generic_threat_model.rst
@@ -0,0 +1,1130 @@
+#######################################
+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 | 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-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 | 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 | |
+ +---------------+------------------------------------------------------------+
+
+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 | |
+ +---------------+------------------------------------------------------------+
+
+.. table:: TFM-GENERIC-SVC-CALL-SP-FETCH
+ :widths: 10 50
+
+ +---------------+------------------------------------------------------------+
+ | Index | **TFM-GENERIC-SVC-CALL-SP-FETCH** |
+ +---------------+------------------------------------------------------------+
+ | Description | Invoking Secure functions from handler mode may cause TF-M |
+ | | IPC model to behave unexpectedly. |
+ +---------------+------------------------------------------------------------+
+ | Justification | On Armv8-M based processors with TrustZone, if NSPE calls |
+ | | a secure function via Secure Gateway (SG) from non-secure |
+ | | Handler mode , TF-M selects secure process stack by |
+ | | mistake for SVC handling. |
+ | | It will most likely trigger a crash in secure world or |
+ | | reset the whole system, with a very low likelihood of |
+ | | overwriting some memory contents. |
+ +---------------+------------------------------------------------------------+
+ | Category | Denial of service/Tampering |
+ +---------------+------------------------------------------------------------+
+ | Mitigation | TF-M has enhanced implementation to mitigate this |
+ | | vulnerability. |
+ | | |
+ | | Refer to [ADVISORY-TFMV-2]_ for details on analysis and |
+ | | mitigation in TF-M. |
+ +---------------+------------------------------------------------------------+
+ | CVSS Score | 4.5 (Medium) |
+ +---------------+------------------------------------------------------------+
+ | CVSS Vector | CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:N/I:L/A:L |
+ | String | |
+ +---------------+------------------------------------------------------------+
+
+***************
+Version control
+***************
+
+.. table:: Version control
+
+ +---------+--------------------------------------------------+---------------+
+ | Version | Description | TF-M version |
+ +=========+==================================================+===============+
+ | v0.1 | Initial draft | TF-M v1.1 |
+ +---------+--------------------------------------------------+---------------+
+ | v1.0 | First version | TF-M v1.2.0 |
+ +---------+--------------------------------------------------+---------------+
+
+*********
+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/technical_references/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/technical_references/tfm_secure_boot>`
+
+.. [ROLLBACK-PROTECT] :doc:`Rollback protection in TF-M secure boot </docs/technical_references/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/security/security_advisories/stack_seal_vulnerability>`
+
+.. [ADVISORY-TFMV-2] :doc:`Advisory TFMV-2 </docs/security/security_advisories/svc_caller_sp_fetching_vulnerability>`
+
+--------------------
+
+*Copyright (c) 2020-2021 Arm Limited. All Rights Reserved.*
diff --git a/docs/security/threat_models/index.rst b/docs/security/threat_models/index.rst
new file mode 100644
index 0000000000..227d4d41e1
--- /dev/null
+++ b/docs/security/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/security/threat_models/overall-DFD.png b/docs/security/threat_models/overall-DFD.png
new file mode 100644
index 0000000000..39cf4c8549
--- /dev/null
+++ b/docs/security/threat_models/overall-DFD.png
Binary files differ