Image: Michael Borgers, Getty Images/iStockphoto
In January 2018, the Spectre and Meltdown security vulnerabilities were publicly disclosed, prompting widespread concern among security professionals as the duo can be used to steal data from nearly any computer, as well as iPhones and iPads and other mobile devices.
Spectre and Meltdown individually represent classes of hardware vulnerabilities, each with a number of variants dependent on specific silicon-level functionality. Differences between manufacturers (e.g., Intel vs. AMD) and architectures (e.g., x86-64 vs. Arm) make some processors vulnerable to more variants than others. While these are fundamentally hardware design flaws, attempts to remediate on a software level have seen some success.
Understanding of Spectre and Meltdown has increased significantly since the initial disclosure, and security researchers continue to study these vulnerabilities. Presently, 13 Spectre variants and 14 Meltdown variants have been identified. Initially, AMD processors were thought to be immune to Meltdown attacks, though one variant has been successfully demonstrated on AMD systems.
TechRepublic’s cheat sheet for Spectre and Meltdown is as a comprehensive guide to understanding how the vulnerabilities work, as well as a resource for the most up-to-date patching and mitigation information.
Note: TechRepublic’s cheat sheet to Spectre and Meltdown utilizes the stratification of variants, definitions, and explanations from “A Systematic Evaluation of Transient Execution Attacks and Defenses,” by Claudio Canella, Daniel Gruss, Moritz Lipp, Philipp Ortner, Michael Schwarz, and Benjamin von Berg of Graz University of Technology; Frank Piessens and Jo Van Bulck of KU Leuven; and Dmitry Evtyushkin of The College of William and Mary. That document serves as further analysis of the original papers in which Meltdown and Spectre were presented.
What are Spectre and Meltdown?
In the most basic definition, Spectre is a vulnerability allowing for arbitrary locations in the allocated memory of a program to be read. Meltdown is a vulnerability allowing a process to read all memory in a given system. Spectre and Meltdown are not singular flaws—they individually represent a class of closely-related variants.
Spectre and Meltdown are uniquely dangerous security vulnerabilities that allow malicious actors to bypass system security protections present in nearly every recent device with a CPU-not just PCs, servers, and smartphones, but also Internet of Things (IoT) devices like routers and smart TVs. By leveraging the duo, it is possible to read protected system memory, gaining access to passwords, encryption keys, and other sensitive information.
Spectre and Meltdown are representative examples of “transient execution” attacks, which rely on hardware design flaws in the implementation of speculative execution, instruction pipelining, and out-of-order execution in modern CPUs. While this trio are essential to performance optimizations inherent to modern processors, implementations of these vary between CPU manufacturers and microarchitectures; as a result, not all Spectre and Meltdown variants are exploitable on all microarchitectures.
Various factors have immeasurably complicated the understanding of Spectre and Meltdown, including:
- Technical differences in variances discovered after the initial disclosure
- The differing extent to which microarchitecture types are susceptible to transient execution attacks
- The difficulty of and differing ways in which Spectre and Meltdown risks can be mitigated
- The financial hit feared by processor manufacturers and hardware vendors
- Politics endemic to the IT industry
- Widely disseminated misinformation days before and immediately following initial disclosure
TechRepublic’s cheat sheet cites and contextualizes-or, as necessary, corrects-claims regarding Spectre and Meltdown that are incongruent with real-world circumstances regarding the duo.
What risks are associated with Spectre and Meltdown?
For cloud computing, Spectre and Meltdown can be leveraged by attackers to escape software containers, paravirtualized systems, and virtual machines.
As a standalone vulnerability, Spectre and Meltdown are fairly inefficient for mass data exfiltration, as initial research demonstrates Meltdown is able to access data at about 120 KB/s, with Spectre around 1.5 to 2 KB/s. Further, Spectre-BTB (Variant 2) requires 10-30 minutes for initialization on a system with 64 GB RAM, which is anticipated to scale “roughly linearly” with increases in host RAM size.
SEE: Cybersecurity strategy research: Common tactics, issues with implementation, and effectiveness (Tech Pro Research)
Exploitation of Spectre and Meltdown can be performed untraceably-that is, without leaving evidence of an exploit in system logs. This makes the pair difficult to detect in targeted malware attacks, though known malware signatures are still possible to determine by traditional means.
How do Spectre and Meltdown work?
The mechanics of Spectre and Meltdown require an understanding of how the microarchitecture of modern processors are designed.
A quick primer on modern processor design
Improvements in performance in modern processors are derived from a number of techniques. Limitations in augmenting the physical attributes of processors (shrinking transistor size and increasing clock frequencies) require architectural changes to how processors work in order to deliver higher-performing parts. These changes focus largely on parallelism: Optimizing and lengthening instruction pipelines, allowing multiple operations to be performed in parallel in a logical core (thread), and increasing the number of logical and physical cores on a processor.
Other properties in modern processors include virtual (paged) memory, a method that streamlines memory management across processes, privilege levels, which allow operating systems to control which areas of virtual memory can be read by other processes, and CPU cache, in which data in system RAM is cached in order to reduce latency.
Two independent optimization techniques of modern processors, used in conjunction, are key to understanding how Spectre and Meltdown are hardware-level vulnerabilities.
Out-of-order execution allows for the simultaneous use of all the execution units in a CPU core. As explained in the Meltdown paper, “Instead of processing instructions strictly in the sequential program order, the CPU executes them as soon as all required resources are available. While the execution unit of the current operation is occupied, other execution units can run ahead. Hence, instructions can be run in parallel as long as their results follow the architectural definition.”
The state of instructions processed out of order are stored in a re-order buffer, from which they are committed in order.
Speculative execution allows processors to speculate on future instruction directions and proactively execute instructions along these paths before knowing if the instructions are correct. An example in the Spectre paper, “Consider an example where the program’s control flow depends on an uncached value located in external physical memory. As this memory is much slower than the CPU, it often takes several hundred clock cycles before the value becomes known. Rather than wasting these cycles by idling, the CPU attempts to guess the direction of control flow, saves a checkpoint of its register state, and proceeds to speculatively execute the program on the guessed path.”
When the value arrives from memory, the correctness of the guess is checked. If correct, the results are committed, “yielding a significant performance gain as useful work was accomplished during the delay.” If wrong, the speculative execution is discarded. Performance wise, this is transparent-the speeds are comparable to idling, as if the speculative execution never occurred. Importantly, it is possible to speculatively execute instructions on both in-order and out-of-order pipelines.
In terms of security, speculative execution requires executing a program in potentially incorrect ways. To maintain functional correctness, these incorrectly speculated, or transient executions, are intended to not be exposed to the program. They are not committed, and are flushed from the execution pipeline, reverting architectural effects the instructions may have had.
However, according to the Systematic Evaluation paper, “While the architectural effects and results of transient instructions are discarded, microarchitectural side effects remain beyond the transient execution. This is the foundation of Spectre, Meltdown, and Foreshadow. These attacks exploit transient execution and encode secrets in the microarchitectural side effects (e.g., cache state) to transmit them (to the architectural level) to an attacker.”
How Spectre works
Spectre, according to the original authors of the Spectre paper, “[induces] a victim to speculatively perform operations that would not occur during strictly serialized in-order processing of the program’s instructions, and which leak victim’s confidential information via a covert channel to the adversary.”
Spectre attacks are conducted in three steps:
- The setup phase, in which the processor is mistrained to make “an exploitably erroneous speculative prediction.”
- The processor speculatively executes instructions from the target context into a microarchitectural covert channel.
- The sensitive data is recovered. This can be done by timing access to memory addresses in the CPU cache.
How Meltdown works
Meltdown exploits a race condition between memory access and privilege level checking while an instruction is being processed. In conjunction with a CPU cache side-channel attack, privilege level checks can be bypassed, allowing access to memory used by an operating system, or other running processes. In certain circumstances, this can be used to read memory in paravirtualized software containers.
Meltdown attacks, according to the original authors of the Meltdown paper, are conducted in three steps:
- The content of an attacker-chosen memory location, which is inaccessible to the attacker, is loaded into a register.
- A transient instruction accesses a cache line based on the secret content of the register.
- The attacker uses Flush+Reload to determine the accessed cache line and hence the secret stored at the chosen memory location.
Understanding the difference between Spectre and Meltdown
Despite the simultaneous publication of Spectre and Meltdown, the two exploit different properties of CPUs; the only commonality between Spectre and Meltdown is the utilization of transient execution.
Spectre relies on misprediction events to prompt transient instructions. Spectre works only with data accessible architecturally to an application. To contrast, Meltdown relies on transient out of order instructions following an exception. Meltdown relies on transient instructions inaccessible architecturally to an application.
How many variants of Spectre and Meltdown exist?
In the Systematic Evaluation paper, researchers created a tree illustrating potential attacks, defining 13 variants of Spectre and 14 variants of Meltdown (of which, negative results were shown for 6 of the 14).
Graph Data: Canella et al. Edited Image: James Sanders/TechRepublic
Variants of Spectre
This new classification of Spectre groups attacks by the microarchitectural element they exploit. This creates four primary attack types: Spectre-PHT, exploiting the Pattern History Table; Spectre-BTB, exploiting the Branch Target Buffer; Spectre-RSB, exploiting the Return Stack Buffer; and Spectre-STL, exploiting the CPUs memory disambiguation prediction (specifically, store-to-load forwarding).
The first three attack types rely on mistraining the branch predictor, which can occur in one of four ways, according to researchers:
- Within the same address space and the same branch location that is later exploited (same-address-space in-place mistraining)
- Within the same address space with a different branch (same-address-space out-of-place)
- Within an attacker-controlled address space with a branch at the same address as the victim branch (cross-address-space in-place)
- Within an attacker-controlled address space at a congruent address to the victim branch (cross-address-space out-of-place)
Spectre-PHT (Bounds Check Bypass)
Spectre-PHT encompasses Variant 1 (CVE-2017-5753) and Variant 1.1 (CVE-2018-3693), as well as NetSpectre.
Spectre-PHT has been demonstrated as possible in all four mistraining types (PHT-CA-IP, PHT-CA-OP, PHT-SA-IP, and PHT-SA-OP) on Intel, Arm, and AMD (Zen microarchitecture) processors.
Spectre-BTB (Branch Target Injection)
Spectre-BTB is Variant 2 (CVE-2017-5715).
In the Systematic Evaluation, Researchers have demonstrated it as possible in all four mistraining types (BTB-CA-IP, BTB-CA-OP, BTB-SA-IP, and BTB-SA-OP) on Intel, but out of place mistraining has not been demonstrated on AMD (Zen microarchitecture) or Arm, indicating they “assume that they are possible, but that they require a different set of bits that we were not able to determine.”
Spectre-RSB (Return Stack Buffer Mispredict)
Two groups of researchers have demonstrated Spectre-type vulnerabilities utilizing the Return Stack Buffer. These are published SpectreRSB and ret2spec, the latter of which notably has been demonstrated with JIT-compiled code in web browsers.
Spectre-RSB has been demonstrated in all four mistraining types (RSB-CA-IP, RSB-CA-OP, RSB-SA-IP, and RSB-SA-OP) on Intel and AMD (Zen microarchitecture). Arm claims that same-address-space mistraining is possible, but makes no mention of cross-address-space. The researchers indicate that “while we expect them to work, we were not able to observe any leakage with any of our proofs of-concept,” adding that “We assume that it is a timing issue.”
Spectre-STL (Speculative Store Bypass)
Spectre-STL, previously Variant 4 (CVE-2018-3639), was first disclosed in May 2018. It has been demonstrated on Intel, AMD, and Arm.
This is acutely different from other Spectre variants. It exploits store-to-load forwarding, which does not involve history-based prediction; because of this, mistraining (the first step) is not possible. As a result, Spectre-STL can only access memory in the same privilege level.
Variants of Meltdown
The new classification of Meltdown variants contains two levels. The first level categorizes attacks by the exception causing a transient execution. For page faults, these are subclassified by the page-table entry protection bits.
|Attack Variant||Memory||Cache||Register||Cross Privilege Level|
Table Data: Canella et al.
Further, for ease of understanding, Meltdown variants are classified by the type of data recoverable, and the ability to cross privilege levels.
Meltdown variants have been observed to rely solely on faults. Analysis of aborts and interrupts indicate that those functions provide no transient execution to exploit by Meltdown.
Meltdown-US (Supervisor-only Bypass)
Meltdown-US, previously Variant 3 (CVE-2017-5754), was the first Meltdown variant disclosed. Most processors include “user” and “supervisor” page-table attributes to designate ownership of virtual memory pages; Meltdown-US demonstrates the ability to read kernel memory from user space on pipelined processors that fail to transiently enforce these flags.
Refinements to Meltdown-US utilizing transactional synchronization extensions enable attackers to increase data access speed. Further, Meltdown-US is capable of extracting uncached data from memory.
Researchers successfully demonstrated Meltdown-US on Intel and Arm Cortex-A75.
Meltdown-P (Virtual Translation Bypass)
Meltdown-US, also known as Foreshadow (CVE-2018-3615), leverages flaws in Intel SGX (Software Guard Extensions). Meltdown-US forces a page fault to occur during unauthorized access to page-table memory, providing an exploitable path to reading protected memory.
When researchers disclosed Foreshadow to Intel, the company identified variants called Foreshadow-NG (CVE-2018-3620 and CVE-2018-3646) that allow attackers to read any data stored in L1 cache, including System Management Mode, host OS kernel, and hypervisor data. These variants can allow attackers on cloud platforms to read information from other virtual machines on the same physical hardware.
Researchers successfully demonstrated Meltdown-P is demonstrated on Intel processors. Intel’s documentation refers to Meltdown-P as L1 Terminal Fault (L1TF).
Meltdown-GP (System Register Bypass)
Meltdown-GP, also known as Variant 3a (CVE-2018-3640), allows attackers to read privileged system registers.
Researchers successfully demonstrated Meltdown-GP on Intel and Arm Cortex-A15, A57, and A72.
Meltdown-NM (FPU Register Bypass)
Meltdown-NM, also known as LazyFP (CVE-2018-3665), exploits speculative execution used in conjunction with context switching of the floating-point unit. Researchers demonstrated the ability to retrieve AES-NI keys.
Researchers successfully demonstrated Meltdown-NM on Intel processors.
Meltdown-RW (Read-only Bypass)
Relative to the above four attacks, Meltdown-RW is the first to bypass “page-table based access rights within the current privilege level,” according to the Systematic Evaluation. Further, Meltdown-RW demonstrates that “transient execution does not respect the ‘read/write’ page-table attribute. The ability to transiently overwrite read-only data within the current privilege level can bypass software-based sandboxes which rely on hardware enforcement of read-only memory.”
Meltdown-RW was initially erroneously labeled “Spectre Variant 1.2,” though because the cause of transient execution is a page-fault exception, the correct classification of this vulnerability is Meltdown.
Researchers successfully demonstrated Meltdown-RW on Intel and Arm processors.
Meltdown-PK (Protection Key Bypass)
Meltdown-PK exploits “Memory Protection Keys for Userspace” (PKU or PKEYs) first introduced in Intel’s Skylake-based Xeon CPUs. This variant bypasses read and write isolation for PKU within the containing process. According to the Systematic Evaluation, in which this variant was introduced, “in contrast to cross-privilege level Meltdown attack variants, there is no software workaround. Intel can only fix Meltdown-PK in new hardware or possibly via a microcode update,” though the functionality is only exposed in Linux if the kernel was configured and built with support enabled.
Meltdown-PK is exploitable only on Intel CPUs featuring PKU support.
Meltdown-BR (Bounds Check Bypass)
Meltdown-BR exploits the bound-range exceeded exception present in x86 processors. The variant can be used to capture out-of-bounds data safeguarded by the IA32 “bound” opcode on Intel or AMD, or MPX on Intel.
Researchers successfully demonstrated Meltdown-BR on Intel Skylake i5-6200U and AMD Ryzen ThreadRipper 1920X CPUs. This is the first, and presently only, Meltdown variant exploitable on AMD. No equivalent to “bound” exists on Arm.
Faults unexploitable by Meltdown
In Intel, AMD, and Arm systems, other possible faults indicated in the graph of variants do not produce scenarios exploitable by Meltdown. These include division errors (Meltdown-DE), supervisor access (Meltdown-SM), alignment faults (Meltdown-AC), segmentation faults (Meltdown-SS), and instruction fetch (Meltdown-XD and Meltdown-UD).
What products are affected by Spectre and Meltdown?
Spectre and Meltdown are wide-ranging hardware flaws that affect the vast majority of devices currently available for sale, devices currently deployed, and legacy devices dating back to the 1990s, though significant exceptions exist. Because Spectre and Meltdown individually represent a class of flaws-not a single vulnerability-the differences in microarchitecture design in different types of processors impact the extent to which processors are affected.
SEE: 10 dangerous app vulnerabilities to watch out for (free PDF) (TechRepublic)
For individual products and operating systems, the Spectre and Meltdown website maintains a comprehensive list of up-to-date guidance from vendors, including Microsoft, Amazon, and Google, as well as hardware manufacturers such as Apple, Dell, HP, and Lenovo.
In terms of the CPUs that power computers, smartphones, and other devices, products using Intel, AMD, Arm, or POWER CPUs have been demonstrated to be affected by both Spectre and Meltdown; however, not all products using those CPUs are vulnerable. Despite early media reports that “most CPUs released since 1995” are vulnerable, there is-frustratingly-no quick heuristic to determine if a CPU is vulnerable. To gain a better understanding of what is affected by Spectre and Meltdown, an explanation of microarchitecture is necessary.
The claim “most CPUs released since 1995” is a reference to Intel’s P6 microarchitecture, which was introduced with the Pentium Pro in November 1995. P6 was the first Intel processor to use speculative execution and out-of-order processing. This design was used for Pentium 2 and 3 (and Celeron and Xeon variants), and refined versions were used in Pentium M (and Celeron variant) and the first Intel Core Solo and Duo CPUs. P6-based products are unsupported by Intel, and are vulnerable to Spectre and Meltdown.
Intel’s NetBurst microarchitecture was introduced on the Pentium 4 in 2000, as the intended successor to P6. For a variety of reasons-including a 31-stage pipeline that proved to be more of an encumbrance than a benefit-NetBurst was unsuccessful and discontinued by 2008. NetBurst-based products are unsupported by Intel. No data is available to demonstrate that these products are vulnerable to Spectre or Meltdown, but should be considered vulnerable.
Intel Core and succeeding generations of that microarchitecture, including Nehalem, Sandy Bridge, Haswell, and Skylake, trace their lineage from P6, and are affected, as are the low-power Silvermont and Goldmont microarchitectures. Together, these microarchitectures comprise effectively every Intel Core and Intel Xeon processor since 2006, and Intel Atom processors since 2013, the full list of which is provided by Intel.
Conversely, the Itanium microarchitecture (IA-64) is not affected by Spectre and Meltdown, which is explicitly parallel, in-order, requiring the compiler to define what can be done in parallel. Without speculative execution, Spectre and Meltdown are not usable. Likewise, the Bonnell microarchitecture lacks speculative execution capabilities in the interest of power savings, making first-generation Atom processors immune.
AMD microarchitectures starting from K8 (Hammer) through Zen+ are vulnerable to Spectre. The K8 microarchitecture debuted in September 2003 with the Athlon 64, the first of AMD’s CPUs capable of running 64-bit Windows.
In contrast to Intel, AMD CPUs are not vulnerable to Spectre-BTB-SA-OP or Spectre-BTB-CA-OP.
Early reports indicated AMD CPUs are not vulnerable to Meltdown. AMD CPUs are vulnerable to the Meltdown-BR variant, publicly disclosed in November 2018.
SoCs such as the Qualcomm Snapdragon, Apple A-Series, MediaTek Helio, and NVIDIA Tegra, as well as SoCs from other companies including Broadcom, and server processors including Cavium ThunderX, Qualcomm Centriq, and Amazon (AWS) Graviton, utilize Arm microarchitectures.
According to Arm, only the Cortex-R7, R8, A8, A9, A12, A15, A57, A72, A73, A75, and A76 are affected by any variant of Spectre or Meltdown. These designs are used in SoCs by the aforementioned vendors; the designs are used in smartphones, tablets, and other devices.
IBM POWER9, POWER8, POWER7+, and POWER7 CPUs are partially vulnerable to Spectre and Meltdown, and have been patched by IBM. POWER4, 5, and 6 family CPUs are likewise partially vulnerable, though will not be patched, as those products have reached end of life.
How can I protect against Spectre and Meltdown?
Because of the nature of Spectre and Meltdown, ensuring the latest available patches for your system are installed is necessary. Troublingly, initial patches for Spectre and Meltdown focused on preventing exploitation of a specific methodology, not addressing the microarchitectural vulnerability enabling those attacks.
As of November 2018, on systems with the latest available patches, exploitation of some Spectre and Meltdown variants remained possible under specific circumstances.
Patches for Spectre and Meltdown should be considered a work in progress, with initial patching strategies introduced and rolled back due to instability or findings indicating they were ineffective against specific variants. It is unclear if the pair of vulnerabilities can be completely patched through microcode and software updates, though this uncertainty should not discourage users or administrators from deploying available patches. (This is elaborated on in the following section.)
Servers, desktops, and notebooks
Mitigations for Spectre and Meltdown are delivered through BIOS and OS updates. For BIOS updates, check with your manufacturer to determine if BIOS updates are available. When applying BIOS updates, follow the instructions exactly as provided by your system manufacturer to prevent inadvertently causing damage to your computer.
Generally speaking, OS updates are delivered automatically through Windows Update, the App Store (on Mac OS), or through the package manager on Linux systems. Updates will not be made available for an OS that has reached end of life, such as Windows XP.
iOS and Android devices
For users of Apple devices, including iPhone, iPad, and Apple TV devices, software and firmware updates have been issued to address Spectre and Meltdown.
For Android users, the first round of patches were delivered in the 2018-01-05 security patch level. Though this is not specific to Spectre and Meltdown, ensure that Android devices are updated to a minimum of 7.0 (Nougat), as prior versions are unsupported.
Cloud computing services
Generally, users of cloud computing services are reliant on the platform provider to update the underlying infrastructure. Users of cloud-powered virtual machines may need to update their VMs, though this may not be specific to Spectre and Meltdown.
How will installing patches to protect against Spectre and Meltdown affect my computer?
The creation, deployment, and performance of mitigations to Spectre and Meltdown are subject to political in-fighting proportional to the severity of the vulnerabilities. Early software patches for the duo were rife with optimization problems, leading to performance regressions for a variety of reasons, including patches being applied to systems not vulnerable to specific variants, patches to microcode and operating system kernels conflicting with each other, and poor testing prior to deployment leading to system instability, particularly on Windows.
A quick history lesson about Spectre and Meltdown
Disclosure of Spectre and Meltdown to affected vendors occurred on June 1, 2017, providing six months to develop mitigations for Spectre and Meltdown. While this nominally happened behind closed doors, the open-source nature of Linux and BSD led to pull requests for mitigations being submitted partially publicly.
Days before the public announcement of Spectre and Meltdown, patches had become publicly available and tested by developers on custom-built kernels. These patches were benchmarked, resulting in reports of “up to 30% performance regression” being bandied about in developer circles and technology news websites.
Taken generously, these benchmarks were “worst-case scenario.” Less generously, the way in which the kernels were built were simply faulty, as they omitted a component of the patches as actually shipped in production kernels from Debian, Ubuntu, Red Hat, and other Linux distributions.
Spectre relies on the exploitation of processor components that enable speculative execution. Eliminating this risk by disabling these components is a technically possible-but not practically useful-idea, as the performance degradation would be far too high. This strategy is not being seriously considered as a real-world solution to the problem.
One of the first Meltdown patches, Kernel Page Table Isolation (KPTI), was developed originally as KASLR prior to the discovery of Meltdown. KPTI addresses Meltdown by separating user-space and kernel-space page tables. System calls or interrupts have context switching overheads, incurring a performance penalty of 7-17%; using process-context identifiers (PCIDs) reduces that overhead. KPTI was been backported to kernel 4.4 and 4.9, but support for PCIDs had not been. A lateral kernel upgrade adding KPTI to those kernels indicates regressions, upgrading to the (then-latest) 4.14 with KPTI and PCIDs enabled showed performance increases in use cases with frequent context switching, such as PostgreSQL and Redis.
Initial patches causing system instability
Initial patches for Windows created system instability, with Microsoft’s initial patch being blacklisted on systems with third-party antivirus software, as the patch caused Blue Screen of Death incidents on these systems. Microsoft subsequently halted all updates to systems with incompatible third-party antivirus software. Microsoft’s Meltdown patch caused certain AMD systems running Windows 10 to boot loop, unfortunate both for the fact that AMD systems are not vulnerable to those variants of Meltdown, and Windows 10 Home users have no easy way of deferring updates, prompting Microsoft to withdraw the patch.
Intel’s first microcode update caused random reboots, first thought to affect only Haswell and Broadwell CPUs, and later confirmed to affect Ivy Bridge, Sandy Bridge, Skylake, and Kaby Lake CPUs. The issue became sufficiently widespread that Intel directed manufacturers to stop rolling out microcode updates until a new update could be issued.
Unsuccessful attempts by Microsoft to patch Windows 7 and Server 2008 R2 led to an incident called ” Total Meltdown,” making the vulnerability dramatically worse. The patch incorrectly set permissions, causing memory that should only be accessible to the kernel to be automatically mapped for every process running at user-level privileges; this allowed malicious programs to read complete system memory at speeds of gigabytes per second, instead of 120 KB/s which Meltdown is otherwise capable of.
In April 2018, it was discovered that patches in Windows 10 for Spectre and Meltdown prior to the April 2018 update were completely useless, as a program could access the entire kernel page table by calling NtCallEnclave. (The April 2018 Windows 10 Update caused a variety of other problems.)
Practical performance implications of patching
Microsoft’s original guidance on performance degradation noted that Spectre-PHT and Meltdown-US had minimal performance impact, though patching Spectre-BTB caused performance regressions. From the January 2018 post by Terry Myerson:
- With Windows 10 on newer silicon (2016-era PCs with Skylake, Kabylake or newer CPU), benchmarks show single-digit slowdowns, but we don’t expect most users to notice a change because these percentages are reflected in milliseconds.
- With Windows 10 on older silicon (2015-era PCs with Haswell or older CPU), some benchmarks show more significant slowdowns, and we expect that some users will notice a decrease in system performance.
- With Windows 8 and Windows 7 on older silicon (2015-era PCs with Haswell or older CPU), we expect most users to notice a decrease in system performance.
- Windows Server on any silicon, especially in any IO-intensive application, shows a more significant performance impact when you enable the mitigations to isolate untrusted code within a Windows Server instance. This is why you want to be careful to evaluate the risk of untrusted code for each Windows Server instance, and balance the security versus performance tradeoff for your environment.
These regressions are expected to be minimized in Windows 10 19H1, as Microsoft is planning to adopt Google’s Retpoline method to patch Spectre-BTB.
For Linux, performance impact is heavily configuration dependent. Performance regressions are likely to be more noticeable on older LTS kernels, particularly 4.4 and 4.9, though 4.14 or 4.19 are preferable. Regressions on desktop usage is negligible, though system calls or interrupts continue to incur context switching overheads, most visibly on database applications. This is reduced to margin-of-error territory by use of Retpoline on existing hardware.
A new mitigation, Single Thread Indirect Branch Predictors (STIBP), was introduced in kernel 4.20 for systems with up-to-date microcode, though has significant performance regressions associated with it. STIBP is unlikely to remain enabled, at least in the current state. The fix is intended to address Spectre-BTB across threads, though the PortSmash vulnerability announced in November 2018 is prompting users to disable symmetric multithreading (SMT) entirely, negating the need for that patch.
Will buying a new processor help protect against Spectre and Meltdown?
New processors do address the Spectre and Meltdown vulnerabilities at a hardware level, though buying a new processor for that reason alone is probably unwarranted. Patches presently available and immediately on the horizon reduce performance penalties for security to background noise.
SEE: Special report: A winning strategy for cybersecurity (free PDF) (TechRepublic)
However, as of November 2018, on systems with the latest available patches, exploitation of some Spectre and Meltdown variants remained possible under specific circumstances.
That said, Intel opted to not provide patches to certain CPUs released between 2007 and 2011, leaving them vulnerable. If you are using a computer powered by Bloomfield, Bloomfield Xeon, Clarksfield, Gulftown, Harpertown Xeon C0 and E0, Jasper Forest, Penryn/QC, SoFIA 3GR, Wolfdale, Wolfdale Xeon, Yorkfield, or Yorkfield Xeon CPUs, upgrading to newer hardware is advisable, independent of Spectre or Meltdown.
Intel included hardware-level fixes to some of the variants as part of the Coffee Lake-S Refresh series of workstation CPUs, as well as Xeon Cascade Lake CPUs for servers. AMD is providing fixes starting with Zen 2 CPUs, and Arm has provided hardware-level fixes in Cortex-A76, A53, A55, A32, A7, and A5 designs.