CVE-2022-23960: Speculative Processor Vulnerability – Arm Developer

Sorry, your browser is not supported. We recommend upgrading your browser. We have done our best to make all the documentation and resources available on old versions of Internet Explorer, but vector image support and the layout may not be optimal. Technical documentation is available as a PDF Download.

Vulnerability of Speculative Processors to Cache Timing Side-Channel Mechanism****Updated on 08/March/2022

For details on the newly announced Spectre-BHB attack, consult the Spectre-BHB page.

In 2018, Google disclosed research findings identifying security vulnerabilities. Those vulnerabilities were based on cache timing side-channels exploiting processor speculation. These web pages contain the latest information on those attacks, including a list of affected Arm processors, and their potential mitigations. This page will be periodically updated when new attacks are disclosed, or new information about the processors or software mitigations is made public.

Cache timing side-channels are a well-understood concept in the area of security research and therefore not a new finding. However, this side-channel mechanism could enable someone to potentially extract some information that otherwise would not be accessible to software from processors that are performing as designed. This is the issue addressed here and in the Cache Speculation Side-channels white paper.

It is important to note that these methods are generally dependent on malware running locally. Practicing good security hygiene by keeping software up-to-date, and avoiding suspicious links or downloads, is imperative for users.

The majority of Arm processors are not impacted by any variation of this side-channel speculation mechanism. A definitive list of the subset of Arm-designed processors that are susceptible can be found below.

Cache Speculation Side-channels white paper

Download

What are the attack mechanisms?

There are four main variants of the exploits, as detailed by Google in their blogpost, that explain in detail the mechanisms:

• Variant 1: bounds check bypass store (CVE-2017-5753) and bounds check bypass store (CVE-2018-3693)
• Variant 2: branch target injection (CVE-2017-5715)
• Variant 3: using speculative reads of inaccessible data (CVE-2017-5754)
• Subvariant 3a: using speculative reads of inaccessible data (CVE-2018-3640)
• Variant 4: speculative bypassing of stores by younger loads despite the presence of a dependency (CVE-2018-3639)
• Straight-line speculation: speculatively executing the instructions linearly in memory following an unconditional change in control flow (CVE-2020-13844). For more information on this attack mechanism and potential mitigations, see the FAQ and this white paper.
• Spectre-BHB: branch target injection in the same software context (unlike Spectre v2, which injects branch targets across different exception levels) (CVE-2022-23960). For more information on this attack mechanism and potential mitigations, please see the information found on the Spectre-BHB page.

In addition, Arm has included information on a related variant to 3, noted as 3a, in the table below.

Follow the steps below to determine if there is any vulnerability for your devices and, if vulnerable, then the mitigation mechanisms.

Step 1

Check the table below to determine if you have an affected processor.

• Only affected cores are listed
• ****Other Arm cores that are NOT listed are NOT affected****
• No indicates the core affected by the particular variant for that version of the core, and the software mitigation should be applied
• Yes indicates affected by the particular variant but has a mitigation (unless otherwise stated)
• Cortex-R cores typically use a closed software stack. In those environments, applications or processes are strictly controlled, and therefore not exploitable

Processor

Revision

Variant 1

Variant 2

Variant 3

Variant3a

Variant 4

Spectre-BHB

Cortex-R7

All

Yes

Yes

No

No

No

Yes

Cortex-R8

All

Yes

Yes

No

No

No

Yes

Cortex-A8

All

Yes

Yes

No

No

No

No

Cortex-A9

All

Yes

Yes

No

No

No

No

Cortex-A12

All

Yes

Yes

No

No

No

No

Cortex-A15

All

Yes

Yes

No

Yes

No

No

Cortex-A17

All

Yes

Yes

No

No

No

No

Cortex-A57

All

Yes

Yes

No

Yes

Yes

Yes

Cortex-A65

All

Yes

No

No

No

No

Yes

Cortex-A65AE

All

Yes

No

No

No

No

Yes

Cortex-A72

Prior to r1p0

Yes

Yes

No

Yes

Yes

Yes

Cortex-A72*

r1p0 and after

Yes

No

No

No

Yes

Yes

Cortex-A73

Prior to r1p0

Yes

Yes

No

No

Yes

Yes

Cortex-A73*

r1p0 and after

Yes

No

No

No

Yes

Yes

Cortex-A75

Prior to r3p0

Yes

Yes

Yes

Yes

Yes

Yes

Cortex-A75*

r3p0 and after

Yes

No

No

N

Yes

Yes

Cortex-A76

Prior to r3p0

Yes

Yes

No

No

Yes

Yes

Cortex-A76*

r3p0 and after

Yes

No

No

No

No

Yes

Cortex-A77

Prior to r1p1

Yes

Yes

No

No

Yes

Yes

Cortex-A77*

Prior to r1p1

Yes

No

No

No

No

Yes

Cortex-A78*

All

Yes

No

No

No

No

Yes

Cortex-A78C*

All

Yes

No

No

No

No

No

Cortex-A78AE*

All

Yes

No

No

No

No

Yes

Cortex-A710*

All

Yes

No

No

No

No

Yes

Neoverse-E1

All

Yes

No

No

No

No

Yes

Neoverse-N1

Prior to r3p0

Yes

Yes

No

No

Yes

Yes

Neoverse-N1*

r3p0 and after

Yes

No

No

No

No

Yes

Neoverse-V1*

All

Yes

No

No

No

No

Yes

Neoverse-N2*

All

Yes

No

No

No

No

Yes

Cortex-X1*

All

Yes

No

No

No

No

Yes

Cortex-X2*

All

Yes

No

No

No

No

Yes

* Note: For Armv8.5-A and Armv9 hardware mitigations added to the indicated Arm CPUs, view the Armv8.5-A/Armv9 Updates document.

Step 2

• If you are running Linux, please follow the directions below according to the variant identified in the table.
• If you are running Android, please check with Google for the detail of supported kernel versions.
• If you are running another OS, please contact the OS vendor for details and refer to For non-Linux operating system below.
• For JIT development, please check with the run-time vendor for details.

For Linux

Variant 1

Where vulnerable code sequences (described in the Cache Speculation Side-channels white paper) have been identified, the action required is:

• Impacted kernel/driver code should be reworked to use the new cross-architectural ‘nospec’ accessors. These accessors implement suitable Arm ‘CSDB’ sequences and ensure the compiler generates speculation safe code sequences for bounds checks.
• Userspace code implementing software privilege boundaries should be reworked, using the approach discussed in Compiler support for mitigations.

Variant 2

The mitigation will vary by processor micro-architecture:

For Cortex-A57, Cortex-A72, Cortex-A73, and Cortex-A75 that have not been updated, please apply kernel patches and Trusted Firmware-A patches provided by Arm.

For Cortex-A8, Cortex-A9, Cortex-A12, Cortex-A15, and Cortex-A17 please apply the kernel patches provided by Arm.

View the available Kernel patches and Trusted Firmware-A patches.

Variant 3

For Cortex-A75:

• Ensure your kernel implements Kernel Page Table Isolation (KPTI), referring to the patches in the branch above. This variant impacts software executing at EL1/EL0 which share a translation regime. KPTI is used to unmap the kernel from a process address space when that process is running.

Variant 3a

For Cortex-A15, Cortex-A57, and Cortex-A72:

• In general, it is not believed that software mitigations for this issue are necessary. However, an update for the latest release of the Cortex-A72 does include a hardware mitigation for this issue. Please download the Cache Speculation Side-channels white paper for more details.

Variant 4

For Cortex-A76 and Neoverse N1:

Mitigation is based on dynamically disabling memory disambiguation via an implementation-defined control register. Implementing this functionality involves updates to Trusted Firmware. Linux patches were merged in the 4.18 release of the Linux kernel and backported to the 4.14 and 4.9 stable kernels.

Release versions of Neoverse N1, as well as updated versions of the Cortex-A76, have made the control feature architecturally defined, as well as added additional barrier operations to help software mitigate this issue. Support for the architectural mitigations was added to Linux in the 4.20 release.

For Cortex-A57, Cortex-A72, Cortex-A73, and Cortex-A75:

Mitigation is based on disabling a hardware feature (memory disambiguation) at boot via an implementation-defined control register.

View the Trusted Firmware-A Advisory.

For non-Linux operating systems

Variant 2

The mitigation will vary by processor micro-architecture:

For Cortex-A9, Cortex-A12, Cortex-A17, Cortex-R7, and Cortex-R8, invalidate the branch predictor using a BPIALL instruction. See below for mitigation of remaining affected cores.

For Cortex-A8:

• Invalidate the branch predictor using a BPIALL instruction.
• Set ACTRL[6] to 1 during early processor initialization.

For Cortex-A15:

• Set ACTLR[0]==1 from early initialization of the processor.
• Invalidate the branch predictor by performing an ICIALLU instruction.

For Cortex-A57 and Cortex-A72:

• Do one of the following:
  • Disable the current stage 1 MMU, execute an ISB, re-enable the MMU and execute an ISB. This must be done in an area of memory where the VA and the IPA (or PA if there is only one stage of translation) are the same.
  • Do an ERET from EL3 where SCTLR_EL3.M==1 to S-EL1 where SCTLR_EL1.M=0 followed by an SMC back to EL3.

For Cortex-A73:

• In AArch32: Invalidate the branch predictor using a BPIALL instruction.
• In AArch64: Switch into AArch32, then perform a BPIALL - this can be done by calling Secure EL1 code, which is typically using AArch32, to do the BPIALL.

For Cortex-A75:

• In AArch32: Invalidate the branch predictor using a BPIALL instruction.
• In AArch64: Switch into AArch32, then perform a BPIALL - this can be done by calling Secure EL1 code, which is typically using AArch32, to do the BPIALL.

Variant 4

The mitigation varies by processor micro-architecture. Memory disambiguation should be disabled at boot by setting the relevant control register bit:

For Cortex-A57 and Cortex-A72:

• Set bit 55 (disable load pass store) of CPUACTLR_EL1 (S3_1_C15_C2_0).

For Cortex-A73:

• Set bit 3 of S3_0_C15_C0_0.

For Cortex-A75:

• Set bit 35 of CPUACTLR_EL1 (S3_0_C15_C1_0)

For Cortex-A76:

• Set bit 16 of CPUACTLR2_EL1 (S3_0_C15_C1_1)

Please consult the latest version of the white paper for additional mitigations.

What about future Arm Cortex processors?

All future Arm Neoverse and Cortex processors provided to our licensees will be resilient to this style of attack, or will be mitigated by enhancements made to the Kernel and firmware. For details on updates to affected CPUs, as well as descriptions of mitigations added to Armv8.5-A, view the Armv8.5-A CPU Updates document.

Arm recommends that users deploy the software mitigations described in the Cache Speculation Side-channels white paper, and in the Spectre-BHB white paper, where protection against malicious applications is required. Arm’s Security Response Team will continue to research any potential mitigations, and work closely with our customers and partners. Please refer to the FAQ for additional information.