Frequently asked questions
Q: Can you explain the problem in layman's terms?
Both attacks exploit existing side-channel techniques and could result in small bits of data being accessed through use of malware.
Malware using this method and running locally could potentially allow malicious actors to improperly gather small bits of sensitive data from privileged memory (DRAM or CPU cache).
Arm believes these exploits do not have the potential to corrupt, modify or delete data.
All variants are based on speculative memory access causing cache allocation. Timing analysis of memory accesses can then be used to reveal data that would otherwise be kept secret. Each mechanism is slightly different, and some are microarchitecture dependent. The impact of each variant on Arm cores, plus the solutions and how they should be applied, are described in the Software Overview for Arm Cores Paper.
Q: Please explain how Spectre Variant 4 differs from the other variants?
Variant 4 is a Spectre-type attack utilizing a CPU technology known as memory disambiguation, a technology used in high-end CPUs to enable greater out-of-order execution and higher performance.
Simply put, this is a race between a store and following load that target the same memory location whereby under specific conditions, a speculative load can overtake a store, resulting in the load returning stale data.
If a chain of suitable instructions can be constructed, this stale data can be used to construct an address that drives cache allocation. This can be used to leak data to an attacker across a privilege boundary in a similar way to existing variants.
Q: What Arm cores are impacted by Spectre Variant 4?
Four cores from the existing Cortex-A family are impacted: Cortex-A57, A72, A73 and A75. All cores impacted by all Spectre and Meltdown variants are listed at www.arm.com/security-update.
Q: What is a cache side-channel attack?
When using the time taken to execute instructions that access the cache (such as loads or stores) it's possible to infer what items are in the cache. By being able to infer such information, the values of addresses that have been used to allocate items into the cache can be deduced.
Q: What does this mean for the average mobile user?
Malicious actors would need to install malware on devices to execute any of these attacks. Users will greatly reduce their risk by following good security practices by avoiding suspicious links and downloads, and immediately installing any software updates when available from device makers.
Q: Which Arm processors are affected by Spectre and Meltdown variants?
A comprehensive and updated list of all Arm processors impacted by all known variants can be found at www.arm.com/security-update.
Q: What Arm chips are impacted?
Most chips based on Arm processors are not impacted by Spectre or Meltdown; Approximately 5-8% of the 125+ billion Arm-based chips ever produced.
Updated versions of the Cortex-A72, A73 and A75 cores resilient to Spectre variant 2 will be released to partners later this year.
Only Cortex-A75 is impacted by Meltdown; an updated version of the Cortex-A75 core which is resilient to Meltdown will be released to partners later this year.
Cortex-A15, A57 and A72 are impacted by Meltdown 3a.
No Cortex-M processors are impacted.
No classic Arm processors (Arm11 and prior) are impacted.
Two out-of-order, speculative Cortex-R processors could theoretically be affected. Details on Arm processors are impacted by known variants is at www.arm.com/security-update.
Q: Can Spectre variant 4 attacks be executed through a web browser?
Q: Is Arm impacted by Meltdown 3a? (CVE-2018-3640)?
In January 2018, Arm provided details on the Cortex-A cores (A15, A57 and A72) impacted. Arm believes that software mitigations for Meltdown 3a are not required for the impacted Arm cores. For more details, please refer to our whitepaper at www.arm.com/security-update.
Q: Can you describe the four Spectre and two Meltdown variants?
Variant 1: Bounds Check Bypass - Use existing code with access to secrets by making it speculatively execute memory operations with out-of-range arguments.
Variant 2: Branch Target Injection - Malicious code usurps properties of CPU branch prediction features to speculatively run code.
Variant 3: Rogue Data Load - Access memory controlled by the OS while running a malicious application.
Variant 3a - A different form of variant 3 identified by Arm. Variant 3a uses speculation to access a privileged system register.
Variant 4 - A Spectre-type attack using a CPU technology known as memory disambiguation.
Spectre is an alternative name for variants 1 and 2, and Meltdown is an alternative name for variant 3.
Detailed CVE descriptions for all known variants can be found at www.arm.com/security-update.
Q: Is there a fix for all the vulnerabilities?
Each variant will have a different set of mitigations. For all known variants impacting Arm cores, Arm has completed initial kernel patching, compiler work and firmware updates. We continue to monitor and work on mitigations. Detailed information on mitigations for all known variants can be found at www.arm.com/security-update.
Q: How can mobile or PC users know whether the mitigation measure has been applied to them or not?
We encourage end-users to frequently check the security update sites for their respective operator or OEM or inquire directly as to when security updates will be available for Spectre and Meltdown.
Q: Are all the fixes applicable to Arm architecture partner designs?
The vulnerabilities are dependent on processor micro-architecture and Arm cannot comment on how architecture partner designs are impacted. We advise you to contact Arm architecture partners directly with questions related to mitigations for their affected designs.
Q: What is Arm doing to ensure existing Android devices are updated with mitigations?
Arm has pushed out the necessary mitigations for all known Meltdown and Spectre variants to our ecosystem. In some cases, updates have been pushed to existing telephones that address the original vulnerabilities published in January 2018.
Questions about specific devices or timing for deploying security updates should be directed to OEMs.
Q: Are software mitigations available, and will I get them?
The major operating systems running on Arm are aware of these issues and are deploying software mitigations. Please contact the suppliers of that software for their plans in this regard.
Linux patches are now under community review and can be found here: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=kpti.
Arm trusted firmware patches are being made available through GitHub:
Specifications of the changes required in Firmware are available here.
Q: Will the Cortex-A cores impacted by Spectre variant 4 be updated for resiliency against the attack?
The mitigation for existing cores impacted by Spectre variant 4 is a straightforward configuration setting at boot and, therefore, does not require hardware-level modifications.
Q: Will the Cortex-A cores impacted by Spectre variant 1 be updated for resiliency against the attack?
Spectre variant 1 is an issue that a usually safe hardware mechanism becomes exploitable in a very small number of cases that need to be identified by the software. As such, it’s not possible for hardware to distinguish between apparently identical code sequences which are safe and those which are exploitable, and so it not practical to implement the generic fixes in the hardware without incurring significant performance degradation on safe code sequences. Therefore we regard it as being necessary for the software to be modified to avoid the issue.
Q: Will future ARM cores or architectures address this?
Future Arm cores and architectures will provide a range of features to address the issues that can be addressed within hardware, and will provide more optimised mechanisms to allow software to address the issues that need to be addressed in software.
Q: Is Google's Retpoline considered effective for mitigating variant 2 vulnerability on Arm based systems?
Arm has investigated the use of retpoline and has concluded that it doesn't provide effective mitigation on Arm-based systems. Retpoline relies on specific aspects of the design of the branch prediction logic in the CPU, which do not apply to Arm-based systems.
Variant 2 mitigations for Arm systems have been implemented in the Linux kernel and Arm Trusted Firmware and can be implemented in other operating systems. For details see www.arm.com/security-update.
See our FAQ "Are software mitigations available, and will I get them?" for more information.
Q: Will compilers provide mitigations for variant 2?
Arm is not currently aware of any effective compiler-based mitigation techniques (such as retpolines) for variant 2.
Variant 2 mitigations for Arm systems have been implemented in the Linux kernel and Arm Trusted Firmware, and can be implemented in other operating systems. For details see www.arm.com/security-update.
Q: How is TrustZone affected?
Arm Trusted Firmware has been updated to mitigate the known Spectre variants (1, 2 and 4) which could potentially create different levels of privilege.
For Meltdown, 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 Arm Trusted Firmware.
The link to the updated Trusted Firmware can be found at www.arm.com/security-update.
Q: Are any Arm cores affected by CVE-2018-3665?
No Arm Cortex cores are affected by the FPU state information attack described in CVE-2018-3665.
Q: My Arm processor operates with branch prediction and speculative execution, why is my processor not on the list of affected processors?
Power efficient processor implementations tend to have shorter pipelines with fewer backend stages, and may also lack more complex micro-architectural features such as out-of-order execution. While these processors do still use speculation, they tend to be less aggressively optimized which makes these attacks unfeasible.
Arm have looked at all processors in all families to assess their vulnerability and compiled the table of processors with their perceived vulnerability that can be seen on the Speculative Processor Vulnerability overview page. Any processor not on the table has been analyzed and deemed not susceptible.