aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorSandrine Bailleux <sandrine.bailleux@arm.com>2022-05-13 12:39:56 +0200
committerSandrine Bailleux <sandrine.bailleux@arm.com>2022-05-31 08:35:15 +0200
commit7e32cdb21ec8f57dfac1639daba6dc0880e03772 (patch)
tree98f4e02f49bad1e31aafcd0e7ecd1a64642d86bd
parent453abc80b2eacbf2816c838e47e40f063227d934 (diff)
downloadtrusted-firmware-a-7e32cdb21ec8f57dfac1639daba6dc0880e03772.tar.gz
docs(threat-model): emphasize whether mitigations are implemented
For each threat, we now separate: - how to mitigate against it; - whether TF-A currently implements these mitigations. A new "Mitigations implemented?" box is added to each threat to provide the implementation status. For threats that are partially mitigated from platform code, the original text is improved to make these expectations clearer. The hope is that platform integrators will have an easier time identifying what they need to carefully implement in order to follow the security recommendations from the threat model. Change-Id: I8473d75946daf6c91a0e15e61758c183603e195b Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
-rw-r--r--docs/threat_model/threat_model.rst242
1 files changed, 164 insertions, 78 deletions
diff --git a/docs/threat_model/threat_model.rst b/docs/threat_model/threat_model.rst
index 2e11a94797..0f6e2af013 100644
--- a/docs/threat_model/threat_model.rst
+++ b/docs/threat_model/threat_model.rst
@@ -254,6 +254,18 @@ Threat Assessment
The following threats were identified by applying STRIDE analysis on
each diagram element of the data flow diagram.
+For each threat, we strive to indicate whether the mitigations are currently
+implemented or not. However, the answer to this question is not always straight
+forward. Some mitigations are partially implemented in the generic code but also
+rely on the platform code to implement some bits of it. This threat model aims
+to be platform-independent and it is important to keep in mind that such threats
+only get mitigated if the platform code properly fulfills its responsibilities.
+
+Also, some mitigations require enabling specific features, which must be
+explicitly turned on via a build flag.
+
+These are highlighted in the ``Mitigations implemented?`` box.
+
+------------------------+----------------------------------------------------+
| ID | 01 |
+========================+====================================================+
@@ -286,13 +298,18 @@ each diagram element of the data flow diagram.
+------------------------+------------------+-----------------+---------------+
| Total Risk Rating | Critical (25) | Critical (25) | Critical (25) |
+------------------------+------------------+-----------------+---------------+
-| Mitigations | | TF-A implements the `Trusted Board Boot (TBB)`_ |
+| Mitigations | | 1) Implement the `Trusted Board Boot (TBB)`_ |
| | feature which prevents malicious firmware from |
| | running on the platform by authenticating all |
-| | firmware images. In addition to this, the TF-A |
-| | boot firmware performs extra checks on |
-| | unauthenticated data, such as FIP metadata, prior|
-| | to use. |
+| | firmware images. |
+| | |
+| | | 2) Perform extra checks on unauthenticated data, |
+| | such as FIP metadata, prior to use. |
++------------------------+----------------------------------------------------+
+| Mitigations | | 1) Yes, provided that the ``TRUSTED_BOARD_BOOT`` |
+| implemented? | build option is set to 1. |
+| | |
+| | | 2) Yes. |
+------------------------+----------------------------------------------------+
+------------------------+----------------------------------------------------+
@@ -324,22 +341,27 @@ each diagram element of the data flow diagram.
+------------------------+------------------+-----------------+---------------+
| Total Risk Rating | Critical (25) | Critical (25) | Critical (25) |
+------------------------+------------------+-----------------+---------------+
-| Mitigations | | TF-A supports anti-rollback protection using |
-| | non-volatile counters (NV counters) as required |
-| | by `TBBR-Client specification`_. After a firmware|
-| | image is validated, the image revision number |
-| | taken from a certificate extension field is |
-| | compared with the corresponding NV counter stored|
-| | in hardware to make sure the new counter value is|
-| | larger or equal to the current counter value. |
-| | Platforms must implement this protection using |
-| | platform specific hardware NV counters. |
+| Mitigations | Implement anti-rollback protection using |
+| | non-volatile counters (NV counters) as required |
+| | by `TBBR-Client specification`_. |
++------------------------+----------------------------------------------------+
+| Mitigations | | Yes / Platform specific. |
+| implemented? | |
+| | | After a firmware image is validated, the image |
+| | revision number taken from a certificate |
+| | extension field is compared with the |
+| | corresponding NV counter stored in hardware to |
+| | make sure the new counter value is larger than |
+| | the current counter value. |
+| | |
+| | | **Platforms must implement this protection using |
+| | platform specific hardware NV counters.** |
+------------------------+----------------------------------------------------+
+------------------------+-------------------------------------------------------+
| ID | 03 |
+========================+=======================================================+
-| Threat | | **An attacker can use Time-of-Check-Time-of-Use |
+| Threat | | **An attacker can use Time-of-Check-Time-of-Use |
| | (TOCTOU) attack to bypass image authentication |
| | during the boot process** |
| | |
@@ -370,8 +392,14 @@ each diagram element of the data flow diagram.
+------------------------+---------------------+-----------------+---------------+
| Total Risk Rating | N/A | High (15) | High (15) |
+------------------------+---------------------+-----------------+---------------+
-| Mitigations | | TF-A boot firmware copies image to on-chip |
-| | memory before authenticating an image. |
+| Mitigations | Copy image to on-chip memory before authenticating |
+| | it. |
++------------------------+-------------------------------------------------------+
+| Mitigations | | Platform specific. |
+| implemented? | |
+| | | The list of images to load and their location is |
+| | platform specific. Platforms are responsible for |
+| | arranging images to be loaded in on-chip memory. |
+------------------------+-------------------------------------------------------+
+------------------------+-------------------------------------------------------+
@@ -415,12 +443,19 @@ each diagram element of the data flow diagram.
+------------------------+---------------------+-----------------+---------------+
| Total Risk Rating | N/A | High (15) | High (15) |
+------------------------+---------------------+-----------------+---------------+
-| Mitigations | | The most effective mitigation is adding glitching |
+| Mitigations | Mechanisms to detect clock glitch and power |
+| | variations. |
++------------------------+-------------------------------------------------------+
+| Mitigations | | No. |
+| implemented? | |
+| | | The most effective mitigation is adding glitching |
| | detection and mitigation circuit at the hardware |
-| | level. However, software techniques, |
-| | such as adding redundant checks when performing |
-| | conditional branches that are security sensitive, |
-| | can be used to harden TF-A against such attacks. |
+| | level. |
+| | |
+| | | However, software techniques, such as adding |
+| | redundant checks when performing conditional |
+| | branches that are security sensitive, can be used |
+| | to harden TF-A against such attacks. |
| | **At the moment TF-A doesn't implement such |
| | mitigations.** |
+------------------------+-------------------------------------------------------+
@@ -460,11 +495,25 @@ each diagram element of the data flow diagram.
+------------------------+------------------+----------------+---------------+
| Total Risk Rating | N/A | Medium (8) | Medium (8) |
+------------------------+------------------+----------------+---------------+
-| Mitigations | | In TF-A, crash reporting is only enabled for |
-| | debug builds by default. Alternatively, the log |
-| | level can be tuned at build time (from verbose |
-| | to no output at all), independently of the |
-| | build type. |
+| Mitigations | Remove crash reports in production releases. |
++------------------------+---------------------------------------------------+
+| Mitigations | | Yes / Platform Specific. |
+| implemented? | Requires the right build options to be used. |
+| | |
+| | | Crash reporting is only enabled for debug |
+| | builds by default, see ``CRASH_REPORTING`` |
+| | build option. |
+| | |
+| | | The log level can be tuned at build time, from |
+| | very verbose to no output at all. See |
+| | ``LOG_LEVEL`` build option. By default, release |
+| | builds are a lot less verbose than debug ones |
+| | but still produce some output. |
+| | |
+| | | Messages produced by the platform code should |
+| | use the appropriate level of verbosity so as |
+| | not to leak sensitive information in production |
+| | builds. |
+------------------------+---------------------------------------------------+
+------------------------+----------------------------------------------------+
@@ -503,11 +552,14 @@ each diagram element of the data flow diagram.
+------------------------+------------------+---------------+-----------------+
| Total Risk Rating | N/A | Critical (20) | Critical (20) |
+------------------------+------------------+---------------+-----------------+
-| Mitigations | | Configuration of debug and trace capabilities is |
-| | platform specific. Therefore, platforms must |
-| | disable the debug and trace capability for |
-| | production releases or enable proper debug |
-| | authentication as recommended by [`DEN0034`_]. |
+| Mitigations | Disable the debug and trace capability for |
+| | production releases or enable proper debug |
+| | authentication as recommended by [`DEN0034`_]. |
++------------------------+----------------------------------------------------+
+| Mitigations | | Platform specific. |
+| implemented? | |
+| | | Configuration of debug and trace capabilities is |
+| | entirely platform specific. |
+------------------------+----------------------------------------------------+
+------------------------+------------------------------------------------------+
@@ -542,9 +594,14 @@ each diagram element of the data flow diagram.
+------------------------+-------------------+----------------+-----------------+
| Total Risk Rating | High (12) | High (12) | High (12) |
+------------------------+-------------------+----------------+-----------------+
-| Mitigations | | The generic TF-A code validates SMC function ids |
-| | and arguments before using them. |
-| | Platforms that implement SiP services must also |
+| Mitigations | Validate SMC function ids and arguments before using |
+| | them. |
++------------------------+------------------------------------------------------+
+| Mitigations | | Yes / Platform specific. |
+| implemented? | |
+| | | For standard services, all input is validated. |
+| | |
+| | | Platforms that implement SiP services must also |
| | validate SMC call arguments. |
+------------------------+------------------------------------------------------+
@@ -588,17 +645,12 @@ each diagram element of the data flow diagram.
+------------------------+-------------------+-----------------+----------------+
| Total Risk Rating | High (15) | High (15) | High (15) |
+------------------------+-------------------+-----------------+----------------+
-| Mitigations | | TF-A uses a combination of manual code reviews and |
-| | automated program analysis and testing to detect |
-| | and fix memory corruption bugs. All TF-A code |
-| | including platform code go through manual code |
-| | reviews. Additionally, static code analysis is |
-| | performed using Coverity Scan on all TF-A code. |
-| | The code is also tested with |
-| | `Trusted Firmware-A Tests`_ on Juno and FVP |
-| | platforms. |
+| Mitigations | | 1) Use proper input validation. |
| | |
-| | | Data received from normal world, such as addresses |
+| | | 2) Code reviews, testing. |
++------------------------+------------------------------------------------------+
+| Mitigations | | 1) Yes. |
+| implemented? | Data received from normal world, such as addresses |
| | and sizes identifying memory regions, are |
| | sanitized before being used. These security checks |
| | make sure that the normal world software does not |
@@ -612,6 +664,17 @@ each diagram element of the data flow diagram.
| | option to use *asserts* in release builds, however |
| | we recommend using proper runtime checks instead |
| | of relying on asserts in release builds. |
+| | |
+| | | 2) Yes. |
+| | TF-A uses a combination of manual code reviews |
+| | and automated program analysis and testing to |
+| | detect and fix memory corruption bugs. All TF-A |
+| | code including platform code go through manual |
+| | code reviews. Additionally, static code analysis |
+| | is performed using Coverity Scan on all TF-A code. |
+| | The code is also tested with |
+| | `Trusted Firmware-A Tests`_ on Juno and FVP |
+| | platforms. |
+------------------------+------------------------------------------------------+
+------------------------+------------------------------------------------------+
@@ -643,10 +706,14 @@ each diagram element of the data flow diagram.
+------------------------+-------------------+----------------+-----------------+
| Total Risk Rating | High (12) | High (12) | High (12) |
+------------------------+-------------------+----------------+-----------------+
-| Mitigations | | TF-A saves and restores registers |
-| | by default when switching contexts. Build options |
-| | are also provided to save/restore additional |
-| | registers such as floating-point registers. |
+| Mitigations | Save and restore registers when switching contexts. |
++------------------------+------------------------------------------------------+
+| Mitigations | | Yes. |
+| implemented? | |
+| | | This is the default behaviour in TF-A. |
+| | Build options are also provided to save/restore |
+| | additional registers such as floating-point |
+| | registers. These should be enabled if required. |
+------------------------+------------------------------------------------------+
+------------------------+-----------------------------------------------------+
@@ -680,11 +747,17 @@ each diagram element of the data flow diagram.
+------------------------+-------------------+----------------+----------------+
| Total Risk Rating | Medium (9) | Medium (9) | Medium (9) |
+------------------------+-------------------+----------------+----------------+
-| Mitigations | | TF-A implements software mitigations for Spectre |
+| Mitigations | Enable appropriate side-channel protections. |
++------------------------+-----------------------------------------------------+
+| Mitigations | | Yes / Platform specific. |
+| implemented? | |
+| | | TF-A implements software mitigations for Spectre |
| | type attacks as recommended by `Cache Speculation |
-| | Side-channels`_ for the generic code. SiPs should |
-| | implement similar mitigations for code that is |
-| | deemed to be vulnerable to such attacks. |
+| | Side-channels`_ for the generic code. |
+| | |
+| | | SiPs should implement similar mitigations for |
+| | code that is deemed to be vulnerable to such |
+| | attacks. |
+------------------------+-----------------------------------------------------+
+------------------------+----------------------------------------------------+
@@ -720,19 +793,25 @@ each diagram element of the data flow diagram.
+------------------------+-----------------+-----------------+----------------+
| Total Risk Rating | Critical (20) | Critical (20) | Critical (20) |
+------------------------+-----------------+-----------------+----------------+
-| Mitigations | | In TF-A, configuration of the MMU is done |
-| | through a translation tables library. The |
-| | library provides APIs to define memory regions |
-| | and assign attributes including memory types and |
-| | access permissions. Memory configurations are |
-| | platform specific, therefore platforms need make |
-| | sure the correct attributes are assigned to |
-| | memory regions. When assigning access |
-| | permissions, principle of least privilege ought |
-| | to be enforced, i.e. we should not grant more |
-| | privileges than strictly needed, e.g. code |
-| | should be read-only executable, RO data should |
-| | be read-only XN, and so on. |
+| Mitigations | When configuring access permissions, the |
+| | principle of least privilege ought to be |
+| | enforced. This means we should not grant more |
+| | privileges than strictly needed, e.g. code |
+| | should be read-only executable, read-only data |
+| | should be read-only execute-never, and so on. |
++------------------------+----------------------------------------------------+
+| Mitigations | | Platform specific. |
+| implemented? | |
+| | | MMU configuration is platform specific, |
+| | therefore platforms need to make sure that the |
+| | correct attributes are assigned to memory |
+| | regions. |
+| | |
+| | | TF-A provides a library which abstracts the |
+| | low-level details of MMU configuration. It |
+| | provides well-defined and tested APIs. |
+| | Platforms are encouraged to use it to limit the |
+| | risk of misconfiguration. |
+------------------------+----------------------------------------------------+
+------------------------+-----------------------------------------------------+
@@ -747,7 +826,7 @@ each diagram element of the data flow diagram.
| | to count events at any exception level and in |
| | both Secure and Non-secure states. This allows |
| | a Non-secure software (or a lower-level Secure |
-| | software) to potentially carry out |
+| | software) to potentially carry out |
| | side-channel timing attacks against TF-A. |
+------------------------+-----------------------------------------------------+
| Diagram Elements | DF5, DF6 |
@@ -767,18 +846,25 @@ each diagram element of the data flow diagram.
+------------------------+-------------------+----------------+----------------+
| Total Risk Rating | Medium (6) | Medium (6) | Medium (6) |
+------------------------+-------------------+----------------+----------------+
-| Mitigations | | TF-A follows mitigation strategies as described |
-| | in `Secure Development Guidelines`_. General |
-| | events and cycle counting in the Secure world is |
-| | prohibited by default when applicable. However, |
-| | on some implementations (e.g. PMUv3) Secure world |
-| | event counting depends on external debug interface|
-| | signals, i.e. Secure world event counting is |
-| | enabled if external debug is enabled. |
-| | Configuration of debug signals is platform |
+| Mitigations | Follow mitigation strategies as described in |
+| | `Secure Development Guidelines`_. |
++------------------------+-----------------------------------------------------+
+| Mitigations | | Yes / platform specific. |
+| implemented? | |
+| | | General events and cycle counting in the Secure |
+| | world is prohibited by default when applicable. |
+| | |
+| | | However, on some implementations (e.g. PMUv3) |
+| | Secure world event counting depends on external |
+| | debug interface signals, i.e. Secure world event |
+| | counting is enabled if external debug is enabled. |
+| | |
+| | | Configuration of debug signals is platform |
| | specific, therefore platforms need to make sure |
| | that external debug is disabled in production or |
-| | proper debug authentication is in place. |
+| | proper debug authentication is in place. This |
+| | should be the case if threat #06 is properly |
+| | mitigated. |
+------------------------+-----------------------------------------------------+
--------------