blob: 8e06762c7470694cc9ce909b035d5ffca3186ac2 [file] [log] [blame]
Paul Beesley267f8082019-03-07 16:22:44 +00001Advisory TFV-7 (CVE-2018-3639)
Joel Hutton4fe91232019-02-25 15:18:56 +00004+----------------+-------------------------------------------------------------+
5| Title | Trusted Firmware-A exposure to cache speculation |
6| | vulnerability Variant 4 |
8| CVE ID | `CVE-2018-3639`_ |
10| Date | 21 May 2018 (Updated 7 June 2018) |
12| Versions | All, up to and including v1.5 |
13| Affected | |
15| Configurations | All |
16| Affected | |
18| Impact | Leakage of secure world data to normal world |
20| Fix Version | `Pull Request #1392`_, `Pull Request #1397`_ |
22| Credit | Google |
25This security advisory describes the current understanding of the Trusted
26Firmware-A (TF-A) exposure to Variant 4 of the cache speculation vulnerabilities
27identified by `Google Project Zero`_. To understand the background and wider
28impact of these vulnerabilities on Arm systems, please refer to the `Arm
29Processor Security Update`_.
31At the time of writing, the TF-A project is not aware of a Variant 4 exploit
32that could be used against TF-A. It is likely to be very difficult to achieve an
33exploit against current standard configurations of TF-A, due to the limited
34interfaces into the secure world with attacker-controlled inputs. However, this
35is becoming increasingly difficult to guarantee with the introduction of complex
36new firmware interfaces, for example the `Software Delegated Exception Interface
37(SDEI)`_. Also, the TF-A project does not have visibility of all
38vendor-supplied interfaces. Therefore, the TF-A project takes a conservative
39approach by mitigating Variant 4 in hardware wherever possible during secure
40world execution. The mitigation is enabled by setting an implementation defined
41control bit to prevent the re-ordering of stores and loads.
43For each affected CPU type, TF-A implements one of the two following mitigation
44approaches in `Pull Request #1392`_ and `Pull Request #1397`_. Both approaches
45have a system performance impact, which varies for each CPU type and use-case.
46The mitigation code is enabled by default, but can be disabled at compile time
47for platforms that are unaffected or where the risk is deemed low enough.
49Arm CPUs not mentioned below are unaffected.
51Static mitigation
Paul Beesley267f8082019-03-07 16:22:44 +000052-----------------
Joel Hutton4fe91232019-02-25 15:18:56 +000053
54For affected CPUs, this approach enables the mitigation during EL3
55initialization, following every PE reset. No mechanism is provided to disable
56the mitigation at runtime.
58This approach permanently mitigates the entire software stack and no additional
59mitigation code is required in other software components.
61TF-A implements this approach for the following affected CPUs:
63- Cortex-A57 and Cortex-A72, by setting bit 55 (Disable load pass store) of
64 ``CPUACTLR_EL1`` (``S3_1_C15_C2_0``).
66- Cortex-A73, by setting bit 3 of ``S3_0_C15_C0_0`` (not documented in the
67 Technical Reference Manual (TRM)).
69- Cortex-A75, by setting bit 35 (reserved in TRM) of ``CPUACTLR_EL1``
70 (``S3_0_C15_C1_0``).
72Dynamic mitigation
Paul Beesley267f8082019-03-07 16:22:44 +000073------------------
Joel Hutton4fe91232019-02-25 15:18:56 +000074
75For affected CPUs, this approach also enables the mitigation during EL3
76initialization, following every PE reset. In addition, this approach implements
77``SMCCC_ARCH_WORKAROUND_2`` in the Arm architectural range to allow callers at
78lower exception levels to temporarily disable the mitigation in their execution
79context, where the risk is deemed low enough. This approach enables mitigation
80on entry to EL3, and restores the mitigation state of the lower exception level
81on exit from EL3. For more information on this approach, see `Firmware
82interfaces for mitigating cache speculation vulnerabilities`_.
84This approach may be complemented by additional mitigation code in other
85software components, for example code that calls ``SMCCC_ARCH_WORKAROUND_2``.
86However, even without any mitigation code in other software components, this
87approach will effectively permanently mitigate the entire software stack, since
88the default mitigation state for firmware-managed execution contexts is enabled.
90Since the expectation in this approach is that more software executes with the
91mitigation disabled, this may result in better system performance than the
92static approach for some systems or use-cases. However, for other systems or
93use-cases, this performance saving may be outweighed by the additional overhead
94of ``SMCCC_ARCH_WORKAROUND_2`` calls and TF-A exception handling.
96TF-A implements this approach for the following affected CPU:
98- Cortex-A76, by setting and clearing bit 16 (reserved in TRM) of
99 ``CPUACTLR2_EL1`` (``S3_0_C15_C1_1``).
101.. _Google Project Zero:
102.. _Arm Processor Security Update:
103.. _CVE-2018-3639:
104.. _Software Delegated Exception Interface (SDEI):
105.. _Firmware interfaces for mitigating cache speculation vulnerabilities:
106.. _Pull Request #1392:
107.. _Pull Request #1397: