spectre meltdown virtual machines

Stack Exchange Network

Stack Exchange network consists of 183 Q&A communities including Stack Overflow , the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Super User is a question and answer site for computer enthusiasts and power users. It only takes a minute to sign up.

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

can the spectre security vulnerability be in a virtual machine?

Is it possible that a virtual machine like VirtualBox has the security vulnerability "spectre"? I think the VM maybe does out-of-order execution, but in my opinion it is not possible to peek at the cache to read the result.

Is there any explanation how it is possible to read the cache of a virtual cpu?

• virtual-machine
• 4 Yes, A little research would have confirmed VMWare has released patches to address Spectre and Meltdown. The guest OS must be patched, in addition, to the actual hypervisor (both types) –  Ramhound Mar 3, 2018 at 13:41
• Depends on the level of virtualisation, I'd say. If you are simulating a virtual CPU, then you're probably safe. But that's not what modern VMs do. –  Bergi Mar 3, 2018 at 17:08
• Is there any explanation how it is possible to read the cache of a virtual cpu? –  user521153 Mar 3, 2018 at 17:15
• 1 @jms details are in the canonical post I linked in my answer: Spectre works on a different level ... In this attack, the attacker tricks the speculative execution to predictively execute instructions erroneously. In a nutshell, the predictor is coerced to predict a specific branch result that results in asking for an out-of-bound memory access that the victim process would not normally have requested resulting in incorrect speculative execution. Then by the side-channel, retrieves the value of this memory. In this way memory belonging to the victim process is leaked to the malicious process. –  Mokubai ♦ Mar 3, 2018 at 18:33
• 1 @jms Virtualization is only fast because it uses the physical CPU with as little abstraction as possible and relies on CPU hardware to provide isolation and abstraction. Things like qemu can do emulation which would be safer as it is not a hardware CPU, but it is much slower and is different from virtualization. –  Mokubai ♦ Mar 4, 2018 at 16:43

2 Answers 2

Yes Spectre can cross host/guest, guest/host and guest/guest boundaries because this is a CPU level flaw that means that potentially sensitive information can be leaked across anything that runs on a CPU core.

Most of the news stories on the internet speak about the cloud providers being worst hit by this as they have massive clusters of systems that are virtualised and could potentially be abused to leak sensitive information.

Most of the large providers should have been patched against the flaws by now, as best they can be, but this is going to be a problem that lives with us for some time.

Security.SE has a canonical Q & A regarding this and it mentions VM's:

I am running a Virtual Machine/Containers, to what extent am I vulnerable? As per Steffen Ullrich's answer Meltdown attacks do not cross VMs, only leaks kernel memory to local processes. Spectre can work across VMs. Also, from Steffen again , Meltdown and Spectre works with containers, as containers relies on the host kernel.

VMs use the actual CPU in your system with some privileged instructions trapped and able to be redirected. It uses the same caches and instructions as the host does. It is essentially just another layer within the physical CPU in your system.

Virtualization is only fast because it uses the physical CPU with as little abstraction as possible and relies on CPU hardware to provide isolation. Things like qemu can do emulation which would be safer as it is not a hardware CPU, but it is much slower and is different from virtualization.

From the Security.se canonical post again:

Spectre works on a different level and does not allow access to kernel-space data from user-space. In this attack, the attacker tricks the speculative execution to predictively execute instructions erroneously. In a nutshell, the predictor is coerced to predict a specific branch result (if -> true), that results in asking for an out-of-bound memory access that the victim process would not normally have requested, resulting in incorrect speculative execution. Then by the side-channel, retrieves the value of this memory. In this way, memory belonging to the victim process is leaked to the malicious process.

So, because the VM runs in actual CPU hardware and all it needs to do is run a particular loop to "train" the speculative execution engine. Then it can use precise timing to watch the caches for particular patterns of access indicative of the host or guest (or other VM) process that it is looking to exploit.

In this way it means that a machine is exploitable in every direction. From host to VM, from VM to host, and from VM to VM.

Yes, it is by no means easy and is a difficult thing to pull off as the VM CPU core could change at whim of the host and the host could happily schedule tasks on different cores as well, but over a long period of time enough information could be leaked to give up a secret key to some important system or account. Given enough time and some suitably stealthy software everything is potentially open.

If you wanted a "secure" VM then you have to guarantee that it's cores are isolated. The only real ways to block this attack would be to "force" the host and VMs to only use certain cores so that they are never running on the same hardware but this would lead to an effective increase in cost as you would not be able to have as many VMs on a given host. You would never be able to get away with running more VMs than you have cores available, which is something I would expect to be done on "low load" servers as many systems sit idle for 90% of their life.

• 2 I think you interpreted the question as "if the host CPU is affected, will the VM be affected, too?" As I understand the question, it asks "if the host CPU is not affected, can the VM still be affected?" Could you clear that up? –  AndreKR Mar 3, 2018 at 22:04
• 1 @AndreKR: currently all out-of-order execution CPUs are affected by Spectre; only with software workarounds can you make a system sort of safe (and thus the VM would have to care about this, although a hypervisor can isolate the guests from each other if the CPU provides the facilities, e.g. Intel's IBRS stuff). But on an in-order CPU with no speculative execution, no Spectre vulnerabilities of any sort can exist between any two pieces of software. The essence of Spectre is provoking speculative execution of something that puts secret data into microarchitectural state; in-order CPUs don't. –  Peter Cordes Mar 3, 2018 at 23:31
• The most interesting thing is not the speculative execution. The most interesting thing is how a process can find out what is in the cache - even in an VM. –  user521153 Mar 7, 2018 at 21:11
• @jms the side channel attacks available are facilitated and made useful by the speculative execution. The process may not be able to directly read cache lines, but the speculative execution can leak information by doing calculations that put values into the cache that can be detected or inferred by timing attacks. Section 4 of the spectre white paper has a good explanation: spectreattack.com/spectre.pdf –  Mokubai ♦ Mar 7, 2018 at 21:24

The gem5 simulator simulates CPU microarchitecture and can be used to study Spectre

If you are interested in studying/reproducing vulnerabilities purely with emulation, without using the host CPU, I don't think QEMU is detailed enough to observe them as it does not simulate the CPU pipeline.

gem5 however, is used to estimate system performance in research and development, and does simulate enough CPU internals for you to observe Spectre in a fully clean and controlled environment.

A cool x86_64 demo with visualization has been published at: http://www.lowepower.com/jason/visualizing-spectre-with-gem5.html

The downside of gem5 is that it is much slower than QEMU the simulation is more detailed.

You must log in to answer this question.

• The Overflow Blog
• Meetings are the worst. Let's reduce their blast radius
• Wondering how sustainable your buildings are? Make your data speak sponsored post
• Featured on Meta
• Alpha test for short survey in banner ad slots starting on week of September...
• What should be next for community events?

Hot Network Questions

• Can I shove a creature away from me in a particular direction?
• Mutual funds question: “You need to spend money to generate income that’s sustainable, because if you don’t, then you end up eroding your capital,”
• Powershell Export function to create environment variables with bash syntax
• Can I cast Clinging Ice twice on the same target?
• Source of a Poincaré quote: "Logic sometimes makes monsters..."
• Overstayed my visa in Germany by 9 days
• Expanding a modular space-station for 100 years
• Reviewing a potentially interesting, albeit unreadable paper
• What's the deal with Tek Knight's adaptation from "The Boys" comic book series into "Gen V"?
• How to handle boss' team invitation to go to a bar, when my coworker is an alcoholic in recovery?
• In a Ridge regression, why do i get a stronger sparsity when i remove some coefficients from the penalization term?
• Why are jurors asked if each element of a crime is proved, rather than the crime as a whole
• From R array to Numpy array
• How is Italy so rich, given its high corruption and crime?
• What to do if a paper is going to be published with my name included when they ignored repeated measures?
• A car catches fire in a carpark. The resulting fire spreads destroying the entire carpark. Who is liable?
• Why do we have sump pits?
• Which software is recommended for building RAID in Windows 10?
• Add items to JSON
• When was the last direct conflict within Israel's boundaries?
• Old story about slow light
• What is this lightbulb fixture, and how do I change it?
• What to do when advanced undergraduate and/or early graduate STEM students cannot perform correct math manipulations?
• Why is there a difference between pad-to-trace and trace-to-trace clearance?

Your privacy

By clicking “Accept all cookies”, you agree Stack Exchange can store cookies on your device and disclose information in accordance with our Cookie Policy .

• TechRepublic

Account Information

Spectre and Meltdown explained: A comprehensive guide for professionals

Share with Your Friends

Your email has been sent

Staying up to date on Spectre and Meltdown can be challenging. This guide includes in-depth explanations about these uniquely dangerous security vulnerabilities and the best mitigation solutions.

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

SEE: All of TechRepublic’s cheat sheets and smart person’s guides

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.

Following the disclosure of Spectre and Meltdown, further research into CPU side-channel flaws yielded a new vulnerability class, “ Microarchitectural Data Sampling ” (MDS), which exploits CPU-internal buffers rather than CPU caches. This target makes attacks that leverage MDS more difficult to mitigate, though are also more difficult for hackers to usefully exploit.

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.

Additional resources

• Major Intel, Arm chip security flaw puts your PCs, phones at risk (CNET)
• Congress: Please tell US about security vulnerabilities sooner (CNET)

What risks are associated with Spectre and Meltdown?

Spectre and Meltdown enable attackers to extract encryption keys and passwords from compromised systems, enabling other attacks dependent on access to compromised systems. Leveraging Spectre and Meltdown does not require a user to run a particular maliciously-formed executable, as JavaScript-based proofs-of-concept demonstrate the potential of exploiting these vulnerabilities inside a web browser. (In response, browser vendors have reduced the precision of high-resolution timers needed to successfully carry out an attack.)

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.

• Meltdown-Spectre: Malware is already being tested by attackers (ZDNet)
• Class-action suits over Intel Spectre, Meltdown flaws surge (CNET)

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.

• Beyond Spectre: Foreshadow, a new Intel security problem (ZDNet)
• All Intel chips open to new Spoiler non-Spectre attack: Don’t expect a quick fix (ZDNet)

How many variants of Spectre and Meltdown exist?

In the Systematic Evaluation paper , researchers created a tree illustrating potential variants, defining 13 exploitable variants of Spectre and 14 variants of Meltdown (of which, 6 of the 14 are not exploitable).

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.

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-P, also known as Foreshadow (CVE-2018-3615), leverages flaws in Intel SGX (Software Guard Extensions). Meltdown-P 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).

• SpectreRSB: New attack targets CPU return stack buffers (ZDNet)
• AMD on chip flaws: ‘Newly outed bugs are real but no big deal, and fixes are coming’ (ZDNet)

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.

Notably, the Raspberry Pi series of single-board computers use ARM1176, Cortex-A7, and A53 designs. These designs lack speculative execution capabilities, making them immune to Spectre and Meltdown .

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.

• Meltdown-Spectre: IBM preps firmware and OS fixes for vulnerable Power CPUs (ZDNet)
• Meltdown-Spectre: Oracle’s critical patch update offers fixes against CPU attacks (ZDNet)
• Intel: We now won’t ever patch Spectre variant 2 flaw in these chips (ZDNet)
• Spectre and Meltdown: Linux creator Linus Torvalds criticises Intel’s ‘garbage’ patches (ZDNet)

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 to tell if your Linux machine is patched against Meltdown and Spectre (TechRepublic)
• Microsoft delivers free Meltdown-Spectre assessment tool for IT pros (ZDNet)
• Apple releases iOS update to patch Spectre chip flaw (CNET)
• How to protect Windows Server from Meltdown and Spectre (ZDNet)

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.

• Windows 10 alert: All versions get new Intel patches for Spectre, Foreshadow bugs (ZDNet)
• Meltdown and Spectre response hampered by ‘exclusive club’ secrecy (ZDNet)
• Windows Meltdown-Spectre: Watch out for fake patches that spread malware (ZDNet)
• Check if your Chromebook is protected against the Meltdown vulnerability (CNET)

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.

• Meltdown-Spectre amplifies call for new hardware-software contract (ZDNet)
• CES 2019: AMD releasing 7nm Ryzen 3 in 2019, while Intel struggles to ship 10nm CPUs (TechRepublic)
• CES 2019: Intel’s 10nm Ice Lake CPUs, 5G solutions offer greater performance and security (TechRepublic)

Subscribe to the Daily Tech Insider Newsletter

Stay up to date on the latest in technology with Daily Tech Insider. We bring you news on industry-leading companies, products, and people, as well as highlighted articles, downloads, and top resources. You’ll receive primers on hot tech topics that will help you stay ahead of the game.

• See all of James's content
• Cheat Sheets

Editor's Picks

TechRepublic Premium Editorial Calendar: Policies, Checklists, Hiring Kits and Research for Download

TechRepublic Premium content helps you solve your toughest IT issues and jump-start your career or next project.

7 Best AI Art Generators of 2023

This is a comprehensive list of the best AI art generators. Explore the advanced technology that transforms imagination into stunning artworks.

The Best Cheap Payroll Services for 2023

Find the perfect payroll service for your business without breaking the bank. Discover the top cheap payroll services, features, pricing and pros and cons.

NordVPN Review (2023): Pricing, Security & Performance

Is NordVPN worth it? How much does it cost and is it safe to use? Read our NordVPN review to learn about pricing, features, security, and more.

Best Free Project Management Software for 2023

Free project management software provides flexibility for managing projects without paying a cent. Check out our list of the top free project management tools.

Cloud Strategies Are Facing a New Era of Strain in Australia, New Zealand

Australian and New Zealand enterprises in the public cloud are facing pressure to optimize cloud strategies due to a growth in usage and expected future demand, including for artificial intelligence use cases.

Portable Storage Policy

Portable storage media allow employees to access or back up business data both inside and outside the office. However, the ease of use presented by portable storage devices can also place companies at significant risk of lost or stolen data. Moreover, malware can infect portable storage media, which can then be inadvertently or purposely introduced ...

MSP Best Practices: Network Switch and Router Deployment Checklist

No managed services provider should lock itself out of the very network switches or routers it deploys, yet such accidents occur. Network switches have become increasingly complex and sometimes route virtual local area network traffic, while routers power an ever-expanding smorgasbord of filters and services. As a result, it’s easier than ever to skip an ...

Quick Glossary: Financial Crime

As financial technology offers advancements and innovations, it also brings along new risks for financial crimes. Recognizing terms and ideas related to financial crime can help businesses enforce safeguards, identify suspicious activities and prevent financial losses caused by tech-related crimes. TechRepublic Premium presents this glossary of terms and concepts to help your understanding. From the ...

• TechRepublic on Twitter
• TechRepublic on Facebook
• TechRepublic on LinkedIn
• TechRepublic on Flipboard
• Privacy Policy
• Terms of Use
• Property of TechnologyAdvice

VMware Performance Impact for CVE-2017-5753, CVE-2017-5715, CVE-2017-5754 (aka Spectre and Meltdown) (52337)

VMware described its overall response to a specific set of recently discovered CPU security vulnerabilities in KB 52245 : VMware Response to Speculative Execution security issues, CVE-2017-5753, CVE-2017-5715, CVE-2017-5754 (aka Spectre and Meltdown). Since then, customers have inquired if there may be a performance cost associated with either the VMware mitigations, or mitigations of the guest operating systems as released from the OS providers. This knowledge base article will be used as the centralized document to discuss such performance impacts.

VMware has conducted performance testing to determine the costs of the Meltdown/Spectre mitigations for VMware products. We have tested a wide variety of workloads ( with and without vSAN ) on guest operating systems both with mitigation (“patched”) and without mitigation (“unpatched”) to provide a comprehensive view of relevant performance characteristics. All testing to date has been conducted on a representative range of recent Intel Xeon server processors. Note that the latest ESXi patches include relevant Intel and AMD CPU microcode for Spectre V2 mitigations. For understanding the performance impact to virtualization environments, we classify the mitigations into two performance categories.  Our conclusions for each are as follows: Virtualization Layer Mitigations : The latest ESXi patches** and the relevant Intel CPU microcode but without Guest Operating System mitigation patches. These mitigations have a minimal performance impact (< 2%) for most workloads on a representative range of recent Intel Xeon server processors. Full Stack Mitigations : All levels of mitigation. This includes all virtualization layer mitigations above with the addition of Guest Operating System mitigation patches. As reported in the press, the impact of these mitigations will vary depending on your application. Applications with very heavy system call usage, including those with very high IO rates, will show a more significant impact than their counterparts with lower system call usage. For information regarding the performance impact of Operating System Mitigations on your application, please consult with your Operating system and/or Application vendor. Consistent with our findings above, the virtualization layer mitigations that are part of these full stack mitigations have minimal influence to the overall impact . As a general best practice, we recommend you test the appropriate patches with your applications prior to deploying in production environments. Please sign up to be alerted when this KB is updated with new information. Footnote: ** = This includes Hypervisor-Specific vSphere mitigations, Intel CPU microcode updates for Spectre V2, and also the implementation of Hypervisor-Assisted Guest Mitigation even though no Guest Operating System has been patched to use them.

• Generative AI
• Business Operations
• IT Leadership
• Application Security
• Business Continuity
• Cloud Security
• Critical Infrastructure
• Identity and Access Management
• Network Security
• Physical Security
• Risk Management
• Security Infrastructure
• Vulnerabilities
• Software Development
• United States
• United Kingdom
• Newsletters
• Foundry Careers
• Privacy Policy
• Cookie Policy
• Member Preferences
• About AdChoices
• E-commerce Links
• Your California Privacy Rights

Our Network

• Computerworld
• Network World

Spectre and Meltdown explained: What they are, how they work, what’s at risk

Spectre and Meltdown are the names given to a trio of variations on a vulnerability that affects nearly every computer chip manufactured in the last 20 years. The flaws are so fundamental and widespread that security researchers are calling them catastrophic.

In the first days of 2018, published research revealed that nearly every computer chip manufactured in the last 20 years contains fundamental security flaws, with specific variations on those flaws being dubbed Spectre and Meltdown. The flaws arise from features built into chips that help them run faster, and while software patches are available, they may have impacts on system performance. There is as of yet no evidence that these flaws have been exploited in the wild, but such exploits would be difficult to detect, and the flaws are so fundamental and widespread that security researchers are calling them catastrophic.

What are Spectre and Meltdown?

Spectre and Meltdown are the names given to different variants of the same fundamental underlying vulnerability that affects nearly every computer chip manufactured in the last 20 years and could, if exploited, allow attackers to get access to data previously considered completely protected. Security researchers discovered the flaws late in 2017 and publicized them in early 2018. Technically, there are three variations on the vulnerability, each given its own CVE number ; two of those variants are grouped together as Spectre and the third is dubbed Meltdown .

All of the variants of this underlying vulnerability involve a malicious program gaining access to data that it shouldn’t have the right to see, and do so by exploiting two important techniques used to speed up computer chips, called speculative execution and caching.

What is speculative execution?

Speculative execution essentially involves a chip attempting to predict the future in order to work faster. If the chip knows that a program involves multiple logical branches, it will start working out the math for all of those branches before the program even has to decide between them. For instance, if the program says, “If A is true, compute function X; if A is false, compute function Y”, the chip can start computing both functions X and Y in parallel, before it even knows whether A is true or false. Once it knows whether A is true or false, it already has a head start on what comes after, which speeds up processing overall. Or, in another variation, if a chip learns that a program makes use of the same function frequently, it might use idle time to compute that function even when it hasn’t been asked to, just so it has what it thinks the answer will be on hand.

What is caching?

Caching is a technique used to speed up memory access. It takes a relatively long time for the CPU to fetch data from RAM, which lives on a separate chip, so there’s a special small amount of memory storage called CPU cache on that lives on the CPU chip itself and that can be accessed very quickly. This memory gets filled with data that the chip will need soon, or often. What’s relevant for our situation is that data that’s output by speculative execution is often stored in cache, which is part of what makes speculative execution a speed booster.

The problem arises when caching and speculative execution start grappling with protected memory.

What is protected memory?

Protected memory is one of the foundational concepts underlying computer security. In essence, no process on a computer should be able to access data unless it has permission to do so. This allows a program to keep some of its data private from some of its users, and allows the operating system to prevent one program from seeing data belonging to another. In order to access data, a process needs to undergo a privilege check, which determines whether or not it’s allowed to see that data.

But a privilege check can take a (relatively) long time. So — and this is the key to the vulnerability we’re discussing — while the CPU is waiting to find out if the process is allowed to access that data, thanks to speculative execution, it starts working with that data even before it receives permission to do so. In theory this is still secure, because the results of that speculative execution are also protected at the hardware level. The process isn’t allowed to see them until it passes the privilege check, and if it doesn’t pass the check, the data is discarded.

The problem arises because the protected data is stored in CPU cache even if the process never receives permission to access it. And because CPU cache memory can be accessed more quickly than regular memory, the process can attempt to access certain memory locations to find out if the data there has been cached — it still won’t be able to access the data, but if the data has been cached, its attempt to read it will be rejected much more quickly than it otherwise would. Think of it as knocking on a box to see if it’s hollow. Because of the way computer memory works, just knowing the addresses where data is stored can help you deduce what the data is. This is what’s known as a side-channel attack.

What’s the difference between Spectre and Meltdown?

If you want a much more technical description of how Spectre and Meltdown work, you should check out the post on Google’s Project Zero site that was most of the world’s introduction to it. To keep it short and simple, both Spectre and Meltdown could allow potential attackers to get access to data they shouldn’t have access to using the techniques outlined above, but their effects are somewhat different:

• Meltdown got its name because it “melts” security boundaries normally enforced by hardware . By exploiting Meltdown, an attacker can use a program running on a machine to gain access to data from all over that machine that the program shouldn’t normally be able to see, including data belonging to other programs and data that only administrators should have access to. Meltdown doesn’t require too much knowledge of how the program the attacker hijacks works, but it only works with specific kinds of Intel chips. This is a pretty severe problem but fixes are being rolled out.
• By exploiting the Spectre variants, an attacker can make a program reveal some of its own data that should have been kept secret. It requires more intimate knowledge of the victim program’s inner workings, and doesn’t allow access to other programs’ data, but will also work on just about any computer chip out there. Spectre’s name comes from speculative execution but also derives from the fact that it will be much trickier to stop — while patches are starting to become available, other attacks in the same family will no doubt be discovered. That’s the other reason for the name: Spectre will be haunting us for some time.

Why are Spectre and Meltdown dangerous?

Spectre and Meltdown both open up possibilities for dangerous attacks. For instance, JavaScript code on a website could use Spectre to trick a web browser into revealing user and password information. Attackers could exploit Meltdown to view data owned by other users and even other virtual servers hosted on the same hardware, which is potentially disastrous for cloud computing hosts.

But beyond the potential specific attacks themselves lies the fact that the flaws are fundamental to the hardware platforms running beneath the software we use every day. Even code that is formally secure as written turns out to be vulnerable, because the assumptions underlying the security processes built into the code — indeed, built into all of computer programming — have turned out to be false.

Spectre and Meltdown patches

The fundamental vulnerability exists at the hardware level and cannot be patched. However, most vendors are releasing software patches that work around the problems. The KAISER patch, developed coincidentally in 2017 to improve Linux security, actually has the side effect of preventing Meltdown attacks . Major cloud vendors have by and large patched their servers. Patches have already been rolled out by Intel, Microsoft, Apple, and Google (see more below) and more are on the way. CSO’s J.M. Porup has a good roundup of steps you should take in the short term . Rendition Infosec also has a great resource on establishing a strategy for your organization that will, among other things, harden your systems and practices to prevent further damage if you do fall victim to an attack exploiting Spectre or Meltdown.

Since JavaScript in the browser is one particularly dangerous vector for Spectre attacks, it’s also important keep your browsers up to date.

Notably, older systems, particularly Windows XP, will almost certainly never be patched. Also left in the lurch are the millions of third-party, low-cost Android phones that don’t get security updates from Google , many of which are not particularly old.

When will my PC, Mac, iPhone, Android phone, or browser get a patch for Meltdown and Spectre?

• As of January 11th, Microsoft has released operating system patches for most versions of Windows from Windows 7 on , which also patch the company’s Internet Explorer and Edge browsers. The previous link also includes a roundup of links to firmware updates from hardware manufacturers, which cover all the major players. However, some AMD systems after downloading the patches did not restart, so those patches have been pulled for the moment .
• Apple released patched versions of its macOS, iOS, and tvOS operating systems , as well as its Safari browser, on January 3rd.
• Google released a list of which Chromebook models have been patched or won’t need a patch (most of them), which will be patched soon, and which are end-of-lifed and won’t see a patch.
• Firefox has a patch that will be released on January 23rd , but is now available in beta.
• Google’s Chrome browser has a patch that will be released on January 23rd . You can turn on the experimental Site Isolation feature in the meantime to protect yourself.
• The multiplicity of Android handsets makes the question of whether your Android phone is or will be patched difficult to answer. Most phones sold directly from Google or giants like Samsung are patched or will be, but many will not. The Italian trade-in company RiCompo has a site that keeps you up to date on many different brands and models .

Do Spectre and Meltdown patches hurt performance?

These patches generally mitigate the vulnerabilities by altering or disabling how software code makes use of the speculative execution and caching features built into the underlying hardware. The downside of this, of course, is that these features were designed to improve system performance, and so working around them can slow your systems down. While there were initial reports of performance hits up to 30 percent, benchmarks from Phoronix indicate that 5 to 10 percent seems more typical.

Meltdown and Spectre news

Here are the latest headlines from CSO and other publications about this vulnerability. Check back for updates!

• Patching Windows for Spectre and Meltdown: A complete guide (CSO 8/1/18)
• Spectre/Meltdown fixes in HPC: Want the bad news or the bad news? (The Register 7/26/18)
• Google Chrome’s new protection against Meltdown and Spectre bugs will slow your computer down (Mastable 7/13/18)
• New Spectre-like attack uses speculative execution to overflow buffers (Ars Technica 7/10/2018)
• New Spectre derivative bug haunts Intel processors (Network World 3/7/18)

Related content

Israel-hamas conflict extends to cyberspace, microsoft, american express most spoofed brands in financial services phishing emails, only you can prevent forest trust issues: managing the complexity of merged networks, built-in weakness in http/2 protocol exploited for massive ddos attacks, from our editors straight to your inbox.

Josh Fruhlinger is a writer and editor who lives in Los Angeles.

More from this author

Defense in depth explained: layering tools and processes for better security, what is an sbom software bill of materials explained, 11 infamous malware attacks: the first and the worst, 9 types of computer virus and how they do their dirty work, most popular authors.

• Cynthia Brumfield Contributing Writer

Show me more

Vanta bakes generative ai into core security and compliance product.

Gutsy debuts with data-driven security governance tool

Veza releases new IGA solution to enhance identity security

CSO Executive Sessions / ASEAN: Cisco's Anthony Grieco on opportunities in Southeast Asia's cybersecurity landscape

CSO Executive Sessions Australia with Leron Zinatullin, CISO at Linkly

CSO Executive Sessions Australia with Nathan Morelli, Head of Cyber Security and IT Resilience at SA Power Networks

Sponsored Links

• Unified identity security is the new imperative. SailPoint has the roadmap for success - Learn more
• Tomorrow’s cybersecurity success starts with next-level innovation today. Join the discussion now to sharpen your focus on risk and resilience.
• Accelerate your cloud application security strategy with Panoptica

Meltdown and Spectre Questions Answered

Fred o'connor.

From how Spectre and Meltdown differ to how patching will impact machine performance to what's behind the news that applying patches will blue screen computers,  Cybereason CTO Yonatan Striem-Amit  received several questions from people who attended our webinar on what security professionals should know about these hardware flaws. In this blog, he answers many of those questions. And if you want to learn more about these vulnerabilities, including what mitigation measures to implement,  check out a blog  Striem-Amit wrote.

ARE SPECTRE AND MELTDOWN SEPARATE FLAWS?

Spectre and Meltdown are very similar flaws, but they are actually three separate vulnerabilities. Meltdown is specific to Intel processors and is, by far, more easily exploitable. It is also more easily mitigatable and is addressed by recent patches from Microsoft, Apple and Linux. Spectre is an attack against two classes of issues, affecting Intel, AMD and ARM CPUs. These attacks are harder to exploit, but also much harder to mitigate. OS and CPU vendors are still trying to figure out the best mitigations.

Generally, no. Some manifestations of these attacks will use plain-text JavaScript code that might be detectable by network traffic. But these will be the exception.

Are networking devices at risk?

Both classes of attacks require the adversary to run low-privilege code on the attacked machine so the risk to networking devices is low. The exception is devices that allow customer controlled code. We may see bizzare things like attacks against printers by abusing postscript code, but, to the best of my knowledge, this hasn’t happened.

Just for clarification, the new Windows patch will not patch the vulnerability unless a regkey is set?

Correct. The Microsoft patches are inactive unless explicitly activated by an antivirus solution running on the machine. They have a high risk of blue-screening the machine if activated with an unsupported antivirus.

From a monitoring perspective, are there not kernel-based codes that are sent to logs for detection purposes?

Generally there’s very little that is loggable. That’s the risk of this attack. It can be done with almost no interaction between the software running and the kernel. There are some minor side effects that can potentially be used for detection and we’re researching these options.

How would an exploit be delivered and is the risk rating critical?

The most likely scenario is using malicious JavaScript. For example, malvertising could be used. That’s when malicious JavaScript code is used in an advertisement placed on a legitimate website. Other malware could use this technique as well and it is likely to become a tool used by hackers to circumvent kernel protection. The risk when using JavaScript: critical. An example would be a malicious JavaScript code that can read the contents of kernel or other tabs and steal user names and passwords.

Is a firmware update enough or does it have to be combined with OS patching to be effective?

This is unclear since the firmware patch isn’t publically available yet. Early signs indicate that a firmware update has to be combined with OS patching.

Is this a CPU bug? If so, is a firmware update sufficient?

These are CPU bugs that are inherent to the design of processors built over the past 20 years. See my answer to the previous question about only updating firmware.

You mentioned that AMD is also affected. However, some media reports say that AMD is not impacted. Do you think AMD may soon admit that it has an issue, or is there a reason for the vendor to deny any risk?

Meltdown only affects Intel CPUs, is easier to exploit and poses greater risk. It’s also easier to mitigate against it. Spectre affects Intel, AMD and ARM CPUs. AMD is technically correct in saying that it’s not affected by Meltdown, but their decision to downplay the Spectre vulnerability is a marketing trick to bash Intel.

Some network security firms have developed signatures for detecting JavaScript exploitation of these attacks. Do you think these would be effective?

I doubt it. Obfuscating JavaScript is very easy. Network security firms will create a signature for the non-obfuscated version that will be used to demonstrate these attacks, but attackers will have a very easy time evading these detections.

Our environment is 80 percent virtual. What impact would Meltdown and Spectre have on virtual machines?

Patching your host could lead to performance degradation ranging from 5 percent to 30 percent. But performance degradation is very workload specific and really depends on your environment. We’ve seen machine increase their load by 20 percent on virtual environments, while others have shown almost no impact. Initial indicators show that the more I/O intensive your workload is, the more impact patching will have.

You mentioned that newer CPUs should experience minimal performance impact. Where can I find out if the CPUs in my servers are among those that will be impacted?

Intel CPUs from Haswell (fourth generation Core CPUs, v3 Generation XEON CPUs) support an extension called PCID (Process Context Identifier). This list from Intel shows which CPUs are Haswell. Any CPU with a newer number should have minimal impact.

If I patched the VMware hosts, do I also need to patch the guest Windows virtual machines?

Patching the host protects the host from malicious guests. Patching the guests protects the guest’s kernel from malicious low-privilege applications. The decision depends on your usage patterns. In general, patching is recommended.

Can you talk more about the news reports that Microsoft patches cause blue screens? Can we wait until Microsoft issues the next version of these patches?

The blue screens are mostly caused by third-party solutions  - particularly antivirus software that isn’t compatible with these changes - not Microsoft code. Here’s an analogy to better explain the situation: if the electric grid started transmitting power at 220 volts instead of 110 volts tomorrow, my TV will still fry even if the electrical company handled the transition perfectly.

This is the case here. The Microsoft patch does what it needs to, but Microsoft said the patch is delivered as “Inactive” and will only be activated if either turned on manually or automatically by the antivirus vendors. You can apply the patches now because they will not be activated until your antivirus vendor patches their software.

One important note: while Microsoft may place the responsibility on antivirus vendors, their programs are not the only applications running on your machines. Other software, such as DLP or copy-protection programs, could also blue screen when enabling these patches. I strongly recommend that the activation of these patches be done in a cascade while ensuring compatibility with existing software.

If I understand correctly, the Windows patch will be available on Jan. 9 with the next patch release. However, the prevention mechanisms will be inactive and must be turned on once antivirus compatibility is confirmed?

The patch is available now, pushed as an out-of-band update. It will not be activated by Microsoft and requires explicit activation from antivirus vendors.

Are there any problems with the Windows patch on/off state when migrating from one antivirus vendor to another?For example, uninstalling the default antispam software and using one that’s approved by the company?

Assuming that both antivirus programs support the patch correctly, there shouldn’t be a problem. If the removed antivirus software doesn’t support the patch, you should be fine. But if the antivirus program being installed doesn’t support it, you risk getting a blue screen

What is the common vector for those attacks?

These attacks are vector independent. We’ll likely see a lot of use in JavaScript-based malware.

Are there any solutions for an older Os?

There is no solution for older OSs. Microsoft said it will not back-port the patches to unsupported systems

What’s the risk level for medical machines that run proprietary software and never connect to the Internet?

This risk is relatively low. These exploits require the ability to run low-privilege code. Often times it’s difficult to know if a medical device is really at risk. With that said, I recommend talking to someone to make sure there’s really no ability to run this code. In general, given the attacks we saw last year (such as WannaCry), I strongly recommend fully patching medical devices and any other industrial device.

Both chip manufacturers and software vendors are releasing patches for Meltdown. Are both needed for total remediation?

Intel and Microsoft patches are needed to protect machines from Meltdown while vendor patches are needed to ensure that these patches are active.

Are virtual machines running on affected hardware susceptible within the virtual machine itself?

Virtual machines running on susceptible hardware may attack the host and read its content and potentially read content from other hosts. Virtual machines running on susceptible hardware are vulnerable to being attacked from low-privilege code running within the virtual machine.

Learn how Cybereason can help companies handle the fallout from Meltdown and Spectre.

Fred is a Senior Content Writer at Cybereason who writes a variety of content including blogs, case studies, ebooks and white papers to help position Cybereason as the market leader in endpoint security products.

Related Posts

Cybereason and Tech Data Partner to End Cyberattacks in Asia Pacific Region

Cybereason and Tech Data will protect joint customers through expert MDR services that leverage the Cybereason Defense Platform, a multi-layered solution that combines the power of EPP prevention with industry-leading EDR capabilities...

Cybereason and Nuspire Partner to Empower Organizations to Stop Cyber Attacks

Combining the Cybereason operations-centric EDR with Nuspire’s top-notch security operations team enables defenders to combat sophisticated and persistent threats to our mutual customer’s organizations...

Recent Posts

Never miss a blog.

Get the latest research, expert insights, and security industry news.

Answering your questions about “Meltdown” and “Spectre”

Matt linton.

Senior Security Engineer

Matthew O'Connor

Office of the CTO

This week, security vulnerabilities dubbed “Spectre” and “Meltdown” made news headlines. On Wednesday, we explained what these vulnerabilities are and how we're protecting you against them .

Since then, there's been considerable discussion about what this means for Google Cloud and the industry at large. Today, we’d like to clear up some confusion and highlight several key considerations for our customers.

What are “Spectre” and “Meltdown”?

Last year, Google’s Project Zero team discovered serious security flaws caused by “ speculative execution ,” a technique used by most modern processors (CPUs) to optimize performance.

Independent researchers separately discovered and named these vulnerabilities “Spectre” and “Meltdown.” 

Project Zero described three variants of this new class of speculative execution attack. Variant 1 and Variant 2 have been referred to as “Spectre.” Variant 3 has been referred to as “Meltdown.” Most vendors are referring to them by Common Vulnerabilities and Exposures aka “CVE” labels, which are an industry standard way of identifying vulnerabilities.

There's no single fix for all three attack variants; each requires protection individually.

Here's an overview of each variant:

Variant 1 ( CVE-2017-5753 ), “bounds check bypass.” This vulnerability affects specific sequences within compiled applications, which must be addressed on a per-binary basis. This variant is currently the basis for concern around browser attacks, Javascript exploitation and vulnerabilities within individual binaries.

Variant 2 ( CVE-2017-5715 ), “branch target injection.” This variant may either be fixed by a CPU microcode update from the CPU vendor, or by applying a software protection called “ Retpoline ” to binaries where concern about information leakage is present. This variant is currently the basis for concern around Cloud Virtualization and “Hypervisor Bypass” concerns that affect entire systems.

Variant 3 ( CVE-2017-5754 ), “rogue data cache load.”  This variant is the basis behind the discussion around “KPTI,” or “Kernel Page Table Isolation.” When an attacker already has the ability to run code on a system, they can access memory which they do not have permission to access.

For more information on these variants, please read this week’s Google Security post .

Am I protected from Spectre and Meltdown?  

Google’s engineering teams began working to protect our customers from these vulnerabilities upon our learning of them in June 2017. We applied solutions across the entire suite of Google products , and we collaborated with the industry at large to help protect users across the web.

G Suite and Google Cloud Platform (GCP) are updated to protect against all known attack vectors. Some customers may worry that they have not been protected since they were not asked to reboot their instance. Google Cloud is architected in a manner that enables us to update the environment while providing operational continuity for our customers. Via live migration we can patch our infrastructure without requiring customers to reboot their instances.

Customers who use their own operating systems with Google Cloud services should continue to follow security best practices and apply security updates to their images just as they would for any other operating system vulnerability. We're providing an up-to-date reference on the availability of vendor patches for common operating systems on our GCE Security Bulletin page.

I’ve heard that Spectre is nearly impossible to protect against. Is this true?

There has been significant concern in particular about “Spectre.” The use of the name “Spectre” to refer to both Variants 1 and 2 has caused some confusion over whether it's “fixed” or not.

Google Cloud instances are protected against all known inter-VM attacks, regardless of the patch status of the guest environments, and attackers do not have access to any customers’ data as a result of these vulnerabilities. Google Cloud and other public clouds use virtualization technology to isolate neighboring customer workloads. A virtualization component known as a hypervisor connects the physical machine to virtual machines. This hypervisor can be updated to address Variant 2 threats. Google Cloud has updated its hypervisor using “ Retpoline ,” which addresses all currently known Variant 2 attack methods.

Variant 1 is the basis behind claims that Spectre is nearly impossible to protect against. The difficulty is that Variant 1 affects individual software binaries, so it must be handled by discovering and addressing exploits within each binary.

Risks that Variant 1 would pose to the infrastructure underpinning Google Cloud are addressed by the multiple security controls that make up our layered “defense in depth” security posture. Because Google is in full control of our infrastructure from the hardware up to our secure software development practices, our infrastructure is protected against Variant 1. You can read more about the security foundations of our infrastructure in our whitepaper .

We work continuously to stay ahead of the constantly-evolving threat landscape and will continue to roll out additional protections to address potential risks.

As a user of the public cloud, am I more vulnerable to Spectre and Meltdown than others?

In many respects, public cloud users are better-protected from security vulnerabilities than are users of traditional datacenter-hosted applications. Security best practices rely on discovering vulnerabilities early, and patching them promptly and completely. Each of these activities is aided by the scale and automation that top public cloud providers can offer — for example, few companies maintain a several-hundred-person security research team to find vulnerabilities and patch them before they're discovered by others or disclosed. Having the ability to update millions of servers in days, without causing user disruption or requiring maintenance windows, is difficult technology to develop but it allows patches and updates to be deployed quickly after they become available, and without user disruption that can damage productivity.

Spectre and Meltdown are new and troubling vulnerabilities, but it’s important to remember that there are many different types of threats that Google (and other cloud providers) protect against every single day. Google’s cloud infrastructure doesn’t rely on any single technology to make it secure. Our stack builds security through progressive layers that deliver defense in depth. From the physical premises to the purpose-built servers, networking equipment, and custom security chips to the low-level software stack running on every machine, our entire hardware infrastructure is Google-controlled, -secured, -built and -hardened.

Is performance impacted?

On most of Google’s workloads, including our cloud infrastructure, we've seen negligible impact on performance after applying remediations. This was explained further in our follow-up Security blog post on January 4.

There are many conflicting reports about patch impacts being publicly discussed. In some cases, people have published results of tests that focus solely on making API calls to the operating system, which does not represent the real-world scenario that customer software will encounter. There's no substitute for testing to determine for yourself what performance you can expect in your actual situation. We believe solutions exist that introduce minimal performance impact, and expect such techniques will be adopted by software vendors over time. We designed and tested our mitigations for this issue to have minimal performance impact, and the rollout has been uneventful.

Where can I get additional information?

Technical details from Project Zero about these vulnerabilities

Information about these vulnerabilities and mitigations across all Google products

Additional information about impacts to performance

Our Support page offers a list of affected Google products and will be updated with their current status of mitigation against these risks

Our GCP Security Bulletins page will provide notifications as other operating system maintainers publish patches for this vulnerability and as Compute Engine releases updated OS images

• Security & Identity
• Inside Google Cloud

Related articles

Additional signals for enforcing Context Aware Access for Android

By Prashant Jain • 3-minute read

Google mitigated the largest DDoS attack to date, peaking above 398 million rps

By Emil Kiner • 4-minute read

How it works: The novel HTTP/2 ‘Rapid Reset’ DDoS attack

By Juho Snellman • 8-minute read

Deliver and secure your internet-facing application in less than an hour using Dev(Sec)Ops Toolkit

By Lihi Shadmi • 4-minute read

What to know about Spectre and Meltdown with VMware environments

You probably heard about the two massive security flaws: Spectre and Meltdown ( link ). These security flaws allow attackers to access “secure” data by compromising privileged processor memory from major manufacturers, including Intel, AMD, and ARM. So the most CPUs are affected by Spectre and Meltdown security flaws! In this blogpost I highlight what to do in VMware environments.

Last Updated:

• Januari 14, 2018.  All the patches associated with  VMSA-2018-0004 have been pulled back from the online and offline portal. Intel has notified VMware of recent sightings that may affect some of the initial microcode patches that provide the speculative execution control mechanism (Intel Sightings) for a number of Intel Haswell and Broadwell processors.  Link
• Januari 17, 2018.  LoginVSI gives a free license to all companies who are in need of performance testing their VMware Horizon VDI environment regarding meltdown and spectre security patches. This special license will be valid until March 31, 2018, and offers unlimited users, unlimited locations, and includes all standard user workloads. More information can be found here Link .
• Januari 22, 2018.  VMSA-2018-0002.3 updated. Updated security advisory after release of ESXi 5.5 patch ESXi550-201801301-BG that has mitigation against both CVE-2017-5753 and CVE-2017-5715 on 2018-01-22. This patch does NOT include the unstable microcode mentioned in KB52345.
• Februari 3, 2018 . Added the VMware Performance Impact for CVE-2017-5753, CVE-2017-5715, CVE-2017-5754 KB. Link
• Februari 8, 2018.  VMware Virtual Appliance updates address side-channel analysis due to speculative execution (VMSA-2018-0007) is added. Link
• Februari 15, 2018.  VMSA-2018-0007 is updated. Link
• March 20, 2018 . Updated KB VMSA-2018-0004.3. New patches available for vCenter Server, ESXi, Workstation and Fusion.

Currently these security flaws can be divided into the following categories:

Operating System patches will protect against number variant 1 and 3.  With variant 2 a CPU microcode update is required.

What components needs to patched from a hypervisor perspective?

With a type 1 hypervisor such as VMware ESXi or Hyper-V the following components needs to be patched:

• CPU microcode (BIOS/UEFI update)
• Server firmware
• Hypervisors
• Operating systems
• Virtual machines
• Virtual appliances

So what’s the first step to perform?

The first thing to start is to develop a patch strategy. Here’s an example of  tasks to perform to develop the patch strategy:

• RVTools, Link
• Verify Hypervisor-Assisted Guest Mitigation (Spectre) patches using PowerCLI, Link
• Document your vSphere Environment script, Link
• Use the Microsoft PowerShell Module “SpeculationControl” to verify that protections are enabled. See the Microsoft section below for more information.

• PowerCLI can be used for example to identify the VM hardware version with a simple oneliner:
• Identify per vendor what patches are available and how these patches needs to be installed.
• Identify the hardware that can’t be patched anymore. Contact the hardware vendor for a possible solution and decide what to do.
• Make sure your virus/anti malware solution is compatible with the new patches. Contact the antivirus software vendor for compatibility information.
• What’s the impact after applying those patches? Test the patches first in a separate environment. Works everything after deploying? Is there a performance impact when installing these patches?
• Identify what systems needs to be first patched (for example shared and multi tenant environments).
• The security best practices is to install all the patches available per vendor. Communicate with the vendor so you know when patches will be released. The comming days/weeks a lot of vendors will release patches against Spectre and Meltdown.

Vendor patch information

Here’s an overview of some vendors and there current patches available.

The VMware Security Advisories webpage displays the latest remediation for security vulnerabilities . The following advisories are available when writing this blog:

• VMSA-2018-0002.2 (updated 2018-01-13), about Hypervisor-Specific remediation
• VMSA-2018-0004.4 about Hypervisor-Assisted Guest Remediation

To protect against hardware mitigation for branch target injection issue identified in CVE-2017-5715 (See VMware Security Advisory VMSA-2018-0004.3 and Hypervisor-Assisted Guest Mitigation for branch target injection (52085) ) use the following steps:

• For ESXi 6.5: ESXi650-201803401-BG* and ESXi650-201803402-BG**
• For ESXi 6: ESXi600-201803401-BG* and ESXi600-201803402-BG**
• For ESXi 5.5: ESXi550-201803401-BG* and ESXi550-201803402-BG**
• The ESXi patches listed above will also automatically apply these critical CPU microcode updates if the server’s BIOS/Firmware has not already applied. The ESXi patches apply the microcode updates listed in Table 1. found in VMware KB   52085 .

For each Virtual Machine (VM), enable Hypervisor-Assisted Guest mitigation via the following steps:

• Power down the VM
• Create a snapshot of the VM in case of issues
• Power on the VM
• Apply all security patches for your guest OS
• Ensure that all VMs are using Hardware Version 9 (available in ESXi 5.1 and above) or higher. Hardware version 9 is the minimum requirement for Hypervisor-Assisted Guest Mitigation for branch target injection (CVE-2017-5715). For best performance, Virtual Hardware Version 11 or higher is recommended . Virtual Hardware Version 11 (available in ESXi 6.0 and above) enables PCID/INVPCID. These features may reduce the performance impact of CVE-2017-5754 mitigations on CPUs that support those features. ESXi 6.5 uses hardware version 13.
• Test the VM if everything works as excepted. If not roll back to the snapshot
• Remove the snapshot

vMotion and EVC information

vMotion and EVC Information An ESXi host that is running a patched vSphere hypervisor with updated microcode will see new CPU features that were not previously available. These new features will be exposed to all Virtual Hardware Version 9+ VMs that are powered-on by that host. Because these virtual machines now see additional CPU features, vMotion to an ESXi host lacking the microcode or hypervisor patches applied will be prevented. The vCenter patches enable vMotion compatibility to be retained within an EVC cluster. In order to maintain this compatibility the new features are hidden from guests within the cluster until all hosts in the cluster are properly updated. At that time, the cluster will automatically upgrade its capabilities to expose the new features. Unpatched ESXi hosts will no longer be admitted into the EVC cluster.

More information about the vMotion and EVC changes see the KB “Hypervisor-Assisted Guest Mitigation for branch target injection ( 52085 )”.

• Power down and start the VM to see the new EVC capabilities!
• After installing all the patches check the Hyperivosr-Assisted Guest Mitigation with  William Lam’s PowerCLI script ( Link ). It happen  that EVC must be disabled and enabled before the guest VMs get the proper EVC instructions!

More information :

Other vendor patch information

Here is an list of resources of vendors I frequently work with:

It looks like HPE G6 and G7 models will not been updated anymore!

Related posts:

• Watch out with Hardware Version 10 in VMware ESXi 5.5!
• Patch VMware ESXi hosts by command line
• What to know about VMware Cloud on AWS
• VMware patch alert
• Monitor VMware Horizon View environments with ControlUp

6 thoughts on “What to know about Spectre and Meltdown with VMware environments”

https://kb.vmware.com/s/article/52345 is ambiguous on ESXi600-201801401-BG hypervisor: ” it is recommended to create dynamic or static baseline excluding the bulletins ESXi650-201801401-BG, ESXi650-201801402-BG, ESXi600-201801401-BG, ESXi600-201801402-BG ,ESXi550-201801401-BG and continue with the remediation process.”

• Pingback: Meltdown and Spectre Research. – @vmnick0 Blog….

Great article!

One question:

•Operating systems •Virtual machines

What does this mean?

Operating systems > Guest OS? Ok, aknowledged but what “Virtual machines” in this conext mean?

Seems HPE Gen 6 & 7 will have a fix at a later time after all. Info found in v10 of HPE support bulletin: https://support.hpe.com/hpsc/doc/public/display?docId=emr_na-a00039267en_us

So I have an older DEV environment that is running HP DL380p G8’s. HP just released microcode for these servers (BIOS – P70 1/22/2018).

1). I have patched Vcenter to 5.5u3g. 2). I have patched 1 test host to ESXi 5.5u3h. 3). I have applied HP BIOS P70 released on 3/2/2018 with updated microcode. 4). I have applied MS patches and made registry modifications on a Windows 2012 R2 test VM.

When I run the Get-SpeculationControlSettings script it still shows Hardware Support as FALSE.

I have tried numerous reboots and power off/on to the VM and host. I have updated to VM hardware version 10 and updated tools to the latest. However, the script still shows Hardware Support as FALSE.

Any suggestions? …running out of ideas! TIA

Thanks for great article! But it seems like I am having a same problem as Justin described in a post above!

Justin, any solution? Anyone else?

Thanks in advance!

Regards, adi

Leave a Comment

This browser is no longer supported.

Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.

Guidance for mitigating silicon based micro-architectural and speculative execution side-channel vulnerabilities

• 2 contributors

Applies to: ✔️ Linux VMs ✔️ Windows VMs ✔️ Flexible scale sets ✔️ Uniform scale sets

This article provides guidance for a new class of silicon based micro-architectural and speculative execution side-channel vulnerabilities that affect many modern processors and operating systems. This includes Intel, AMD, and ARM. Specific details for these silicon-based vulnerabilities can be found in the following security advisories and CVEs:

• ADV180002 - Guidance to mitigate speculative execution side-channel vulnerabilities
• ADV180012 - Microsoft Guidance for Speculative Store Bypass
• ADV180013 - Microsoft Guidance for Rogue System Register Read
• ADV180016 - Microsoft Guidance for Lazy FP State Restore
• ADV180018 - Microsoft Guidance to mitigate L1TF variant
• ADV190013 - Microsoft Guidance to mitigate Microarchitectural Data Sampling vulnerabilities
• ADV220002 - Microsoft Guidance on Intel Processor MMIO Stale Data Vulnerabilities
• CVE-2022-23816 - AMD CPU Branch Type Confusion
• CVE-2022-21123 - AMD CPU Branch Type Confusion

The disclosure of these CPU vulnerabilities has resulted in questions from customers seeking more clarity.

Microsoft has deployed mitigations across all our cloud services. The infrastructure that runs Azure and isolates customer workloads from each other is protected. This means that a potential attacker using the same infrastructure can't attack your application using these vulnerabilities.

Azure is using memory preserving maintenance whenever possible, to minimize customer impact and eliminate the need for reboots. Azure will continue utilizing these methods when making systemwide updates to the host and protect our customers.

More information about how security is integrated into every aspect of Azure is available on the Azure Security Documentation site.

Since this document was first published, multiple variants of this vulnerability class have been disclosed. Microsoft continues to be heavily invested in protecting our customers and providing guidance. This page will be updated as we continue to release further fixes.

Customers that are running untrusted code within their VM need to take action to protect against these vulnerabilities by reading below for more guidance on all vulnerabilities.

Other customers should evaluate these vulnerabilities from a Defense in Depth perspective and consider the security and performance implications of their chosen configuration.

Keeping your operating systems up-to-date

While an OS update is not required to isolate your applications running on Azure from other Azure customers, it is always a best practice to keep your software up-to-date. The latest Security Updates for Windows contain mitigations for these vulnerabilities. Similarly, Linux distributions have released multiple updates to address these vulnerabilities. Here are our recommended actions to update your operating system:

Additional guidance if you're running untrusted code

Customers who allow untrusted users to execute arbitrary code may wish to implement some extra security features inside their Azure Virtual Machines or Cloud Services. These features protect against the intra-process disclosure vectors that several speculative execution vulnerabilities describe.

Example scenarios where more security features are recommended:

• For example, you allow one of your customers to upload a binary or script that you then execute within your application .
• For example, you allow a low-privileged user to log into one of your VMs using remote desktop or SSH .
• For example, you control the Hyper-V host, but allocate the VMs to untrusted users .

Customers who do not implement a scenario involving untrusted code do not need to enable these extra security features.

Enabling additional security

You can enable more security features inside your VM or Cloud Service if you're running untrusted code. In parallel, ensure your operating system is up-to-date to enable security features inside your VM or Cloud Service

Your target operating system must be up-to-date to enable these extra security features. While numerous mitigations are enabled by default, the extra features described here must be enabled manually and may cause a performance impact.

Step 1: Follow the instructions in KB4072698 to verify protections are enabled using the SpeculationControl PowerShell module.

If you previously downloaded this module, you will need to install the newest version.

To validate enabled protections against these vulnerabilities, see Understanding Get-SpeculationControlSettings PowerShell script output .

If protections are not enabled, please contact Azure Support to enable additional controls on your Azure VM.

Step 2: To enable Kernel Virtual Address Shadowing (KVAS) and Branch Target Injection (BTI) OS support, follow the instructions in KB4072698 to enable protections using the Session Manager registry keys. A reboot is required.

Step 3: For deployments that are using nested virtualization (D3 and E3 only): These instructions apply inside the VM you're using as a Hyper-V host.

• Follow the instructions in KB4072698 to enable protections using the MinVmVersionForCpuBasedMitigations registry keys.
• Set the hypervisor scheduler type to Core by following the instructions here .

Disable hyper-threading on the VM - Customers running untrusted code on a hyper-threaded VM might choose to disable hyper-threading or move to a non-hyper-threaded VM size. Reference this doc for a list of hyper-threaded VM sizes (where ratio of vCPU to Core is 2:1). To check if your VM has hyper-threading enabled, refer to the below script using the Windows command line from within the VM.

Type wmic to enter the interactive interface. Then type the following command to view the amount of physical and logical processors on the VM.

If the number of logical processors is greater than physical processors (cores), then hyper-threading is enabled. If you're running a hyper-threaded VM, contact Azure Support to get hyper-threading disabled. Once hyper-threading is disabled, support will require a full VM reboot. Refer to Core count to understand why your VM core count decreased.

For CVE-2022-23816 and CVE-2022-21123 (AMD CPU Branch Type Confusion), follow both Option 1 and Option 2 above.

Enabling the set of extra security features inside requires that the target operating system be fully up-to-date. Some mitigations will be enabled by default. The following section describes the features which are off by default and/or reliant on hardware support (microcode). Enabling these features may cause a performance impact. Reference your operating system provider's documentation for further instructions

Step 1: Disable hyper-threading on the VM - Customers running untrusted code on a hyper-threaded VM will need to disable hyper-threading or move to a non-hyper-threaded VM. Reference this doc for a list of hyper-threaded VM sizes (where ratio of vCPU to Core is 2:1). To check if you're running a hyper-threaded VM, run the lscpu command in the Linux VM.

If Thread(s) per core = 2 , then hyper-threading has been enabled.

If Thread(s) per core = 1 , then hyper-threading has been disabled.

Sample output for a VM with hyper-threading enabled:

If you're running a hyper-threaded VM, contact Azure Support to get hyper-threading disabled. Once hyper-threading is disabled, support will require a full VM reboot . Refer to Core count to understand why your VM core count decreased.

Step 2: To mitigate against any of the below CPU based memory vulnerabilities, refer to your operating system provider's documentation:

• Redhat and CentOS

When a hyper-threaded VM is created, Azure allocates 2 threads per core - these are called vCPUs. When hyper-threading is disabled, Azure removes a thread and surfaces up single threaded cores (physical cores). The ratio of vCPU to CPU is 2:1, so once hyper-threading is disabled, the CPU count in the VM will appear to have decreased by half. For example, a D8_v3 VM is a hyper-threaded VM running on 8 vCPUs (2 threads per core x 4 cores). When hyper-threading is disabled, CPUs will drop to 4 physical cores with 1 thread per core.

For more information about how security is integrated into every aspect of Azure, see Azure Security Documentation .

Submit and view feedback for

Additional resources

How to Mitigate Spectre & Meltdown Security Vulnerabilities in VMware Identity Manager

Spectre and Meltdown (CVE-2017-5715, CVE-2017-5753 and CVE-2017-5754) are two recently discovered security vulnerabilities that can allow a rogue process to access other processes and memory running on the same device. A remote attacker could exploit some of these vulnerabilities to take control of an affected system.

This post covers how you can protect your VMware Identity Manager deployment against these security vulnerabilities. As with all vulnerabilities, one of the most important things you can do to secure your deployments is ensuring Identity Manager is up to date.

How can you protect your deployments?

If you are an Identity Manager customer, you either have SaaS or On-Premises deployment type. In the SaaS deployment type, your Identity Manager service is hosted by VMware and has already been updated. In the On-Premises deployment type, your service is hosted on premises by your IT team and must be updated to mitigate Spectre and Meltdown vulnerabilities. In either deployment type, your Identity Manager connector is installed on premises and needs to be updated.

The table below indicates the steps we encourage you to perform on various components that you have deployed.

Identity Manager Connector: Linux-based virtual appliance

If your VMware Identity Manager connector is deployed as a virtual appliance, ensure that you immediately upgrade to the most recent release of VMware Identity Manager Connector (version 2018.1.1.0) . See here for official documentation on how to upgrade your VMware Identity Manager Connector virtual appliance.

Upgrade Path:

Note: To know the current version of your connector appliance, either navigate to Connectors page of VMware Identity Manager admin console or log into your virtual appliance as the root user and run the following command

/usr/local/horizon/scripts # vamicli version –appliance

Identity Manager Connector: Windows

If your Connector is installed on a Windows Server, ensure you take necessary steps to protect your Windows machines. See the Microsoft article here .

Identity Manager Service: Linux-based virtual appliance

In an on-premise VMware Identity Manager deployment, you would also have VMware Identity Manager Service deployed as a virtual appliance in your internal network. Ensure that you upgrade your Service virtual appliance to the most recent release (version 3.2) . See here for documentation on how to upgrade your VMware Identity Manager Service virtual appliance.

Note: To know the current version of your service appliance, log into your virtual appliance as the root user and run the following command

Identity Manager Service: Windows

If your VMware Identity Manager Service is installed on a Windows Server, ensure you take necessary steps to protect your Windows machines. See Microsoft article here .

Related Articles

Why it pays to deliver your employee experience lifecycle with Workspace ONE

Why every organization needs to have multi-factor authentication

VMSA-2022-0011: What you need to know

New passwordless authentication options for Workspace ONE Access FedRAMP customers

For Identity Management Day, learn from our top identity management and Workspace ONE Access resources

Mitigate Spectre and Meltdown impact with vSphere ESXi

As most of the folks in the IT, I’ve spent last couple of days researching about famous Spectre and Meltdown attacks and their possible impact to our infrastructure.

These security flaws are especially bad, not only because they’ve been here for more than 2 decades, but mitigation comes with significant performance impacts.

Where to start?

As these attacks have to be executed locally, I would recommend anyone to focus on systems which have internet access and systems which are shared among multiple users, especially:

• Multi tenant environments – if you are a hosting company
• Terminal servers
• Workstations/Desktops (Both physical and virtual)
• Mobile devices – Phone/tablets

Although most of the CPU vendors and their CPUs are affected to some extend, I will be focusing on Intel CPUs here, as those are most vulnerable.

OS patching is not enough!

Almost every OS vendor came out with their patches, however what may not be clear for an average user is, If you want to be fully protected against known exploits you have to also update your CPU microcode which is usually coming together with uEFI/BIOS updates from your hardware vendors.

If you have slow HW vendor or they do not support your motherboard anymore, it doesn’t mean you are entirely doomed yet. There is a way how to sideload CPU microcode during the OS boot. For Linux you can find instructions and microcode at Intel’s website directly. In case of Microsoft, occasionally in case of critical issues they do provide CPU microcode updates via Windows Update, although I don’t know for sure when or if they will decide to release it this time, anyway in such issue I would bet yes.

There are 3 types of attack:

• CVE-2017-5753 (variant #1/Spectre) Bounds-checking exploit during branching
• CVE-2017-5715 (variant #2/Spectre) Indirect branching poisoning attack
• CVE-2017-5754 (variant #3/Meltdown) Speculative cache loading

OS(kernel) patches alone will protect you against Variant #1 and Variant #3 , however protection against Variant #2 requires CPU microcode update as well.

Protection in Virtualized environments

When it comes to virtualization, it is a bit trickier as there is an additional layer included.

By updating CPU microcode to fix Spectre you are presenting additional CPU features to your operating system, however this is not the case if you are running in virtual machine as those features may be masked by hypervisor, especially in this case as it is very fresh. You also need to patch your hypervisor, so it will present those features to the OS in virtual machines as well.

VMware released new security advisory VMSA-2018-0004 together with patches and  kb52085 yesterday regarding enabling this capability.

What I like especially, that they included also CPU microcode with the new patches, therefore you don’t have to wait for HW vendor to release uEFI updates. Although updating uEFI is still strongly recommended!

How to protect against Spectre #2  with minimizing performance hit

• ESXi650-201801401-BG hypervisor
• ESXi600-201801401-BG hypervisor
• ESXi550-201801401-BG hypervisor and microcode
• ESXi650-201801402-BG microcode
• ESXi600-201801402-BG microcode
• Update VM Hardware version to at least version 9 (to be protected), ideally version 11 to minimize performance impact in case your CPU supports PCID and INVPCID ( Process-Context Identifiers ).
• Remember you still have to patch your guest operating system

vCenter patches will, make sure EVC version in cluster will be updated to the latest version only after you update all hosts within the cluster

Note: ESXi will never override a newer version of the microcode patch provided by BIOS nor will the BIOS with an older version prevent ESXi from applying the newer version.

I recommend you following articles to read more about handling the issue in Red Hat and Microsoft’s Operating systems:

Controlling the Performance Impact of Microcode and Security Patches for CVE-2017-5754 CVE-2017-5715 and CVE-2017-5753 using Red Hat Enterprise Linux Tunables

Speculative Execution Exploit Performance Impacts 

Windows Client Guidance for IT Pros to protect against speculative execution side-channel vulnerabilities

Windows Server guidance to protect against speculative execution side-channel vulnerabilities

Understanding the performance impact of Spectre and Meltdown mitigations on Windows Systems

• Latest Posts

Dusan Tekeljak

Latest posts by dusan tekeljak ( see all ).

• ESXi 6.7 U1 fixes: APD and VMCP is not triggered even when no paths can service I/Os - November 30, 2018
• Update manager error: hosts could not enter maintenance mode - November 19, 2018
• VMware fixes 2 data corruption bugs and VM to Host escape vulnerability! - November 19, 2018

Share this:

About Dusan Tekeljak

Leave a reply cancel reply.

This site uses Akismet to reduce spam. Learn how your comment data is processed .

• Search for: Search

• vSphere & NSX: Active Directory over LDAPs authentication February 3, 2022
• Make Youtube Videos About Technology? Why not… The Cross-Cloud Guy October 7, 2021
• Automating (NSX-T) REST API using Ansible URI module December 29, 2020
• Quick Reference: Create Security Policy with Firewall Rules using NSX-T Policy API May 4, 2020
• Ansible in Windows 10 box March 30, 2020

Top Posts & Pages

• Remove and Re-Create Management Network (vmk0) VMkernel interface using ESXi Command line
• VCSA filesystem is out of disk space
• Execute ESXCLI commands during ESXi startup
• Enabling LLDP for Intel X7xx series adapters in ESXi
• Persistent Static Routes on VCSA 6.5
• Manually remove ESXi host from vCenter database
• About Us - TheVirtualist
• Update manager error: hosts could not enter maintenance mode
• Centralized syslog server for vSphere environment with CentOS 7 and rsyslog
• VMware installation validation checklist
• Back to Basics
• Cloud and Virtualization
• Cloud Native
• Horizon View
• Microsoft Hyper-V
• TheVirtualist

SUSE Support

Here when you need us, security vulnerability: "meltdown" and "spectre" - hypervisor information..

This document (7022514) is provided subject to the disclaimer at the end of this document.

Environment

• Fully Virtual mode (also known as a Hardware Virtual Machine), including the performance optimized Xen PVHVM mode. We subsume both as "HVM" in this document.
• Para-Virtual (PV) mode

# grep -H . /sys/devices/system/cpu/vulnerabilities/* /sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI /sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: Barriers /sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic retpoline, IBPB

# grep -H . /sys/devices/system/cpu/vulnerabilities/* /sys/devices/system/cpu/vulnerabilities/meltdown:Vulnerable /sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: __user pointer sanitization /sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic retpoline

nospectre_v2     Disables all Spectre v2 mitigation nospec                  Disables microcode-based Spectre v2 mitigation (x86_64 only) spectre_v2=<value>

on                            - unconditionally enable the mitigation off                          - unconditionally disable the mitigation (same as "nospectre_v2") auto                        - default setting where the kernel detects whether the CPU model is vulnerable retpoline                - replace indirect branches retpoline,generic   - google's original retpoline retpoline,amd         - AMD-specific minimal thunk

nopti         Disables Meltdown mitigation (KPTI) pti=<value> on       - force-enables PTI even on AMD off      - force-disable PTI even on Intel auto     - PTI on for Intel, off for AMD (default)

cpuid=<List of comma separated CPU feature booleans (i.e. yes/true, no/false)> ibrsb=(yes/no)         - disable IBRS ibpb=(yes/no)          - disable IBPB stibp=(yes/no)         - disable STIBP

Default settings enable ibrs, ibpb and stibp. Underlying hardware must support capabilities enabled through cpuid Features can be ignored (e.g. ‘no-ibrsb’) which disables the feature at the hypervisor level, and prevents the feature from being passed to guests. Hardware features are automatically passed through to guests, but may be disabled to improve migration compatibility.

bti=<List of comma separated BTI mitigation tunings> thunk=retpoline|lfence|jmp     - Determines mitigation method:                             retpoline – default, preferred for Intel                             lfence – preferred for AMD                             jmp – minimal overhead thunk ibrs=(yes/no)                 - controls hypervisor support for IBRS ibpb=(yes/no)                 - controls hypervisor support for IBPB on vCPU context switches rsb_{vmexit,native}=(yes/no)     - controls when Return Stack Buffers are overwritten by the hypervisor

By default, the most appropriate mitigation is selected based on compiled in support, loaded microcode, and hardware details. Manually adjusting the bti parameter is only recommended for use when disabling mitigation. Disabling hypervisor support for IBRS (bti=ibrs=no) does not prevent Xen from providing IBRS to guests. Additional information can be found in /usr/share/doc/packages/xen/misc/xen-command-line.markdown

xpti=<value> on         - enable XPTI mitigation (default on all platforms except AMD) off         - disable XPTI mitigation

• To disable everything on the Xen hypervisor, while allowing guests access to CPU features related to speculative execution control:

bti=thunk=jmp,ibrs=no,ibpb=no,rsb_native=no,rsb_vmexit=no xpti=no

• To disable everything on the Xen hypervisor, and prevent any mitigation related CPU features from being passed to guests :

cpuid=no-ibrsb,no-ibpb,no-stibp bti=thunk=jmp,rsb_native=no,rsb_vmexit=no xpti=no

• qemu-2.9.1-6.12.1 released Wednesday, 21st of March 2018
• libvirt-3.3.0-5.19.2 released Wednesday, 11th of April 2018
• xen-4.9.1_08-3.26.1 released Wednesday, 14th of February 2018
• qemu-2.6.2-41.37.1 released Tuesday, 27th of March 2018
• libvirt-2.0.0-27.37.1 released Friday, 13th of April 2018
• xen-4.7.5_02-43.27.1 released Tuesday, 10th of April 2018
• qemu-2.3.1-33.6.1 released Tuesday, 9th of January 2018
• xen-4.5.5_24-22.43.1 released Monday, 5th of March 2018
• kernel-xen-3.12.74-60.64.85.1 released Thursday, 29th of March 2018
• qemu-2.0.2-48.37.1 released Thursday, 4th of January 2018
• xen-4.4.4_28-22.62.1 released Monday, 5th of March 2018
• kernel-xen-3.12.61-52.125.1 released Wednesday, 28th of March 2018
• kvm-1.4.2-60.6.1 released Thursday, 4th of January 2018
• libvirt-1.2.5-23.9.1 released Friday, 13th of April 2018
• xen-4.4.4_28-61.23.2 released Thursday, 8th of March 2018
• kernel-xen-3.0.101-108.35.1 released Tuesday, 27th of February 2018
• kvm-1.4.2-53.14.1 released Monday, 8th of January 2018
• xen-4.2.5_21-45.19.1 released Wednesday, 14th of March 2018
• kernel-xen-3.0.101-0.47.106.19.1 released Monday, 12th of March 2018

Additional Information

This Support Knowledgebase provides a valuable tool for SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented "AS IS" WITHOUT WARRANTY OF ANY KIND.

• Document ID: 7022514
• Creation Date: 04-Jan-2018
• Modified Date: 03-Mar-2020
• SUSE Linux Enterprise Server

< Back to Support Search

For questions or concerns with the SUSE Knowledgebase please contact: tidfeedback[at]suse.com

SUSE Support Forums

Get your questions answered by experienced Sys Ops or interact with other SUSE community experts.

Support Resources

Learn how to get the most from the technical support you receive with your SUSE Subscription, Premium Support, Academic Program, or Partner Program.

Open an Incident

Open an incident with SUSE Technical Support, manage your subscriptions, download patches, or manage user access.

Spectre, Meltdown and VMware vSphere

Many people are under the incorrect belief that it is hardware-level firmware updates from companies like HPE and Dell that will protect our Virtual Machines from Speculative Execution Vulnerabilities. This is NOT TRUE.

• As far as your VMs are concerned, the VM BIOS and Hypervisor are the hardware!

When VMware gets around to re-releasing vSphere updates that address Speculative Execution Vulnerabilities (CVE-2017-5753 aka ‘Spectre Variant 1’, CVE-2017-5715 aka ‘Spectre Variant 2’, CVE-2017-5754 aka ‘Meltdown Variant 3’), I have every expectation that all of your VMs will be protected from Speculative Execution Vulnerabilities that occur within the Guest OS

Server hardware firmware and BIOS updates that have been released and will be released in coming days will address Speculative Execution Vulnerabilities of the Hypervisor itself, and other VMkernel processes, which generally ONLY occur within our Management Networks .

This is one more great reason to isolate your VMware vSphere Management networks and harden them from general access, limiting use to named users and network locations! If a potential malicious actor cannot access a vulnerable element (as, perhaps, the vSphere Embedded Host Client interface) they cannot exploit Speculative Execution Vulnerabilities.

This is not to say that server hardware and firmware should not be updated as soon as updates are available, but merely to encapsulate risk where it belongs:

Specific actions you should take:

• Using the Web Client, go to: VM > Edit Settings > Upgrade > Schedule VM Compatibility Upgrade – this may require a reboot of your VMs!
• Using Update Manager , remediate to the pre-defined baseline for: VM Hardware Upgrade to Match Host (Predefined) – this may require a reboot of your VMs!
• We will keep you posted as patches become available and meet our abridged testing/waiting period of one week from release (for Speculative Execution Vulnerabilities only)
• Monitor your server vendor website for firmware updates

Speculative Execution Vulnerabilities Test Result Summary

Inspectre.exe result from a full-updated windows server 2012.

• VM Hardware Version 11
• ESXi Host with no Hypervisor updates specific to Speculative Execution Vulnerabilities
• No Firmware updates specific to Speculative Execution Vulnerabilities
• I DO NOT recommend applying the withdrawn updates, even if you have them downloaded. See: https://kb.vmware.com/s/article/52345
• If you applied the withdrawn updates see: https://kb.vmware.com/s/article/52345

InSpectre.exe Result from a full-updated CentOS7 x64

About: John Borhek

John Borhek is the CEO and Lead Solutions Architect at VMsources Group Inc. John has soup-to-nuts experience in Mission Critical Infrastructure, specializing in hyper-convergence and Cloud Computing , engaging with organizations all over the United States and throughout the Americas.

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Meltdown and Spectre Vulnerabilities Explained

In This Article

What are Meltdown and Spectre Vulnerabilities?

Meltdown and Spectre both refer to the two original transitory executions or classes of hardware vulnerabilities in the modern processors. These vulnerabilities involve micro-architectural timing and side-channel attacks.

Meltdown is a typical type of vulnerability experienced by the modern Intel processors which typically creates an informational barrier. This shields the privileged data from being dissolved effectively by the attack.

On the other hand, Spectre vulnerability encountered by all of the superscalar processors is so called because it involves speculative processing.

KEY TAKEAWAYS

• Meltdown and Spectre vulnerabilities affect most of the modern processors, whether they are made by Intel or AMD, and whether they are used in a desktop or a laptop computer, or in any other mobile device.
• While Meltdown has affected the Intel processors in particular for the past two decades, Spectre typically affects a fundamental part of most of the modern superscalar processors.
• These vulnerabilities typically exist in the physical circuits of the processors and therefore are very hard to do away with, and therefore are expected to stay and haunt the world of computers for several years to come.
• These attacks are very hard to avoid because most modern processors are superscalar and are affected by them, including those manufactured by Intel, AMD or ARM.
• The best way to guard your device from Meltdown attacks is to install all of the updates that are available currently for the operating system that you are using on your device.

Understanding Meltdown and Spectre Vulnerabilities

Spectre and Meltdown are hardware vulnerabilities and individually come with a number of variants based on the functionality of the specific silicon level.

There are about 13 Specter and 14 Meltdown variants identified.

Some processors may be more vulnerable to quite a few variants than others and it all depends on the differences between the manufactures and the architecture of the microprocessors .

Typically, Meltdown and Spectre vulnerabilities result from the flaws in the hardware design.

However, attempts to mitigate them on a software level have shown some success.

The existence of Meltdown and Spectre vulnerabilities in the modern processors were discovered separately by researchers at Graz University of Technology in Austria, and Google’s Project Zero in California in 2017, and were published on January 3, 2018.

It has been increasingly important to understand Spectre and Meltdown vulnerabilities since their initial disclosure.

Several security researchers are still studying these vulnerabilities to come up with better remedies.

Initially, it was thought that the AMD processors were more resilient to Meltdown, but, sadly, that was not the case.

The Meltdown and Spectre attacks are somewhat similar.

The exploits of Meltdown include:

• A race condition between the privilege level checking and memory access while processing an instruction
• A side channel attack in combination with a CPU cache
• Bypassing privilege level checks
• Allowing the operating system to access the memory used or other ongoing processes.

In some cases, this attack can also be used to read the memory in the related, virtualized software containers.

On the other hand, Spectre involves the victim to perform speculative operations while processing the instructions of a program that would ideally not occur during standard, serialized, and in-order processing.

This, in the process, leaks the confidential information of the victim through a secret channel to the adversary.

Processors that have this ability and design are known as superscalar processors , and, in fact, most of the modern processors are superscalar in design and nature.

These CPUs are typically used in the modern desktop and laptop computers and even in the mobile devices.

This means that the systems that use a scalar or ARM processor , such as the Raspberry Pi, will not be affected by Spectre attacks.

This is because they do not use speculative processing.

Typically, Spectre takes the advantage of the consumer processors being superscalar, which helps them in manipulating their guesses or speculative branch predictions in the following ways:

• Instructions are issued by the attacker that are created with an intention to cause wrong guesses by the processor . This allows making an analysis by using a side channel.
• It then uses this information to manipulate the specific code that the processor would carry out next. This even includes the private instructions of some other program that may be running.

This type of attack is known as branch target injection and cannot be implemented very easily.

This is because it needs to target the software of the system of the victim specifically.

Both of these vulnerabilities are very hard to fix because they exist in the physical circuitry of the processor.

However, you may be able to mitigate Meltdown attacks to some extent by making some tweaks to the operating system, but this will slow down its performance by a significant margin.

Meltdown and Spectre may also affect the web browsers. However, a few specific kinds of browsers have made efforts to reduce the chances of these attacks, especially with Meltdown attacks. For example:

• The Firefox Quantum version 57 or higher is protected from such attacks while running any code in the browser, such as JavaScript.
• Google has also declared that Chrome version 64 will mitigate these attacks in the browser.
• Microsoft Edge, on the other hand, is supposed to be patched by Windows Updates automatically to mitigate Meltdown attacks.
• Opera has also made a claim that their security update will mitigate the Meltdown vulnerability.

Typically, the smaller mobile devices using Android and iOS, such as smartphones and tablets, are vulnerable to both Meltdown and Spectre attacks, hypothetically.

Though there are quite a few new versions of Android and iOS devices that come with updates that may mitigate Meltdown attacks, as for the Spectre attacks, if possible, are very much unfeasible.

What Does Spectre Attack?

Spectre typically affects the modern microprocessors that come with a superscalar design that are able to perform different types of speculations including branch prediction .

Therefore, Spectre vulnerability typically attacks the processors used mostly in smartphones and tablets.

It also affects the computer chips made by Intel and Advanced Micro Devices Inc or AMD by causing leakage of information from the applications.

Ideally, it is done in four specify ways as follows:

• Spectre-PHT – This results in bounds check bypass by exploiting the Pattern History Table.
• Spectre-BTB – This results in branch target injection by exploiting the Branch Target Buffer.
• Spectre-RSB – This results in Return Stack Buffer miscredits by exploiting it.
• Spectre-STL – This results in speculative store bypass by exploiting the memory disambiguation prediction of the processors especially during store-to-load forwarding.

What is Meltdown in Cyber Security?

Meltdown in cyber security can cause serious threats imposed by malicious actors. This is because it is really hard to predict who they will go after since there are an abundance of unsuspecting and unprivileged victims in the cloud.

This means that the cloud services and businesses running their infrastructure on Google and Amazon Web Services or AWS Cloud must be extra cautious.

How easily can a hacker steal personal data and information of the clients and customers will depend on the infrastructure of the cloud service provider.

Realizing and knowing the threats imposed by Meltdown and Spectre vulnerabilities, the cloud service providers are racing against time to find a solution to these threats, while keeping things under wraps.

However, billions of computers, tablets, and mobile phones all over the world are affected by these vulnerabilities, and the statements released by Apple, Google and Microsoft confirm it.

However, in spite of the fact that these threats are still there, things can be slowed down a bit, if not prevented, with operating system patches and the latest security updates.

Implementing a reliable and powerful third-party antivirus software is also good to have installed and updated.

There are some fixes available, and more are being developed, to handle this vulnerability in Microsoft Windows, Linux , and macOS X operating systems.

It is expected that these fixes will alleviate the chances of such attacks at the kernel level. And, the performance cost of it is expected to hover around 5 to 10%.

Different updates are available for different kinds of operating systems in different stores. For example:

• If you are using Windows 10, Windows 8, or Windows 7 operating system on your computer, you should always check and upgrade it with a new Windows Update.
• If you are using the macOS X operating system, then you should update the security with what is available in the App Store and upgrade it.
• If you are using an Android tablet or smartphone, you should install the newer security update from the store on your device.
• If you are using iOS on your tablet or smartphone, you must install iOS 11.2 or greater on your device.

On the other hand, as for the Spectre attacks, there is no way at all to mitigate them by using any type of software program.

How Do the Meltdown and Spectre Attacks Work?

While Meltdown creates an information barrier and reads the memory, which it is not supposed to, Spectre makes branch predictions.

Spectre and Meltdown both represent a specific class and are closely related variants. They are not singular flaws. However, Meltdown, Spectre, and all their variants work in almost the same pattern to attack the proceedings.

• First, a speculation is triggered to execute the code as desired by the attacker.
• Next, this code is used to read the memory or the secret data without having any permission for it.
• Then, the secret is communicated by the attacks by using a side channel such as Flush, Reload or anything similar.

However, Meltdown breaks the most basic isolation between the operating system and the user applications.

This type of attack permits the program to access and read the memory and the secrets of other operating systems or programs.

Meltdown is a specific type of vulnerability that is encountered by the Intel processors and can be characterized by its behavior which may be summarized as follows.

• When the CPU is asked to prefetch data, it reads it before checking the privileges of the user.
• The processor functions in a different way depending on the type of data fetched, though it is not conveyed to the unprivileged user.
• The performance of the processor can be monitored by the attacker using a side channel in order to differentiate the vital details of the data.

This information thus gathered creates a possibility of subsequent attacks. In some cases, it is, however, guaranteed.

Meltdown attacks, typically, are conducted in three basic steps such as:

• The content of the memory location chosen and which is inaccessible by an attacker is loaded in the register.
• A transitory instruction allows accessing a cache line depending on the secret information in the register.
• The attacker uses a side channel to figure out the cache line accessed, and therefore, the stored secret at that particular memory location that is chosen.

Spectre, on the other hand, is pretty similar but it does not affect the exclusive behavior of the chip.

Instead, it targets the weaknesses of the fundamental design model of the processor that are known previously.

It can be characterized by its specific behavior as well and are summarized as follows:

• The out-of-order execution or paradigm guesses the kind of operation that would happen by using speculative execution .
• Based on this speculation, some portion of the task is done ahead of time.

This is good in a way because it expedites the processing significantly, but it is essential for the guess to be correct in the first place.

The working process of Spectre, therefore, involves the following three steps:

• The processor is mistrained at the setup phase to make a wrong speculative prediction that can be exploited.
• The processor is also made to execute instructions speculatively from the target context into a secret channel in the microarchitecture.
• The recovery of the sensitive data is done by timing access to the memory locations in the processor cache.

What is Spectre and Meltdown Checker?

The Spectre and Meltdown Checker is actually a script. It is used to check whether or not a device is potentially exposed to rogue system register reads, bounds check bypass and other types of transient execution attacks.

Created and maintained by an open source community, this script or checker supports different open source operating systems to look for threats across different platforms created by different hardware vendors. It includes:

• Cloud service providers
• Individual developers
• Software vendors and others.

This checker supports running in virtualized environments, on-premises, and also in containers.

The Spectre and Meltdown Checker ensures that the proper mitigations are in place within the system and are enabled.

However, it does not alleviate any of these threats by itself. It simply helps you to find out the risk exposure of your device.

It also does not make any modifications to the kernel or system since Meltdown and Spectre target only the features of the microarchitecture and the mitigations for the vulnerabilities are typically found in the software and/or in the microcode .

This useful tool will simply inspect the system hardware, the kernel image, and the microcode installed in the system to detect the existence of these threats and provide you with the necessary information.

This will help you to figure out whether or not your system needs any further mitigation.

The first step to using this checker is to install it on your device.

Usually, a few Linux distros will come with this tool already included in their repositories.

You will just need to check the method of using it, such as Advanced Packaging Tool (APT) or Yellowdog Updater, Modified (YUM).

For others, you can check for necessary information at other websites such as GitHub or meltdown.ovh.

You will need to use this checker with administrator privileges to check different things such as:

• The family and model number of the processor in your system
• The stepping and Model Specific Registers or MSRs for each vulnerability listed that may affect your device.

If your system does not have any updated microcode, it will be listed as vulnerable to the Meltdown and Spectre threats.

At this stage, the checker does not check the mitigations, even if your system is already mitigated.

The checker checks the mitigations after this stage and ensures that they are appropriate because different vulnerabilities will have diverse mitigations.

If anything is found to be missing, it will inform you which particular component needs to be updated.

The first thing you should do after getting such a report is look for the right kind of update that will mitigate the issue. You can check it out with:

• The application
• The operating system
• The hypervisor vendors.

Also, depending on the workload and the environment, you may be allowed to configure the mitigation for that particular condition and workload in a few transient execution attacks mitigation options.

Are Meltdown and Spectre Viruses?

No, neither Meltdown nor Spectre are true viruses. Instead, they are vulnerabilities that affect the CPU of a computer and exploit the flaws in the hardware to carry out an attack.

In fact, since these are not viruses or malware and simply the flaws in the hardware security, it is not possible to prevent them by using antivirus software.

The best way to protect a device is to keep the programs, apps and browsers updated.

Meltdown Vs Spectre

• Meltdown is a vulnerability that allows a process to read the memory of a given system, but in comparison, Spectre is the vulnerability that allows reading the assigned memory for random locations for a program.
• Meltdown typically breaks the most basic separation between the operating system and user applications, but Spectre breaks the isolation between several applications.
• Meltdown can be remedied through software patches in the operating systems, but, in comparison, Spectre is hard to exploit and harder to mitigate, if not impossible.
• Meltdown makes use of the privilege escalation flaw to read the memory of the system, but Spectre tricks the applications to perform instructions that they should not, allowing access to the information stored in the memory of the system by the hackers.
• Meltdown vulnerability usually affects the Intel CPUs with the x86 microarchitecture, the IBM POWER and quite a few ARM microprocessors, but Spectre attacks Intel and AMD processors used in computers, smartphones and tablets.
• Meltdown creates an information barrier with a rogue procedure to read all memory, but Spectre affects the system by causing leakage of information from the applications.
• Meltdown uses Intel privilege escalations and speculative execution methods, but in comparison, Spectre uses branch prediction and speculative execution methods.
• Meltdown attempts to access and allow a program to read the kernel memory that has been protected from access from user space, but in comparison, Spectre affects the performance of the system and reads the contents of memory of other running programs.

Do Spectre and Meltdown Affect Virtual Machines?

Yes, they may affect a virtual machine, depending on their variant.

For example, a VM running within the Sentinel 400 may be susceptible to the Meltdown CVE-2017-5754 variant and two other variants of Spectre, namely CVE-2017-5753 and CVE-2017-5715.

Meltdown and Spectre vulnerabilities both affect the modern CPUs in almost the same way.

Though the former can be mitigated by using software patches in the operating system, Spectre is hard to mitigate.

It is, thus, best for you to keep your system, programs and applications updated with the latest available in the store.

Was this helpful?

Related posts:.

• What is Superscalar? Works, Example, Pros, Cons & More
• What is Skylake Processor? (Explained)
• What is Haswell Processor? Features, Generation & More
• What is Kaby Lake Processor? (Explained)
• What is Broadwell Processor? Function, Generation & More
• What is Coffee Lake Processor? (Explained)

Leave a Comment Cancel Reply

Your email address will not be published. Required fields are marked *

Save my name, email, and website in this browser for the next time I comment.