Vulnerability of Speculative Processors to Cache Timing Side-Channel Mechanism

Updated on 10/Jul/2018

Based on the recent research findings from Google on the potential new cache timing side-channels exploiting processor speculation, here is the latest information on possible Arm processors impacted and their potential mitigations. We will post any new research findings here as needed.

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 whitepaper.

It is important to note that this method is dependent on malware running locally which means it's imperative for users to practice good security hygiene by keeping their software up-to-date and avoid suspicious links or downloads.

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


Cache Speculation Side-channels whitepaper

Download

What are the attack mechanisms?

There are three 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)

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, all other Arm cores are NOT affected.
  • No indicates not affected by the particular variant.
  • Yes indicates affected by the particular variant but has a mitigation (unless otherwise stated).

Processor

Variant 1

Variant 2

Variant 3

Variant 3a

Variant 4

Cortex-R7

Yes*

Yes*

No

No

No

Cortex-R8

Yes*

Yes*

No

No

No

Cortex-A8

Yes

Yes

No

No

No

Cortex-A9

Yes

Yes

No

No

No

Cortex-A12

Yes

Yes

No

No

No

Cortex-A15

Yes

Yes

No

Yes

No

Cortex-A17

Yes

Yes

No

No

No

Cortex-A57

Yes

Yes

No

Yes

Yes

Cortex-A72

Yes

Yes

No

Yes

Yes

Cortex-A73

Yes

Yes

No

No

Yes

Cortex-A75

Yes

Yes

Yes

No

Yes

Cortex-A76

Yes

No

No

No

Yes

* Note for Cortex-R cores: The common usage model for Cortex-R is in non-open environments where applications or processes are strictly controlled and hence not exploitable.

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

Action required:

  • Where vulnerable code sequences (described in the Cache Speculation Side-channels whitepaper) have been identified.

  • 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 please apply kernel patches and Arm Trusted Firmware patches provided by Arm.

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

Kernel patches are available at https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=kpti

Arm Trusted Firmware is available at https://github.com/ARM-software/arm-trusted-firmware/wiki/ARM-Trusted-Firmware-Security-Advisory-TFV-6

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:

Variant 4

For Cortex-A76:

Mitigation is based on dynamically disabling memory disambiguation via an implementation-defined control register. Implementing this functionality involves updates to Trusted Firmware and Linux. References will be posted when available.

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.

Arm Trusted Firmware is available at https://github.com/ARM-software/arm-trusted-firmware/wiki/Trusted-Firmware-A-Security-Advisory-TFV-7

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)

 

What about future Arm Cortex processors?

All future Arm 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.

As of July 2018, Arm will have completed and made available updated RTL for Arm Cortex-A72, Arm Cortex-A73, and Arm Cortex-A75 to provide resilience against Variant 2. In addition, Arm Cortex-A75 will be updated to provide resilience against Variant 3.

Cortex-A76 (released end May 2018) is resilient to Variants 2 and 3.

Arm recommends that the software mitigations described in the Cache Speculation Side-channels whitepaper be deployed where protection against malicious applications is required.  Arm's expert Security Response Team will continue to research any potential mitigations working closely with our customers and partners.  Please refer to the FAQ for additional information.