Docs: Add mitigation strategies to the threat model
For each threat, clarify whether the threat is mitigated by TF-M or
must be mitigated downstream of the generic TF-M implementation.
Signed-off-by: Jamie Fox <jamie.fox@arm.com>
Change-Id: I0ed19271a530534bad19a053763a3ffe983b3969
diff --git a/docs/security/threat_models/generic_threat_model.rst b/docs/security/threat_models/generic_threat_model.rst
index f4c9058..6f419a4 100644
--- a/docs/security/threat_models/generic_threat_model.rst
+++ b/docs/security/threat_models/generic_threat_model.rst
@@ -234,6 +234,22 @@
representation of the CVSS metric values used to score the threat. Refer to
[CVSS_SPEC]_ for more details of CVSS vector string.
+For each threat, a mitigation strategy is determined:
+
+- **Controlled**: a mitigation has been implemented by TF-M.
+
+- **Accepted**: no mitigation is currently implemented as the risk is
+ acceptable, and the mitigation description justifies the acceptance.
+
+- **Suppressed**: the feature can be disabled to remove the threat.
+
+- **Transferred**: the threat cannot be fully mitigated within the scope of
+ TF-M. The threat must be handled by downstream users for their specific
+ platform.
+
+- **Out-of-scope**: some threats are out-of-scope and so do not have a
+ mitigation but are included for completeness.
+
.. note::
A generic threat may have different behaviors and therefore require different
@@ -260,14 +276,15 @@
+---------------+------------------------------------------------------------+
| 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. |
+ | Mitigation | **Controlled**: TF-M BL2 uses MCUBoot to validate the |
+ | | integrity and authenticity of the NS image during secure |
+ | | boot, before the Secure firmware jumps to the NS entry or |
+ | | boots up the NS core. |
| | Refer to [SECURE-BOOT]_ for more details. |
| | |
- | | The validation may vary in diverse vendor platforms |
- | | specific Chain of Trust (CoT) implementation. |
+ | | Platforms may replace the TF-M Chain of Trust (CoT) |
+ | | implementation, in which case this threat is |
+ | | **transferred**. |
+---------------+------------------------------------------------------------+
| CVSS Score | 3.5 (Low) |
+---------------+------------------------------------------------------------+
@@ -293,12 +310,12 @@
+---------------+------------------------------------------------------------+
| Category | Tampering |
+---------------+------------------------------------------------------------+
- | Mitigation | TF-M relies on MCUBoot to perform anti-rollback |
- | | protection. |
+ | Mitigation | **Controlled**: TF-M relies on MCUBoot to perform |
+ | | anti-rollback checks. |
| | |
- | | TF-M defines a non-volatile counter API to support |
- | | anti-rollback. Each platform must implement it using |
- | | specific trusted hardware non-volatile counters. |
+ | | **Transferred**: 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 |
@@ -326,20 +343,18 @@
+---------------+------------------------------------------------------------+
| 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. |
+ | Mitigation | **Transferred**: TF-M defines isolation configuration |
+ | | HALs, which platforms must implement using platform- |
+ | | specific isolation hardware. TF-M provides a reference |
+ | | implementation of the isolation HAL for Armv8-M platforms |
+ | | with TrustZone. |
| | |
| | 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. |
+ | | TF-M executes isolation configuration at an early stage of |
+ | | secure initialization before starting NS execution. |
+---------------+------------------------------------------------------------+
| CVSS Score | 9.0 (Critical) |
+---------------+------------------------------------------------------------+
@@ -366,17 +381,14 @@
+---------------+------------------------------------------------------------+
| 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. |
+ | Mitigation | **Transferred**: Platforms must implement the TF-M |
+ | | isolation HALs to complete and enable proper configuration |
+ | | and isolation to protect critical devices and peripherals |
+ | | from being accessed by the NSPE. |
| | |
| | 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. |
+ | | peripherals at an early stage of secure initialization, |
+ | | before jumping to NS entry or booting up NS core. |
+---------------+------------------------------------------------------------+
| CVSS Score | 9.0 (Critical) |
+---------------+------------------------------------------------------------+
@@ -400,19 +412,19 @@
+---------------+------------------------------------------------------------+
| Category | Information disclosure |
+---------------+------------------------------------------------------------+
- | Mitigation | SPE must clean up the secure information from shared |
- | | registers before NS starts. |
+ | Mitigation | **Controlled**: TF-M clears registers that are not banked |
+ | | between security states before handing over execution to |
+ | | the NSPE on Armv8-M platforms with TrustZone. |
| | |
- | | TF-M invalidates registers not banked before handing over |
- | | the system to NSPE on Armv8-M platforms with TrustZone. |
+ | | TF-M does not store SPE information in Non-secure memory. |
+ | | |
+ | | **Transferred**: Platform-specific code in the SPE must |
+ | | not store SPE information in Non-secure memory. |
| | |
| | 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) |
+---------------+------------------------------------------------------------+
@@ -434,8 +446,8 @@
+---------------+------------------------------------------------------------+
| Category | Denial of service |
+---------------+------------------------------------------------------------+
- | Mitigation | No SPE information will be disclosed and TF-M won't be |
- | | directly impacted. |
+ | Mitigation | **Out-of-scope**: 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 |
@@ -472,9 +484,9 @@
+---------------+------------------------------------------------------------+
| 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. |
+ | Mitigation | **Controlled**: 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) |
+---------------+------------------------------------------------------------+
@@ -501,10 +513,11 @@
+---------------+------------------------------------------------------------+
| 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. |
+ | Mitigation | **Controlled**: 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) |
+---------------+------------------------------------------------------------+
@@ -529,10 +542,10 @@
+---------------+------------------------------------------------------------+
| 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. |
+ | Mitigation | **Controlled**: 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) |
+---------------+------------------------------------------------------------+
@@ -556,8 +569,11 @@
+---------------+------------------------------------------------------------+
| Category | Repudiation |
+---------------+------------------------------------------------------------+
- | Mitigation | TF-M implements an event logging secure service to record |
- | | the critical events, such as the access to critical data. |
+ | Mitigation | **Transferred**: This threat can be mitigated with an |
+ | | audit logging secure service that records significant |
+ | | security events, such as access to sensitive data. If this |
+ | | threat is in-scope for a particular integration, then the |
+ | | system integrator must implement the mitigation. |
+---------------+------------------------------------------------------------+
| CVSS Score | 0.0 (None) |
+---------------+------------------------------------------------------------+
@@ -581,10 +597,10 @@
+---------------+------------------------------------------------------------+
| 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. |
+ | Mitigation | **Controlled**: TF-M executes memory access checks for all |
+ | | the RoT service requests. If a request doesn't have enough |
+ | | permission to access the target memory region, TF-M will |
+ | | refuse the request and assert a security error. |
+---------------+------------------------------------------------------------+
| CVSS Score | 7.1 (High) |
+---------------+------------------------------------------------------------+
@@ -608,9 +624,9 @@
+---------------+------------------------------------------------------------+
| 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. |
+ | Mitigation | **Controlled**: 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) |
+---------------+------------------------------------------------------------+
@@ -640,9 +656,9 @@
+---------------+------------------------------------------------------------+
| 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. |
+ | Mitigation | **Out-of-scope**: TF-M is unable to manage behavior of NS |
+ | | applications. Assets are not disclosed and neither is TF-M |
+ | | 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. |
@@ -679,8 +695,8 @@
+---------------+------------------------------------------------------------+
| Category | Denial of service |
+---------------+------------------------------------------------------------+
- | Mitigation | TF-M executes memory access check to the memory addresses |
- | | in all the NS requests. |
+ | Mitigation | **Controlled**: TF-M executes memory access check to the |
+ | | memory addresses in all the NS requests. |
| | |
| | On Armv8-M platforms with TrustZone, TF-M invokes ``TT`` |
| | instructions to execute memory address check. If a NS |
@@ -696,10 +712,10 @@
| | 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. |
+ | | **Transferred**: 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. |
+---------------+------------------------------------------------------------+
| CVSS Score | 3.2 (Low) |
+---------------+------------------------------------------------------------+
@@ -737,18 +753,20 @@
+---------------+------------------------------------------------------------+
| Category | Tampering |
+---------------+------------------------------------------------------------+
- | Mitigation | If RoT services request SPM to read and write NS data, 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. |
+ | Mitigation | **Controlled**: If RoT services request SPM to read and |
+ | | write NS data, 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. |
| | |
- | | If RoT services can directly access NS memory and read NS |
- | | input data multiple times during data processing, it is |
- | | required to review and confirm the implementation of the |
- | | RoT service copies NS input data into SPE memory area |
- | | before it processes the data. |
+ | | **Transferred**: If RoT services can directly access NS |
+ | | memory and read NS input data multiple times during data |
+ | | processing, then the RoT service implementor must review |
+ | | and confirm the implementation of the RoT service copies |
+ | | NS input data into SPE memory area before it processes the |
+ | | data. TF-M-provided RoT services implement this |
+ | | mitigation. |
+---------------+------------------------------------------------------------+
| CVSS Score | 3.2 (Low) |
+---------------+------------------------------------------------------------+
@@ -787,12 +805,12 @@
+---------------+------------------------------------------------------------+
| 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. |
+ | Mitigation | **Transferred**: The RoT service implementor must not |
+ | | 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. |
| | |
| | If RoT services request SPM to read and write NS data, |
| | SPM will validate the target addresses and can detect the |
@@ -801,6 +819,8 @@
| | If RoT services can directly access NS memory, it is |
| | required to review and confirm the implementation of RoT |
| | service request doesn't embed memory addresses. |
+ | | |
+ | | TF-M-provided RoT services implement these mitigations. |
+---------------+------------------------------------------------------------+
| CVSS Score | 7.1 (High) |
+---------------+------------------------------------------------------------+
@@ -830,12 +850,12 @@
+---------------+------------------------------------------------------------+
| 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. |
+ | Mitigation | **Transferred**: The RoT service implementor must not |
+ | | 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. |
| | |
| | If RoT services request SPM to read and write NS data, |
| | SPM will validate the target addresses and can detect the |
@@ -844,6 +864,8 @@
| | If RoT services can directly access NS memory, it is |
| | required to review and confirm the implementation of RoT |
| | service request doesn't embed memory addresses. |
+ | | |
+ | | TF-M-provided RoT services implement these mitigations. |
+---------------+------------------------------------------------------------+
| CVSS Score | 7.1 (High) |
+---------------+------------------------------------------------------------+
@@ -881,9 +903,10 @@
+---------------+------------------------------------------------------------+
| Category | Information disclosure |
+---------------+------------------------------------------------------------+
- | Mitigation | In Armv8-M TrustZone scenarios, TF-M cleans general |
- | | purpose registers not banked before switching into NSPE to |
- | | prevent NSPE probing secure context from the registers. |
+ | Mitigation | **Controlled**: In Armv8-M TrustZone scenarios, TF-M |
+ | | cleans general purpose registers not banked before |
+ | | switching into NSPE to prevent NSPE probing secure context |
+ | | from the registers. |
| | |
| | When FPU is enabled in TF-M, secure FP context belonging to|
| | a secure partition will be saved on this partition's stack |
@@ -917,9 +940,10 @@
+---------------+------------------------------------------------------------+
| Category | Information disclosure |
+---------------+------------------------------------------------------------+
- | Mitigation | On Armv8-M processors with TrustZone, Armv8-M architecture |
- | | automatically cleans up the registers not banked before |
- | | switching to Non-secure state while taking NS interrupts. |
+ | Mitigation | **Controlled**: On Armv8-M processors with TrustZone, |
+ | | Armv8-M architecture automatically cleans up the registers |
+ | | not banked before switching to Non-secure state when |
+ | | taking NS interrupts. |
| | |
| | When FPU is enabled in TF-M, with setting of FPCCR_S.TS = 1|
| | besides secure FP context in FP caller registers, FP |
@@ -929,10 +953,11 @@
| | to Armv8-M Architecture Reference Manual [Arm-ARM]_ for |
| | details. |
| | |
- | | 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. |
+ | | **Transferred**: 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) |
+---------------+------------------------------------------------------------+
@@ -957,7 +982,8 @@
+---------------+------------------------------------------------------------+
| Category | Denial of service |
+---------------+------------------------------------------------------------+
- | Mitigation | It is out of scope of TF-M. |
+ | Mitigation | **Out-of-scope**: Availability of the whole system is out |
+ | | of scope of TF-M. |
| | |
| | Assets protected by TF-M won't be leaked. TF-M won't be |
| | directly impacted. |
@@ -993,11 +1019,11 @@
+---------------+------------------------------------------------------------+
| Category | Information disclosure |
+---------------+------------------------------------------------------------+
- | Mitigation | TF-M saves NSPE 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. |
+ | Mitigation | **Controlled**: TF-M saves NSPE context in general purpose |
+ | | registers 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 |
@@ -1046,8 +1072,8 @@
+---------------+------------------------------------------------------------+
| Category | Elevation of privilege |
+---------------+------------------------------------------------------------+
- | Mitigation | TF-M has implemented common mitigation against stack seal |
- | | vulnerability. |
+ | Mitigation | **Controlled**: TF-M has implemented a common mitigation |
+ | | against the stack seal vulnerability. |
| | |
| | Refer to [ADVISORY-TFMV-1]_ for details on analysis and |
| | mitigation in TF-M. |
@@ -1077,8 +1103,8 @@
+---------------+------------------------------------------------------------+
| Category | Denial of service/Tampering |
+---------------+------------------------------------------------------------+
- | Mitigation | TF-M has enhanced implementation to mitigate this |
- | | vulnerability. |
+ | Mitigation | **Controlled**: TF-M has enhanced implementation to |
+ | | mitigate this vulnerability. |
| | |
| | Refer to [ADVISORY-TFMV-2]_ for details on analysis and |
| | mitigation in TF-M. |
@@ -1102,10 +1128,10 @@
+---------------+------------------------------------------------------------+
| Category | Tampering/Information disclosure |
+---------------+------------------------------------------------------------+
- | Mitigation | In current TF-M implementation, when FPU is enabled in SPE,|
- | | TF-M configures NSACR to disable NSPE to access FPU. |
- | | Therefore, secure data in FP registers is protected from |
- | | NSPE. |
+ | Mitigation | **Controlled**: In the current TF-M implementation, when |
+ | | FPU is enabled in SPE, TF-M configures NSACR to disable |
+ | | NSPE to access FPU. Therefore, secure data in FP registers |
+ | | is protected from NSPE. |
| | |
| | Refer to [VLLDM-Vulnerability]_, for details on analysis |
| | and mitigation. |
@@ -1135,6 +1161,8 @@
+---------+--------------------------------------------------+---------------+
| v1.3 | Update for validity of dual-cpu model Armv8-M | TF-M v2.1.0 |
+---------+--------------------------------------------------+---------------+
+ | v1.4 | Clarify mitigation strategies of threats | TF-M v2.2.0 |
+ +---------+--------------------------------------------------+---------------+
**********
References