diff options
Diffstat (limited to 'docs/security_advisories')
| -rw-r--r-- | docs/security_advisories/index.rst | 16 | ||||
| -rw-r--r-- | docs/security_advisories/security-advisory-tfv-1.rst | 162 | ||||
| -rw-r--r-- | docs/security_advisories/security-advisory-tfv-2.rst | 61 | ||||
| -rw-r--r-- | docs/security_advisories/security-advisory-tfv-3.rst | 86 | ||||
| -rw-r--r-- | docs/security_advisories/security-advisory-tfv-4.rst | 124 | ||||
| -rw-r--r-- | docs/security_advisories/security-advisory-tfv-5.rst | 57 | ||||
| -rw-r--r-- | docs/security_advisories/security-advisory-tfv-6.rst | 148 | ||||
| -rw-r--r-- | docs/security_advisories/security-advisory-tfv-7.rst | 107 | ||||
| -rw-r--r-- | docs/security_advisories/security-advisory-tfv-8.rst | 103 | ||||
| -rw-r--r-- | docs/security_advisories/security-advisory-tfv-9.rst | 124 |
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 |