summaryrefslogtreecommitdiffstats
path: root/docs/security_advisories
diff options
context:
space:
mode:
Diffstat (limited to 'docs/security_advisories')
-rw-r--r--docs/security_advisories/index.rst16
-rw-r--r--docs/security_advisories/security-advisory-tfv-1.rst162
-rw-r--r--docs/security_advisories/security-advisory-tfv-2.rst61
-rw-r--r--docs/security_advisories/security-advisory-tfv-3.rst86
-rw-r--r--docs/security_advisories/security-advisory-tfv-4.rst124
-rw-r--r--docs/security_advisories/security-advisory-tfv-5.rst57
-rw-r--r--docs/security_advisories/security-advisory-tfv-6.rst148
-rw-r--r--docs/security_advisories/security-advisory-tfv-7.rst107
-rw-r--r--docs/security_advisories/security-advisory-tfv-8.rst103
-rw-r--r--docs/security_advisories/security-advisory-tfv-9.rst124
10 files changed, 988 insertions, 0 deletions
diff --git a/docs/security_advisories/index.rst b/docs/security_advisories/index.rst
new file mode 100644
index 0000000..b80ba34
--- /dev/null
+++ b/docs/security_advisories/index.rst
@@ -0,0 +1,16 @@
+Security Advisories
+===================
+
+.. toctree::
+ :maxdepth: 1
+ :caption: Contents
+
+ security-advisory-tfv-1.rst
+ security-advisory-tfv-2.rst
+ security-advisory-tfv-3.rst
+ security-advisory-tfv-4.rst
+ security-advisory-tfv-5.rst
+ security-advisory-tfv-6.rst
+ security-advisory-tfv-7.rst
+ security-advisory-tfv-8.rst
+ security-advisory-tfv-9.rst
diff --git a/docs/security_advisories/security-advisory-tfv-1.rst b/docs/security_advisories/security-advisory-tfv-1.rst
new file mode 100644
index 0000000..9d58d08
--- /dev/null
+++ b/docs/security_advisories/security-advisory-tfv-1.rst
@@ -0,0 +1,162 @@
+Advisory TFV-1 (CVE-2016-10319)
+===============================
+
++----------------+-------------------------------------------------------------+
+| Title | Malformed Firmware Update SMC can result in copy of |
+| | unexpectedly large data into secure memory |
++================+=============================================================+
+| CVE ID | `CVE-2016-10319`_ |
++----------------+-------------------------------------------------------------+
+| Date | 18 Oct 2016 |
++----------------+-------------------------------------------------------------+
+| Versions | v1.2 and v1.3 (since commit `48bfb88`_) |
+| Affected | |
++----------------+-------------------------------------------------------------+
+| Configurations | Platforms that use AArch64 BL1 plus untrusted normal world |
+| Affected | firmware update code executing before BL31 |
++----------------+-------------------------------------------------------------+
+| Impact | Copy of unexpectedly large data into the free secure memory |
+| | reported by BL1 platform code |
++----------------+-------------------------------------------------------------+
+| Fix Version | `Pull Request #783`_ |
++----------------+-------------------------------------------------------------+
+| Credit | IOActive |
++----------------+-------------------------------------------------------------+
+
+Generic Trusted Firmware (TF) BL1 code contains an SMC interface that is briefly
+available after cold reset to support the Firmware Update (FWU) feature (also
+known as recovery mode). This allows most FWU functionality to be implemented in
+the normal world, while retaining the essential image authentication
+functionality in BL1. When cold boot reaches the EL3 Runtime Software (for
+example, BL31 on AArch64 systems), the FWU SMC interface is replaced by the EL3
+Runtime SMC interface. Platforms may choose how much of this FWU functionality
+to use, if any.
+
+The BL1 FWU SMC handling code, currently only supported on AArch64, contains
+several vulnerabilities that may be exploited when *all* the following
+conditions apply:
+
+1. Platform code uses TF BL1 with the ``TRUSTED_BOARD_BOOT`` build option
+ enabled.
+
+2. Platform code arranges for untrusted normal world FWU code to be executed in
+ the cold boot path, before BL31 starts. Untrusted in this sense means code
+ that is not in ROM or has not been authenticated or has otherwise been
+ executed by an attacker.
+
+3. Platform code copies the insecure pattern described below from the ARM
+ platform version of ``bl1_plat_mem_check()``.
+
+The vulnerabilities consist of potential integer overflows in the input
+validation checks while handling the ``FWU_SMC_IMAGE_COPY`` SMC. The SMC
+implementation is designed to copy an image into secure memory for subsequent
+authentication, but the vulnerabilities may allow an attacker to copy
+unexpectedly large data into secure memory. Note that a separate vulnerability
+is required to leverage these vulnerabilities; for example a way to get the
+system to change its behaviour based on the unexpected secure memory contents.
+
+Two of the vulnerabilities are in the function ``bl1_fwu_image_copy()`` in
+``bl1/bl1_fwu.c``. These are listed below, referring to the v1.3 tagged version
+of the code:
+
+- Line 155:
+
+ .. code:: c
+
+ /*
+ * If last block is more than expected then
+ * clip the block to the required image size.
+ */
+ if (image_desc->copied_size + block_size >
+ image_desc->image_info.image_size) {
+ block_size = image_desc->image_info.image_size -
+ image_desc->copied_size;
+ WARN("BL1-FWU: Copy argument block_size > remaining image size."
+ " Clipping block_size\n");
+ }
+
+ /* Make sure the image src/size is mapped. */
+ if (bl1_plat_mem_check(image_src, block_size, flags)) {
+ WARN("BL1-FWU: Copy arguments source/size not mapped\n");
+ return -ENOMEM;
+ }
+
+ INFO("BL1-FWU: Continuing image copy in blocks\n");
+
+ /* Copy image for given block size. */
+ base_addr += image_desc->copied_size;
+ image_desc->copied_size += block_size;
+ memcpy((void *)base_addr, (const void *)image_src, block_size);
+ ...
+
+ This code fragment is executed when the image copy operation is performed in
+ blocks over multiple SMCs. ``block_size`` is an SMC argument and therefore
+ potentially controllable by an attacker. A very large value may result in an
+ integer overflow in the 1st ``if`` statement, which would bypass the check,
+ allowing an unclipped ``block_size`` to be passed into
+ ``bl1_plat_mem_check()``. If ``bl1_plat_mem_check()`` also passes, this may
+ result in an unexpectedly large copy of data into secure memory.
+
+- Line 206:
+
+ .. code:: c
+
+ /* Make sure the image src/size is mapped. */
+ if (bl1_plat_mem_check(image_src, block_size, flags)) {
+ WARN("BL1-FWU: Copy arguments source/size not mapped\n");
+ return -ENOMEM;
+ }
+
+ /* Find out how much free trusted ram remains after BL1 load */
+ mem_layout = bl1_plat_sec_mem_layout();
+ if ((image_desc->image_info.image_base < mem_layout->free_base) ||
+ (image_desc->image_info.image_base + image_size >
+ mem_layout->free_base + mem_layout->free_size)) {
+ WARN("BL1-FWU: Memory not available to copy\n");
+ return -ENOMEM;
+ }
+
+ /* Update the image size. */
+ image_desc->image_info.image_size = image_size;
+
+ /* Copy image for given size. */
+ memcpy((void *)base_addr, (const void *)image_src, block_size);
+ ...
+
+ This code fragment is executed during the 1st invocation of the image copy
+ operation. Both ``block_size`` and ``image_size`` are SMC arguments. A very
+ large value of ``image_size`` may result in an integer overflow in the 2nd
+ ``if`` statement, which would bypass the check, allowing execution to proceed.
+ If ``bl1_plat_mem_check()`` also passes, this may result in an unexpectedly
+ large copy of data into secure memory.
+
+If the platform's implementation of ``bl1_plat_mem_check()`` is correct then it
+may help prevent the above 2 vulnerabilities from being exploited. However, the
+ARM platform version of this function contains a similar vulnerability:
+
+- Line 88 of ``plat/arm/common/arm_bl1_fwu.c`` in function of
+ ``bl1_plat_mem_check()``:
+
+ .. code:: c
+
+ while (mmap[index].mem_size) {
+ if ((mem_base >= mmap[index].mem_base) &&
+ ((mem_base + mem_size)
+ <= (mmap[index].mem_base +
+ mmap[index].mem_size)))
+ return 0;
+
+ index++;
+ }
+ ...
+
+ This function checks that the passed memory region is within one of the
+ regions mapped in by ARM platforms. Here, ``mem_size`` may be the
+ ``block_size`` passed from ``bl1_fwu_image_copy()``. A very large value of
+ ``mem_size`` may result in an integer overflow and the function to incorrectly
+ return success. Platforms that copy this insecure pattern will have the same
+ vulnerability.
+
+.. _CVE-2016-10319: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-10319
+.. _48bfb88: https://github.com/ARM-software/arm-trusted-firmware/commit/48bfb88
+.. _Pull Request #783: https://github.com/ARM-software/arm-trusted-firmware/pull/783
diff --git a/docs/security_advisories/security-advisory-tfv-2.rst b/docs/security_advisories/security-advisory-tfv-2.rst
new file mode 100644
index 0000000..0ed2a7f
--- /dev/null
+++ b/docs/security_advisories/security-advisory-tfv-2.rst
@@ -0,0 +1,61 @@
+Advisory TFV-2 (CVE-2017-7564)
+==============================
+
++----------------+-------------------------------------------------------------+
+| Title | Enabled secure self-hosted invasive debug interface can |
+| | allow normal world to panic secure world |
++================+=============================================================+
+| CVE ID | `CVE-2017-7564`_ |
++----------------+-------------------------------------------------------------+
+| Date | 02 Feb 2017 |
++----------------+-------------------------------------------------------------+
+| Versions | All versions up to v1.3 |
+| Affected | |
++----------------+-------------------------------------------------------------+
+| Configurations | All |
+| Affected | |
++----------------+-------------------------------------------------------------+
+| Impact | Denial of Service (secure world panic) |
++----------------+-------------------------------------------------------------+
+| Fix Version | 15 Feb 2017 `Pull Request #841`_ |
++----------------+-------------------------------------------------------------+
+| Credit | ARM |
++----------------+-------------------------------------------------------------+
+
+The ``MDCR_EL3.SDD`` bit controls AArch64 secure self-hosted invasive debug
+enablement. By default, the BL1 and BL31 images of the current version of ARM
+Trusted Firmware (TF) unconditionally assign this bit to ``0`` in the early
+entrypoint code, which enables debug exceptions from the secure world. This can
+be seen in the implementation of the ``el3_arch_init_common`` `AArch64 macro`_ .
+Given that TF does not currently contain support for this feature (for example,
+by saving and restoring the appropriate debug registers), this may allow a
+normal world attacker to induce a panic in the secure world.
+
+The ``MDCR_EL3.SDD`` bit should be assigned to ``1`` to disable debug exceptions
+from the secure world.
+
+Earlier versions of TF (prior to `commit 495f3d3`_) did not assign this bit.
+Since the bit has an architecturally ``UNKNOWN`` reset value, earlier versions
+may or may not have the same problem, depending on the platform.
+
+A similar issue applies to the ``MDCR_EL3.SPD32`` bits, which control AArch32
+secure self-hosted invasive debug enablement. TF assigns these bits to ``00``
+meaning that debug exceptions from Secure EL1 are enabled by the authentication
+interface. Therefore this issue only exists for AArch32 Secure EL1 code when
+secure privileged invasive debug is enabled by the authentication interface, at
+which point the device is vulnerable to other, more serious attacks anyway.
+
+However, given that TF contains no support for handling debug exceptions, the
+``MDCR_EL3.SPD32`` bits should be assigned to ``10`` to disable debug exceptions
+from AArch32 Secure EL1.
+
+Finally, this also issue applies to AArch32 platforms that use the TF SP_MIN
+image or integrate the `AArch32 equivalent`_ of the ``el3_arch_init_common``
+macro. Here the affected bits are ``SDCR.SPD``, which should also be assigned to
+``10`` instead of ``00``
+
+.. _CVE-2017-7564: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-7564
+.. _commit 495f3d3: https://github.com/ARM-software/arm-trusted-firmware/commit/495f3d3
+.. _AArch64 macro: https://github.com/ARM-software/arm-trusted-firmware/blob/bcc2bf0/include/common/aarch64/el3_common_macros.S#L85
+.. _AArch32 equivalent: https://github.com/ARM-software/arm-trusted-firmware/blob/bcc2bf0/include/common/aarch32/el3_common_macros.S#L41
+.. _Pull Request #841: https://github.com/ARM-software/arm-trusted-firmware/pull/841
diff --git a/docs/security_advisories/security-advisory-tfv-3.rst b/docs/security_advisories/security-advisory-tfv-3.rst
new file mode 100644
index 0000000..b395f13
--- /dev/null
+++ b/docs/security_advisories/security-advisory-tfv-3.rst
@@ -0,0 +1,86 @@
+Advisory TFV-3 (CVE-2017-7563)
+==============================
+
++----------------+-------------------------------------------------------------+
+| Title | RO memory is always executable at AArch64 Secure EL1 |
++================+=============================================================+
+| CVE ID | `CVE-2017-7563`_ |
++----------------+-------------------------------------------------------------+
+| Date | 06 Apr 2017 |
++----------------+-------------------------------------------------------------+
+| Versions | v1.3 (since `Pull Request #662`_) |
+| Affected | |
++----------------+-------------------------------------------------------------+
+| Configurations | AArch64 BL2, TSP or other users of xlat_tables library |
+| Affected | executing at AArch64 Secure EL1 |
++----------------+-------------------------------------------------------------+
+| Impact | Unexpected Privilege Escalation |
++----------------+-------------------------------------------------------------+
+| Fix Version | `Pull Request #924`_ |
++----------------+-------------------------------------------------------------+
+| Credit | ARM |
++----------------+-------------------------------------------------------------+
+
+The translation table library in ARM Trusted Firmware (TF) (under
+``lib/xlat_tables`` and ``lib/xlat_tables_v2``) provides APIs to help program
+translation tables in the MMU. The xlat\_tables client specifies its required
+memory mappings in the form of ``mmap_region`` structures. Each ``mmap_region``
+has memory attributes represented by the ``mmap_attr_t`` enumeration type. This
+contains flags to control data access permissions (``MT_RO``/``MT_RW``) and
+instruction execution permissions (``MT_EXECUTE``/``MT_EXECUTE_NEVER``). Thus a
+mapping specifying both ``MT_RO`` and ``MT_EXECUTE_NEVER`` should result in a
+Read-Only (RO), non-executable memory region.
+
+This feature does not work correctly for AArch64 images executing at Secure EL1.
+Any memory region mapped as RO will always be executable, regardless of whether
+the client specified ``MT_EXECUTE`` or ``MT_EXECUTE_NEVER``.
+
+The vulnerability is known to affect the BL2 and Test Secure Payload (TSP)
+images on platforms that enable the ``SEPARATE_CODE_AND_RODATA`` build option,
+which includes all ARM standard platforms, and the upstream Xilinx and NVidia
+platforms. The RO data section for these images on these platforms is
+unexpectedly executable instead of non-executable. Other platforms or
+``xlat_tables`` clients may also be affected.
+
+The vulnerability primarily manifests itself after `Pull Request #662`_. Before
+that, ``xlat_tables`` clients could not specify instruction execution
+permissions separately to data access permissions. All RO normal memory regions
+were implicitly executable. Before `Pull Request #662`_. the vulnerability
+would only manifest itself for device memory mapped as RO; use of this mapping
+is considered rare, although the upstream QEMU platform uses this mapping when
+the ``DEVICE2_BASE`` build option is used.
+
+Note that one or more separate vulnerabilities are also required to exploit this
+vulnerability.
+
+The vulnerability is due to incorrect handling of the execute-never bits in the
+translation tables. The EL3 translation regime uses a single ``XN`` bit to
+determine whether a region is executable. The Secure EL1&0 translation regime
+handles 2 Virtual Address (VA) ranges and so uses 2 bits, ``UXN`` and ``PXN``.
+The ``xlat_tables`` library only handles the ``XN`` bit, which maps to ``UXN``
+in the Secure EL1&0 regime. As a result, this programs the Secure EL0 execution
+permissions but always leaves the memory as executable at Secure EL1.
+
+The vulnerability is mitigated by the following factors:
+
+- The xlat\_tables library ensures that all Read-Write (RW) memory regions are
+ non-executable by setting the ``SCTLR_ELx.WXN`` bit. This overrides any value
+ of the ``XN``, ``UXN`` or ``PXN`` bits in the translation tables. See the
+ ``enable_mmu()`` function:
+
+ ::
+
+ sctlr = read_sctlr_el##_el(); \
+ sctlr |= SCTLR_WXN_BIT | SCTLR_M_BIT; \
+
+- AArch32 configurations are unaffected. Here the ``XN`` bit controls execution
+ privileges of the currently executing translation regime, which is the desired
+ behaviour.
+
+- ARM TF EL3 code (for example BL1 and BL31) ensures that all non-secure memory
+ mapped into the secure world is non-executable by setting the ``SCR_EL3.SIF``
+ bit. See the ``el3_arch_init_common`` macro in ``el3_common_macros.S``.
+
+.. _CVE-2017-7563: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-7563
+.. _Pull Request #662: https://github.com/ARM-software/arm-trusted-firmware/pull/662
+.. _Pull Request #924: https://github.com/ARM-software/arm-trusted-firmware/pull/924
diff --git a/docs/security_advisories/security-advisory-tfv-4.rst b/docs/security_advisories/security-advisory-tfv-4.rst
new file mode 100644
index 0000000..66dd542
--- /dev/null
+++ b/docs/security_advisories/security-advisory-tfv-4.rst
@@ -0,0 +1,124 @@
+Advisory TFV-4 (CVE-2017-9607)
+==============================
+
++----------------+-------------------------------------------------------------+
+| Title | Malformed Firmware Update SMC can result in copy or |
+| | authentication of unexpected data in secure memory in |
+| | AArch32 state |
++================+=============================================================+
+| CVE ID | `CVE-2017-9607`_ |
++----------------+-------------------------------------------------------------+
+| Date | 20 Jun 2017 |
++----------------+-------------------------------------------------------------+
+| Versions | None (only between 22 May 2017 and 14 June 2017) |
+| Affected | |
++----------------+-------------------------------------------------------------+
+| Configurations | Platforms that use AArch32 BL1 plus untrusted normal world |
+| Affected | firmware update code executing before BL31 |
++----------------+-------------------------------------------------------------+
+| Impact | Copy or authentication of unexpected data in the secure |
+| | memory |
++----------------+-------------------------------------------------------------+
+| Fix Version | `Pull Request #979`_ (merged on 14 June 2017) |
++----------------+-------------------------------------------------------------+
+| Credit | ARM |
++----------------+-------------------------------------------------------------+
+
+The ``include/lib/utils_def.h`` header file provides the
+``check_uptr_overflow()`` macro, which aims at detecting arithmetic overflows
+that may occur when computing the sum of a base pointer and an offset. This
+macro evaluates to 1 if the sum of the given base pointer and offset would
+result in a value large enough to wrap around, which may lead to unpredictable
+behaviour.
+
+The macro code is at line 52, referring to the version of the code as of `commit
+c396b73`_:
+
+.. code:: c
+
+ /*
+ * Evaluates to 1 if (ptr + inc) overflows, 0 otherwise.
+ * Both arguments must be unsigned pointer values (i.e. uintptr_t).
+ */
+ #define check_uptr_overflow(ptr, inc) \
+ (((ptr) > UINTPTR_MAX - (inc)) ? 1 : 0)
+
+This macro does not work correctly for AArch32 images. It fails to detect
+overflows when the sum of its two parameters fall into the ``[2^32, 2^64 - 1]``
+range. Therefore, any AArch32 code relying on this macro to detect such integer
+overflows is actually not protected.
+
+The buggy code has been present in ARM Trusted Firmware (TF) since `Pull Request
+#678`_ was merged (on 18 August 2016). However, the upstream code was not
+vulnerable until `Pull Request #939`_ was merged (on 22 May 2017), which
+introduced AArch32 support for the Trusted Board Boot (TBB) feature. Before
+then, the ``check_uptr_overflow()`` macro was not used in AArch32 code.
+
+The vulnerability resides in the BL1 FWU SMC handling code and it may be
+exploited when *all* the following conditions apply:
+
+- Platform code uses TF BL1 with the ``TRUSTED_BOARD_BOOT`` build option.
+
+- Platform code uses the Firmware Update (FWU) code provided in
+ ``bl1/bl1_fwu.c``, which is part of the TBB support.
+
+- TF BL1 is compiled with the ``ARCH=aarch32`` build option.
+
+In this context, the AArch32 BL1 image might fail to detect potential integer
+overflows in the input validation checks while handling the
+``FWU_SMC_IMAGE_COPY`` and ``FWU_SMC_IMAGE_AUTH`` SMCs.
+
+The ``FWU_SMC_IMAGE_COPY`` SMC handler is designed to copy an image into secure
+memory for subsequent authentication. This is implemented by the
+``bl1_fwu_image_copy()`` function, which has the following function prototype:
+
+.. code:: c
+
+ static int bl1_fwu_image_copy(unsigned int image_id,
+ uintptr_t image_src,
+ unsigned int block_size,
+ unsigned int image_size,
+ unsigned int flags)
+
+``image_src`` is an SMC argument and therefore potentially controllable by an
+attacker. A very large 32-bit value, for example ``2^32 -1``, may result in the
+sum of ``image_src`` and ``block_size`` overflowing a 32-bit type, which
+``check_uptr_overflow()`` will fail to detect. Depending on its implementation,
+the platform-specific function ``bl1_plat_mem_check()`` might get defeated by
+these unsanitized values and allow the following memory copy operation, that
+would wrap around. This may allow an attacker to copy unexpected data into
+secure memory if the memory is mapped in BL1's address space, or cause a fatal
+exception if it's not.
+
+The ``FWU_SMC_IMAGE_AUTH`` SMC handler is designed to authenticate an image
+resident in secure memory. This is implemented by the ``bl1_fwu_image_auth()``
+function, which has the following function prototype:
+
+.. code:: c
+
+ static int bl1_fwu_image_auth(unsigned int image_id,
+ uintptr_t image_src,
+ unsigned int image_size,
+ unsigned int flags)
+
+Similarly, if an attacker has control over the ``image_src`` or ``image_size``
+arguments through the SMC interface and injects high values whose sum overflows,
+they might defeat the ``bl1_plat_mem_check()`` function and make the
+authentication module read data outside of what's normally allowed by the
+platform code or crash the platform.
+
+Note that in both cases, a separate vulnerability is required to leverage this
+vulnerability; for example a way to get the system to change its behaviour based
+on the unexpected secure memory accesses. Moreover, the normal world FWU code
+would need to be compromised in order to send a malformed FWU SMC that triggers
+an integer overflow.
+
+The vulnerability is known to affect all ARM standard platforms when enabling
+the ``TRUSTED_BOARD_BOOT`` and ``ARCH=aarch32`` build options. Other platforms
+may also be affected if they fulfil the above conditions.
+
+.. _CVE-2017-9607: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9607
+.. _commit c396b73: https://github.com/ARM-software/arm-trusted-firmware/commit/c396b73
+.. _Pull Request #678: https://github.com/ARM-software/arm-trusted-firmware/pull/678
+.. _Pull Request #939: https://github.com/ARM-software/arm-trusted-firmware/pull/939
+.. _Pull Request #979: https://github.com/ARM-software/arm-trusted-firmware/pull/979
diff --git a/docs/security_advisories/security-advisory-tfv-5.rst b/docs/security_advisories/security-advisory-tfv-5.rst
new file mode 100644
index 0000000..97f7cd9
--- /dev/null
+++ b/docs/security_advisories/security-advisory-tfv-5.rst
@@ -0,0 +1,57 @@
+Advisory TFV-5 (CVE-2017-15031)
+===============================
+
++----------------+-------------------------------------------------------------+
+| Title | Not initializing or saving/restoring ``PMCR_EL0`` can leak |
+| | secure world timing information |
++================+=============================================================+
+| CVE ID | `CVE-2017-15031`_ |
++----------------+-------------------------------------------------------------+
+| Date | 02 Oct 2017, updated on 04 Nov 2019 |
++----------------+-------------------------------------------------------------+
+| Versions | All, up to and including v2.1 |
+| Affected | |
++----------------+-------------------------------------------------------------+
+| Configurations | All |
+| Affected | |
++----------------+-------------------------------------------------------------+
+| Impact | Leakage of sensitive secure world timing information |
++----------------+-------------------------------------------------------------+
+| Fix Version | `Pull Request #1127`_ (merged on 18 October 2017) |
+| | |
+| | `Commit e290a8fcbc`_ (merged on 23 August 2019) |
+| | |
+| | `Commit c3e8b0be9b`_ (merged on 27 September 2019) |
++----------------+-------------------------------------------------------------+
+| Credit | Arm, Marek Bykowski |
++----------------+-------------------------------------------------------------+
+
+The ``PMCR_EL0`` (Performance Monitors Control Register) provides details of the
+Performance Monitors implementation, including the number of counters
+implemented, and configures and controls the counters. If the ``PMCR_EL0.DP``
+bit is set to zero, the cycle counter (when enabled) counts during secure world
+execution, even when prohibited by the debug signals.
+
+Since TF-A does not save and restore ``PMCR_EL0`` when switching between the
+normal and secure worlds, normal world code can set ``PMCR_EL0.DP`` to zero to
+cause leakage of secure world timing information. This register should be added
+to the list of saved/restored registers both when entering EL3 and also
+transitioning to S-EL1.
+
+Furthermore, ``PMCR_EL0.DP`` has an architecturally ``UNKNOWN`` reset value.
+Since Arm TF does not initialize this register, it's possible that on at least
+some implementations, ``PMCR_EL0.DP`` is set to zero by default. This and other
+bits with an architecturally UNKNOWN reset value should be initialized to
+sensible default values in the secure context.
+
+The same issue exists for the equivalent AArch32 register, ``PMCR``, except that
+here ``PMCR_EL0.DP`` architecturally resets to zero.
+
+NOTE: The original pull request referenced above only fixed the issue for S-EL1
+whereas the EL3 was fixed in the later commits.
+
+.. _CVE-2017-15031: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-15031
+.. _Pull Request #1127: https://github.com/ARM-software/arm-trusted-firmware/pull/1127
+.. _Commit e290a8fcbc: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=e290a8fcbc
+.. _Commit c3e8b0be9b: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=c3e8b0be9b
+
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..9eeaeec
--- /dev/null
+++ b/docs/security_advisories/security-advisory-tfv-6.rst
@@ -0,0 +1,148 @@
+Advisory TFV-6 (CVE-2017-5753, CVE-2017-5715, CVE-2017-5754)
+============================================================
+
++----------------+-------------------------------------------------------------+
+| Title | Trusted Firmware-A 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 Trusted
+Firmware-A 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
+significantly 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
diff --git a/docs/security_advisories/security-advisory-tfv-7.rst b/docs/security_advisories/security-advisory-tfv-7.rst
new file mode 100644
index 0000000..8e06762
--- /dev/null
+++ b/docs/security_advisories/security-advisory-tfv-7.rst
@@ -0,0 +1,107 @@
+Advisory TFV-7 (CVE-2018-3639)
+==============================
+
++----------------+-------------------------------------------------------------+
+| Title | Trusted Firmware-A exposure to cache speculation |
+| | vulnerability Variant 4 |
++================+=============================================================+
+| CVE ID | `CVE-2018-3639`_ |
++----------------+-------------------------------------------------------------+
+| Date | 21 May 2018 (Updated 7 June 2018) |
++----------------+-------------------------------------------------------------+
+| Versions | All, up to and including v1.5 |
+| Affected | |
++----------------+-------------------------------------------------------------+
+| Configurations | All |
+| Affected | |
++----------------+-------------------------------------------------------------+
+| Impact | Leakage of secure world data to normal world |
++----------------+-------------------------------------------------------------+
+| Fix Version | `Pull Request #1392`_, `Pull Request #1397`_ |
++----------------+-------------------------------------------------------------+
+| Credit | Google |
++----------------+-------------------------------------------------------------+
+
+This security advisory describes the current understanding of the Trusted
+Firmware-A (TF-A) exposure to Variant 4 of the cache speculation 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`_.
+
+At the time of writing, the TF-A project is not aware of a Variant 4 exploit
+that could be used against TF-A. It is likely to be very difficult to achieve an
+exploit against current standard configurations of TF-A, due to the limited
+interfaces into the secure world with attacker-controlled inputs. However, this
+is becoming increasingly difficult to guarantee with the introduction of complex
+new firmware interfaces, for example the `Software Delegated Exception Interface
+(SDEI)`_. Also, the TF-A project does not have visibility of all
+vendor-supplied interfaces. Therefore, the TF-A project takes a conservative
+approach by mitigating Variant 4 in hardware wherever possible during secure
+world execution. The mitigation is enabled by setting an implementation defined
+control bit to prevent the re-ordering of stores and loads.
+
+For each affected CPU type, TF-A implements one of the two following mitigation
+approaches in `Pull Request #1392`_ and `Pull Request #1397`_. Both approaches
+have a system performance impact, which varies for each CPU type and use-case.
+The mitigation code is enabled by default, but can be disabled at compile time
+for platforms that are unaffected or where the risk is deemed low enough.
+
+Arm CPUs not mentioned below are unaffected.
+
+Static mitigation
+-----------------
+
+For affected CPUs, this approach enables the mitigation during EL3
+initialization, following every PE reset. No mechanism is provided to disable
+the mitigation at runtime.
+
+This approach permanently mitigates the entire software stack and no additional
+mitigation code is required in other software components.
+
+TF-A implements this approach for the following affected CPUs:
+
+- Cortex-A57 and Cortex-A72, by setting bit 55 (Disable load pass store) of
+ ``CPUACTLR_EL1`` (``S3_1_C15_C2_0``).
+
+- Cortex-A73, by setting bit 3 of ``S3_0_C15_C0_0`` (not documented in the
+ Technical Reference Manual (TRM)).
+
+- Cortex-A75, by setting bit 35 (reserved in TRM) of ``CPUACTLR_EL1``
+ (``S3_0_C15_C1_0``).
+
+Dynamic mitigation
+------------------
+
+For affected CPUs, this approach also enables the mitigation during EL3
+initialization, following every PE reset. In addition, this approach implements
+``SMCCC_ARCH_WORKAROUND_2`` in the Arm architectural range to allow callers at
+lower exception levels to temporarily disable the mitigation in their execution
+context, where the risk is deemed low enough. This approach enables mitigation
+on entry to EL3, and restores the mitigation state of the lower exception level
+on exit from EL3. For more information on this approach, see `Firmware
+interfaces for mitigating cache speculation vulnerabilities`_.
+
+This approach may be complemented by additional mitigation code in other
+software components, for example code that calls ``SMCCC_ARCH_WORKAROUND_2``.
+However, even without any mitigation code in other software components, this
+approach will effectively permanently mitigate the entire software stack, since
+the default mitigation state for firmware-managed execution contexts is enabled.
+
+Since the expectation in this approach is that more software executes with the
+mitigation disabled, this may result in better system performance than the
+static approach for some systems or use-cases. However, for other systems or
+use-cases, this performance saving may be outweighed by the additional overhead
+of ``SMCCC_ARCH_WORKAROUND_2`` calls and TF-A exception handling.
+
+TF-A implements this approach for the following affected CPU:
+
+- Cortex-A76, by setting and clearing bit 16 (reserved in TRM) of
+ ``CPUACTLR2_EL1`` (``S3_0_C15_C1_1``).
+
+.. _Google Project Zero: https://bugs.chromium.org/p/project-zero/issues/detail?id=1528
+.. _Arm Processor Security Update: http://www.arm.com/security-update
+.. _CVE-2018-3639: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-3639
+.. _Software Delegated Exception Interface (SDEI): http://infocenter.arm.com/help/topic/com.arm.doc.den0054a/ARM_DEN0054A_Software_Delegated_Exception_Interface.pdf
+.. _Firmware interfaces for mitigating cache speculation vulnerabilities: https://developer.arm.com/cache-speculation-vulnerability-firmware-specification
+.. _Pull Request #1392: https://github.com/ARM-software/arm-trusted-firmware/pull/1392
+.. _Pull Request #1397: https://github.com/ARM-software/arm-trusted-firmware/pull/1397
diff --git a/docs/security_advisories/security-advisory-tfv-8.rst b/docs/security_advisories/security-advisory-tfv-8.rst
new file mode 100644
index 0000000..ebe324e
--- /dev/null
+++ b/docs/security_advisories/security-advisory-tfv-8.rst
@@ -0,0 +1,103 @@
+Advisory TFV-8 (CVE-2018-19440)
+===============================
+
++----------------+-------------------------------------------------------------+
+| Title | Not saving x0 to x3 registers can leak information from one |
+| | Normal World SMC client to another |
++================+=============================================================+
+| CVE ID | `CVE-2018-19440`_ |
++----------------+-------------------------------------------------------------+
+| Date | 27 Nov 2018 |
++----------------+-------------------------------------------------------------+
+| Versions | All |
+| Affected | |
++----------------+-------------------------------------------------------------+
+| Configurations | Multiple normal world SMC clients calling into AArch64 BL31 |
+| Affected | |
++----------------+-------------------------------------------------------------+
+| Impact | Leakage of SMC return values from one normal world SMC |
+| | client to another |
++----------------+-------------------------------------------------------------+
+| Fix Version | `Pull Request #1710`_ |
++----------------+-------------------------------------------------------------+
+| Credit | Secmation |
++----------------+-------------------------------------------------------------+
+
+When taking an exception to EL3, BL31 saves the CPU context. The aim is to
+restore it before returning into the lower exception level software that called
+into the firmware. However, for an SMC exception, the general purpose registers
+``x0`` to ``x3`` are not part of the CPU context saved on the stack.
+
+As per the `SMC Calling Convention`_, up to 4 values may be returned to the
+caller in registers ``x0`` to ``x3``. In TF-A, these return values are written
+into the CPU context, typically using one of the ``SMC_RETx()`` macros provided
+in the ``include/lib/aarch64/smccc_helpers.h`` header file.
+
+Before returning to the caller, the ``restore_gp_registers()`` function is
+called. It restores the values of all general purpose registers taken from the
+CPU context stored on the stack. This includes registers ``x0`` to ``x3``, as
+can be seen in the ``lib/el3_runtime/aarch64/context.S`` file at line 339
+(referring to the version of the code as of `commit c385955`_):
+
+::
+
+ /*
+ * This function restores all general purpose registers except x30 from the
+ * CPU context. x30 register must be explicitly restored by the caller.
+ */
+ func restore_gp_registers
+ ldp x0, x1, [sp, #CTX_GPREGS_OFFSET + CTX_GPREG_X0]
+ ldp x2, x3, [sp, #CTX_GPREGS_OFFSET + CTX_GPREG_X2]
+
+In the case of an SMC handler that does not use all 4 return values, the
+remaining ones are left unchanged in the CPU context. As a result,
+``restore_gp_registers()`` restores the stale values saved by a previous SMC
+request (or asynchronous exception to EL3) that used these return values.
+
+In the presence of multiple normal world SMC clients, this behaviour might leak
+some of the return values from one client to another. For example, if a victim
+client first sends an SMC that returns 4 values, a malicious client may then
+send a second SMC expecting no return values (for example, a
+``SDEI_EVENT_COMPLETE`` SMC) to get the 4 return values of the victim client.
+
+In general, the responsibility for mitigating threats due to the presence of
+multiple normal world SMC clients lies with EL2 software. When present, EL2
+software must trap SMC calls from EL1 software to ensure secure behaviour.
+
+For this reason, TF-A does not save ``x0`` to ``x3`` in the CPU context on an
+SMC synchronous exception. It has behaved this way since the first version.
+
+We can confirm that at least upstream KVM-based systems mitigate this threat,
+and are therefore unaffected by this issue. Other EL2 software should be audited
+to assess the impact of this threat.
+
+EL2 software might find mitigating this threat somewhat onerous, because for all
+SMCs it would need to be aware of which return registers contain valid data, so
+it can sanitise any unused return registers. On the other hand, mitigating this
+in EL3 is relatively easy and cheap. Therefore, TF-A will now ensure that no
+information is leaked through registers ``x0`` to ``x3``, by preserving the
+register state over the call.
+
+Note that AArch32 TF-A is not affected by this issue. The SMC handling code in
+``SP_MIN`` already saves all general purpose registers - including ``r0`` to
+``r3``, as can be seen in the ``include/lib/aarch32/smccc_macros.S`` file at
+line 19 (referring to the version of the code as of `commit c385955`_):
+
+.. code:: c
+
+ /*
+ * Macro to save the General purpose registers (r0 - r12), the banked
+ * spsr, lr, sp registers and the `scr` register to the SMC context on entry
+ * due a SMC call. The `lr` of the current mode (monitor) is expected to be
+ * already saved. The `sp` must point to the `smc_ctx_t` to save to.
+ * Additionally, also save the 'pmcr' register as this is updated whilst
+ * executing in the secure world.
+ */
+ .macro smccc_save_gp_mode_regs
+ /* Save r0 - r12 in the SMC context */
+ stm sp, {r0-r12}
+
+.. _CVE-2018-19440: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-19440
+.. _commit c385955: https://github.com/ARM-software/arm-trusted-firmware/commit/c385955
+.. _SMC Calling Convention: https://developer.arm.com/docs/den0028/latest
+.. _Pull Request #1710: https://github.com/ARM-software/arm-trusted-firmware/pull/1710
diff --git a/docs/security_advisories/security-advisory-tfv-9.rst b/docs/security_advisories/security-advisory-tfv-9.rst
new file mode 100644
index 0000000..d73e74b
--- /dev/null
+++ b/docs/security_advisories/security-advisory-tfv-9.rst
@@ -0,0 +1,124 @@
+Advisory TFV-9 (CVE-2022-23960)
+============================================================
+
++----------------+-------------------------------------------------------------+
+| Title | Trusted Firmware-A exposure to speculative processor |
+| | vulnerabilities with branch prediction target reuse |
++================+=============================================================+
+| CVE ID | `CVE-2022-23960`_ |
++----------------+-------------------------------------------------------------+
+| Date | 08 Mar 2022 |
++----------------+-------------------------------------------------------------+
+| Versions | All, up to and including v2.6 |
+| Affected | |
++----------------+-------------------------------------------------------------+
+| Configurations | All |
+| Affected | |
++----------------+-------------------------------------------------------------+
+| Impact | Potential leakage of secure world data to normal world |
+| | if an attacker is able to find a TF-A exfiltration primitive|
+| | that can be predicted as a valid branch target, and somehow |
+| | induce misprediction onto that primitive. There are |
+| | currently no known exploits. |
++----------------+-------------------------------------------------------------+
+| Fix Version | `Gerrit topic #spectre_bhb`_ |
++----------------+-------------------------------------------------------------+
+| Credit | Systems and Network Security Group at Vrije Universiteit |
+| | Amsterdam for CVE-2022-23960, Arm for patches |
++----------------+-------------------------------------------------------------+
+
+This security advisory describes the current understanding of the Trusted
+Firmware-A exposure to the new speculative processor vulnerability.
+To understand the background and wider impact of these vulnerabilities on Arm
+systems, please refer to the `Arm Processor Security Update`_. The whitepaper
+referred to below describes the Spectre attack and mitigation in more detail
+including implementation specific mitigation details for all impacted Arm CPUs.
+
+
+`CVE-2022-23960`_
+-----------------
+
+Where possible on vulnerable CPUs that implement FEAT_CSV2, Arm recommends
+inserting a loop workaround with implementation specific number of iterations
+that will discard the branch history on exception entry to a higher exception
+level for the given CPU. This is done as early as possible on entry into EL3,
+before any branch instruction is executed. This is sufficient to mitigate
+Spectre-BHB on behalf of all secure world code, assuming that no secure world
+code is under attacker control.
+
+The below table lists the CPUs that mitigate against this vulnerability in
+TF-A using the loop workaround(all cores that implement FEAT_CSV2 except the
+revisions of Cortex-A73 and Cortex-A75 that implements FEAT_CSV2).
+
++----------------------+
+| Core |
++----------------------+
+| Cortex-A72(from r1p0)|
++----------------------+
+| Cortex-A76 |
++----------------------+
+| Cortex-A76AE |
++----------------------+
+| Cortex-A77 |
++----------------------+
+| Cortex-A78 |
++----------------------+
+| Cortex-A78AE |
++----------------------+
+| Cortex-A78C |
++----------------------+
+| Cortex-X1 |
++----------------------+
+| Cortex-X2 |
++----------------------+
+| Cortex-X3 |
++----------------------+
+| Cortex-A710 |
++----------------------+
+| Cortex-A715 |
++----------------------+
+| Cortex-Hunter |
++----------------------+
+| Neoverse-N1 |
++----------------------+
+| Neoverse-N2 |
++----------------------+
+| Neoverse-V1 |
++----------------------+
+| Neoverse-V2 |
++----------------------+
+| Neoverse-Poseidon |
++----------------------+
+
+For all other cores impacted by Spectre-BHB, some of which that do not implement
+FEAT_CSV2 and some that do e.g. Cortex-A73, the recommended mitigation is to
+flush all branch predictions via an implementation specific route.
+
+In case local workaround is not feasible, the Rich OS can invoke the SMC
+(``SMCCC_ARCH_WORKAROUND_3``) to apply the workaround. Refer to `SMCCC Calling
+Convention specification`_ for more details.
+
+`Gerrit topic #spectre_bhb`_ This patchset implements the Spectre-BHB loop
+workaround for CPUs mentioned in the above table. For CPUs supporting
+speculative barrier instruction, the loop workaround is optimised by using SB
+in place of the common DSB and ISB sequence. It also mitigates against
+this vulnerability for Cortex-A72 CPU versions that support the CSV2 feature
+(from r1p0). The patch stack also includes an implementation for a specified
+`CVE-2022-23960`_ workaround SMC(``SMCCC_ARCH_WORKAROUND_3``) for use by normal
+world privileged software. Details of ``SMCCC_ARCH_WORKAROUND_3`` can be found
+in the `SMCCC Calling Convention specification`_. The specification and
+implementation also enables the normal world to discover the presence of this
+firmware service. This patch also implements ``SMCCC_ARCH_WORKAROUND_3`` for
+Cortex-A57, Coxtex-A72, Cortex-A73 and Cortex-A75 using the existing workaround.
+for CVE-2017-5715. Cortex-A15 patch extends Spectre V2 mitigation to Spectre-BHB.
+
+The above workaround is enabled by default (on vulnerable CPUs only). Platforms
+can choose to disable them at compile time if they do not require them.
+
+For more information about non-Arm CPUs, please contact the CPU vendor.
+
+.. _Arm Processor Security Update: http://www.arm.com/security-update
+.. _CVE-2022-23960: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-23960
+.. _Gerrit topic #spectre_bhb: https://review.trustedfirmware.org/q/topic:"spectre_bhb"+(status:open%20OR%20status:merged)
+.. _CVE-2022-23960 mitigation specification: https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability
+.. _SMCCC Calling Convention specification: https://developer.arm.com/documentation/den0028/latest