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