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