doc: Migrate a subset of the GitHub wiki content
With the TF wiki being migrated from GitHub to trustedfirmware.org,
some documents will be moved into the docs/ directory within the
repository rather than remaining as external content. The
appropriate action has been decided on a per-document basis.
Change-Id: Id0f615f3418369256f30d2e34e354a115389d105
Signed-off-by: Joel Hutton <Joel.Hutton@Arm.com>
Signed-off-by: Paul Beesley <paul.beesley@arm.com>
diff --git a/docs/security_advisories/security-advisory-tfv-6.rst b/docs/security_advisories/security-advisory-tfv-6.rst
new file mode 100644
index 0000000..7b556d8
--- /dev/null
+++ b/docs/security_advisories/security-advisory-tfv-6.rst
@@ -0,0 +1,145 @@
++----------------+-------------------------------------------------------------+
+| Title | Arm Trusted Firmware exposure to speculative processor |
+| | vulnerabilities using cache timing side-channels |
++================+=============================================================+
+| CVE ID | `CVE-2017-5753`_ / `CVE-2017-5715`_ / `CVE-2017-5754`_ |
++----------------+-------------------------------------------------------------+
+| Date | 03 Jan 2018 (Updated 11 Jan, 18 Jan, 26 Jan, 30 Jan and 07 |
+| | June 2018) |
++----------------+-------------------------------------------------------------+
+| Versions | All, up to and including v1.4 |
+| Affected | |
++----------------+-------------------------------------------------------------+
+| Configurations | All |
+| Affected | |
++----------------+-------------------------------------------------------------+
+| Impact | Leakage of secure world data to normal world |
++----------------+-------------------------------------------------------------+
+| Fix Version | `Pull Request #1214`_, `Pull Request #1228`_, |
+| | `Pull Request #1240`_ and `Pull Request #1405`_ |
++----------------+-------------------------------------------------------------+
+| Credit | Google / Arm |
++----------------+-------------------------------------------------------------+
+
+This security advisory describes the current understanding of the Arm Trusted
+Firmware (TF) exposure to the speculative processor vulnerabilities identified
+by `Google Project Zero`_. To understand the background and wider impact of
+these vulnerabilities on Arm systems, please refer to the `Arm Processor
+Security Update`_.
+
+Variant 1 (`CVE-2017-5753`_)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+At the time of writing, no vulnerable patterns have been observed in upstream TF
+code, therefore no workarounds have been applied or are planned.
+
+Variant 2 (`CVE-2017-5715`_)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Where possible on vulnerable CPUs, Arm recommends invalidating the branch
+predictor as early as possible on entry into the secure world, before any branch
+instruction is executed. There are a number of implementation defined ways to
+achieve this.
+
+For Cortex-A57 and Cortex-A72 CPUs, the Pull Requests (PRs) in this advisory
+invalidate the branch predictor when entering EL3 by disabling and re-enabling
+the MMU.
+
+For Cortex-A73 and Cortex-A75 CPUs, the PRs in this advisory invalidate the
+branch predictor when entering EL3 by temporarily dropping into AArch32
+Secure-EL1 and executing the ``BPIALL`` instruction. This workaround is
+signifiantly more complex than the "MMU disable/enable" workaround. The latter
+is not effective at invalidating the branch predictor on Cortex-A73/Cortex-A75.
+
+Note that if other privileged software, for example a Rich OS kernel, implements
+its own branch predictor invalidation during context switch by issuing an SMC
+(to execute firmware branch predictor invalidation), then there is a dependency
+on the PRs in this advisory being deployed in order for those workarounds to
+work. If that other privileged software is able to workaround the vulnerability
+locally (for example by implementing "MMU disable/enable" itself), there is no
+such dependency.
+
+`Pull Request #1240`_ and `Pull Request #1405`_ optimise the earlier fixes by
+implementing a specified `CVE-2017-5715`_ workaround SMC
+(``SMCCC_ARCH_WORKAROUND_1``) for use by normal world privileged software. This
+is more efficient than calling an arbitrary SMC (for example ``PSCI_VERSION``).
+Details of ``SMCCC_ARCH_WORKAROUND_1`` can be found in the `CVE-2017-5715
+mitigation specification`_. The specification and implementation also enable
+the normal world to discover the presence of this firmware service.
+
+On Juno R1 we measured the round trip latency for both the ``PSCI_VERSION`` and
+``SMCCC_ARCH_WORKAROUND_1`` SMCs on Cortex-A57, using both the "MMU
+disable/enable" and "BPIALL at AArch32 Secure-EL1" workarounds described above.
+This includes the time spent in test code conforming to the SMC Calling
+Convention (SMCCC) from AArch64. For the ``SMCCC_ARCH_WORKAROUND_1`` cases, the
+test code uses SMCCC v1.1, which reduces the number of general purpose registers
+it needs to save/restore. Although the ``BPIALL`` instruction is not effective
+at invalidating the branch predictor on Cortex-A57, the drop into Secure-EL1
+with MMU disabled that this workaround entails effectively does invalidate the
+branch predictor. Hence this is a reasonable comparison.
+
+The results were as follows:
+
++------------------------------------------------------------------+-----------+
+| Test | Time (ns) |
++==================================================================+===========+
+| ``PSCI_VERSION`` baseline (without PRs in this advisory) | 515 |
++------------------------------------------------------------------+-----------+
+| ``PSCI_VERSION`` baseline (with PRs in this advisory) | 527 |
++------------------------------------------------------------------+-----------+
+| ``PSCI_VERSION`` with "MMU disable/enable" | 930 |
++------------------------------------------------------------------+-----------+
+| ``SMCCC_ARCH_WORKAROUND_1`` with "MMU disable/enable" | 386 |
++------------------------------------------------------------------+-----------+
+| ``PSCI_VERSION`` with "BPIALL at AArch32 Secure-EL1" | 1276 |
++------------------------------------------------------------------+-----------+
+| ``SMCCC_ARCH_WORKAROUND_1`` with "BPIALL at AArch32 Secure-EL1" | 770 |
++------------------------------------------------------------------+-----------+
+
+Due to the high severity and wide applicability of this issue, the above
+workarounds are enabled by default (on vulnerable CPUs only), despite some
+performance and code size overhead. Platforms can choose to disable them at
+compile time if they do not require them. `Pull Request #1240`_ disables the
+workarounds for unaffected upstream platforms.
+
+For vulnerable AArch32-only CPUs (for example Cortex-A8, Cortex-A9 and
+Cortex-A17), the ``BPIALL`` instruction should be used as early as possible on
+entry into the secure world. For Cortex-A8, also set ``ACTLR[6]`` to 1 during
+early processor initialization. Note that the ``BPIALL`` instruction is not
+effective at invalidating the branch predictor on Cortex-A15. For that CPU, set
+``ACTLR[0]`` to 1 during early processor initialization, and invalidate the
+branch predictor by performing an ``ICIALLU`` instruction.
+
+On AArch32 EL3 systems, the monitor and secure-SVC code is typically tightly
+integrated, for example as part of a Trusted OS. Therefore any Variant 2
+workaround should be provided by vendors of that software and is outside the
+scope of TF. However, an example implementation in the minimal AArch32 Secure
+Payload, ``SP_MIN`` is provided in `Pull Request #1228`_.
+
+Other Arm CPUs are not vulnerable to this or other variants. This includes
+Cortex-A76, Cortex-A53, Cortex-A55, Cortex-A32, Cortex-A7 and Cortex-A5.
+
+For more information about non-Arm CPUs, please contact the CPU vendor.
+
+Variant 3 (`CVE-2017-5754`_)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This variant is only exploitable between Exception Levels within the same
+translation regime, for example between EL0 and EL1, therefore this variant
+cannot be used to access secure memory from the non-secure world, and is not
+applicable for TF. However, Secure Payloads (for example, Trusted OS) should
+provide mitigations on vulnerable CPUs to protect themselves from exploited
+Secure-EL0 applications.
+
+The only Arm CPU vulnerable to this variant is Cortex-A75.
+
+.. _Google Project Zero: https://googleprojectzero.blogspot.co.uk/2018/01/reading-privileged-memory-with-side.html
+.. _Arm Processor Security Update: http://www.arm.com/security-update
+.. _CVE-2017-5753: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5753
+.. _CVE-2017-5715: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5715
+.. _CVE-2017-5754: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5754
+.. _Pull Request #1214: https://github.com/ARM-software/arm-trusted-firmware/pull/1214
+.. _Pull Request #1228: https://github.com/ARM-software/arm-trusted-firmware/pull/1228
+.. _Pull Request #1240: https://github.com/ARM-software/arm-trusted-firmware/pull/1240
+.. _Pull Request #1405: https://github.com/ARM-software/arm-trusted-firmware/pull/1405
+.. _CVE-2017-5715 mitigation specification: https://developer.arm.com/cache-speculation-vulnerability-firmware-specification