Canonical question regarding the 2018 Jan. disclosed Meltdown and Spectre Attacks. Other identical or significantly similar questions should be closed as a duplicate of this one.

Main concerns

  • What is speculative execution and what does it do?
  • What is the difference between Meltdown and Spectre?
    • How does Meltdown work?
    • How does Spectre work?
  • How do I protect myself?
  • Is the KPTI/KAISER patch sufficient to protect my computer?
  • The patch is claimed to induce a loss of performance; is it true? How much does this mean?
  • Can/should I disable the new patch if I'm worried about performance losses? What are the risks?
  • Which platforms and CPUs are vulnerable?
  • I'm running a virtual machine/containers; to what extent am I vulnerable?
  • Can I detect a Meltdown/Spectre attack on my computer?
  • Are these attacks remote code execution vulnerabilities?
  • Do I need to patch my software/website?
  • Can I be affected while visiting a website?
  • Can you explain this with an image?


  • 2
    @ToddWilcox I knew about Meltdown, but I am still trying to gather enough information about Speculatius, eeh Spectre. The SPARC systems I’m talking about are 32-bit SPARC v7 and v8, produced by Sun/TI/Fujitsu/Ross/Cypress in the 1990s mostly, not the “UltraSPARC” v9 SPARC64 ones by Sun/Oracle and some others. There’s absolutely no information findable on the ’net which CPUs have speculative execution; this article was surprisingly helpful though, but I assume many older ones aren’t affected.
    – mirabilos
    Commented Jan 5, 2018 at 21:34
  • 1
    @ToddWilcox It is inaccurate to say that all processors (current and future) which use speculative execution are vulnerable to Spectre. Speculative execution, itself, does not inherently make a processor vulnerable to Spectre. It's that there are secondary effects of the speculative execution which affect the state of the processor/system which are not fully reverted when the speculative execution is dependent on memory to which the current process is not supposed to have access. The malware must then be able to determine what has (likely) changed in the processor state.
    – Makyen
    Commented Jan 8, 2018 at 7:43
  • 1
    Not only fun: xkcd.com/1938 Commented Jan 12, 2018 at 11:30
  • 1
    @F.Hauri: And now it is clear how important basic security practices are: xkcd.com/1200.
    – user21820
    Commented Jan 14, 2018 at 2:27
  • 1
    Note that grsecurity (commercial-only now) mitigates Meltdown with no performance hit without KPTI.
    – forest
    Commented May 8, 2018 at 3:09

3 Answers 3


This answer is an attempt at addressing simply the main concerns. The details here might not be exemplary accurate, or complete. I'll try to link to more detailed explanations when possible.

What is speculative execution and what does it do?

Speculative execution is a feature of modern processors that comes as an optimisation. To allow for the parallel treatment of instructions into the processor pipeline, instructions can be processed ahead of time by using techniques such as branch prediction, value prediction or memory prefetch. Instructions can then be executed out-of-order.

This is a way to gain time by predicting correctly what happens next, instead of keeping the processor idle. When the prediction fails, the instructions are rolled back.

What is the difference between Meltdown and Spectre?

Meltdown exploits are globally easier to implement than Spectre.

Meltdown takes advantage of memory reads in out-of-order instructions, Spectre acts on the branch prediction mechanism.

Spectre allows for cross/intra process memory disclosure, Meltdown allows disclosure of kernel memory to the user-space processes (normally not accessible).

Meltdown has a known software mitigation.

Both rely on a cache side-channel attack, which is a measure of timing differences when accessing certain blocks of memory to deduce the information otherwise unknown.

How does Meltdown work?

In a nutshell, Meltdown works by asking the processor to load memory the user-space program should not have access to. Memory is read in an out-of-order fashion and put into cache. Using a side-channel attack (execution time measurement) on the cache, it is possible to infer the value of that memory location.

How does Spectre work?

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.

How do I protect myself?

Update your operating system and/or hypervisor.

The main operating system distributors already release patches to implement the KPTI/KAISER behaviour. This is a means to reduce the attack surface by removing the user memory mapping of the kernel that are not strictly necessary for the processor to function.

Microcode (firmware) updates are likely to be release at some point.

Are the KPTI/KAISER patch sufficient to protect my computer?

No. And it only covers Meltdown.

The problem lies in the architecture design of the processors. To solve the problems completely (or even partially in the case of Spectre), at least a firmware update will be necessary. It is also possible that processors will have to be replaced by more recent models without this design flaw.

The patch is claimed to induce a loss of performance, is it true? How much does this mean?

Yes, but the loss incurred is dependent of the software workflow. Claims are it could range from 5% to 30% loss, depending on how system call reliant your software is. Benchmarks with high kernel-to-user space transitions, such as databases, have been reported to be the most affected.

This is still undergoing investigations, preliminary reports have been made (see links). However, since impacts vary by application, you should test the performance impact in your environment rather than relying on generic benchmarks.

Preliminary results (independent??):

Official announcements:

Can I/Should I disable the new patch if I worry about performance losses? What are the risks?

No. You can, but it's definitely not recommended.

First of all, if you're managing data from others, you would make your clients vulnerable to data theft.

Then, the performance losses still have to be properly evaluated and are highly dependent on your specific workflow. It's not a straight down 30% in performances.

Should you disable KPTI, you run the risk of having your confidential data leaked.

Which platforms and which CPU are vulnerable?

Most of the Intel CPU are vulnerable to both attacks. AMD CPU seems to be only affected by Spectre. Some ARM Cortex processors are affected, while all other ARM processors are not. PowerPC processors in the POWER 7, POWER 8, and POWER 9 families are affected, and others may be.

(see links for details).

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.

Can I detect Meltdown/Spectre attack on my computer?

It's very difficult, if even possible to.

Meltdown and Spectre both uses a designed property of the CPU that is triggered by innocuous programs all the time, making malicious programs difficult to tell apart from benign programs.

Are these attacks a remote code execution vulnerability?

No they aren't.

To be able to apply this attack, the attacker need to be able to execute code on the target host. Note however that if these are combined with other attack vectors, for example file upload or cross-site-scripting exploits, then there is a possibility of executing them remotely.

Do I need to patch my software/website?

In an ideal world, no.

In reality, some browser vendors already have implemented decrease in time accuracy measurements to mitigate the side-channel attacks. The KPTI should already provide a fair enough fix for programs using native system calls.

Can I be affected while visiting a website?

Yes, there's already a proof of concept of a Javascript exploit for Spectre (only).

Can you explain this with an image?

No, but Randall Munroe can:

XKCD #1938 - Meltdown and Spectre

[Source XKCD : https://xkcd.com/1938/]

  • 27
    @scohe001: the explanation is simplified. The problem is that the CPU does not properly validate access restrictions for code that was executed speculatively out-of-order. Remember that speculative execution means that there is a significant chance that the results of executing the code are going to be thrown away, so it seems to make sense to delay costly access restriction checks. The result is that the memory access has already happened by the time the CPU throws away the speculatively executed code. The second problem is that the CPU does only clean up stuff that is directly … Commented Jan 5, 2018 at 20:29
  • 28
    observable, when it rolls back the speculatively executed code. What the researchers have found now, is a way to indirectly observe something that the engineers at Intel (and likely many other vendors as well) thought could not be observed. In particular, accessing data from cache is faster than accessing data from memory, and thus by measuring how long it takes to access particular data, the attacker can know which addresses are in cache and which aren't Commented Jan 5, 2018 at 20:31
  • 27
    The way the exploit works is that the speculative code encodes the data it read illegally into an address which it causes to be cached, and the exploit code can then find out via timing which address was cached. Let's just see how we can steal one bit of data: the speculative code reads one bit of data from the kernel and depending on what that bit is, it loads either address 0xdeadbeef or address 0xc00ffee. Now, everything gets rolled back as it should, except that whatever memory the "reader" code accessed is cached. Now, the exploit just needs to read those two addresses and see which … Commented Jan 5, 2018 at 20:34
  • 27
    comes back faster. So, the trick is that the speculatively executed code 1) reads some value from an address it shouldn't have access to, 2) encodes that value into an address it does have access to, 3) reads that address so that it is cached. The "normal" code then reads all the possible addresses (256 if we want to communicate 1 byte) and sees which one comes back faster than the others, then it knows what the byte at that address was. Repeat that over and over again, and you can eventually read the entire memory space. Commented Jan 5, 2018 at 20:37
  • 6
    @aroth this is to be the canonical 'Question'. If you feel you can give very detailed explanations about each attacks, I encourage you to add a new answer. My answer is an attempt to make the vulnerability clearer to the maximum of persons, including the non security-savvy.
    – M'vy
    Commented Jan 6, 2018 at 10:44

Simple tips

In addition to M'vy's excellent answer, I just want answer this question:

What can I do in order to be safe?

  • Spectre, Meltdown and Rowhammer are CPU conceptual bugs, so they couldn't be correctly patched by a software update. This means: Actual software patches do mostly decrase the overall performance of any system (Windows, Linux of MacOS).
  • These bugs also concern isolation. Knowing that:

    All isolation features (sandbox, containers, virtual host and users privileges) are now subject to caution!

    is the correct way of thinking!

  • Old security habits are now useful, such as:
    • having all sensitive applications located on physically dedicated hosts,
    • having one physical host for each sensitive customer (for providers),
    • storing importants data like backups and sensitive data like passwords or any secrets, on separated (dedicated) hosts.
    • browse network on dedicated host and do banking after a full desktop reboot or better: on another (dedicated) host!

If you do isolation by using different hardware hosts, you could safely use speculative execution and all other nice features (even with other, not already known, bugs) offered by modern CPUs. There is no need to decrase your system performances!

( If so, upgrading may not be the better way... ;-)

Why I think hardware separation/dedicated could be useful?

See this trip, published on April 17, 2013! (near than five years ago;)

Source: xkcd.com/1200

XKCD 1200

  • Could you maybe elaborate on your last statement? I'm not sure if this is true and I'm inclined to disagree/downvote.
    – Tom K.
    Commented Jan 12, 2018 at 13:27
  • 1
    @Tom If your installation is correctly isolated by hardware, then by upgrading softwares you just will decrase performances. So for this case, and for this case only, not aplying patches could let your system go fast... Of course, if you plan to use same desktop for web surf and banking, then your config don't fit this requirement! Commented Jan 12, 2018 at 14:40
  • @Tom ... And: As bug is hardware, changing the soft is the wrong answer. ( Plan to ask your provider to exchange your CPU while this must be *unger warranty"! ;-) Commented Jan 12, 2018 at 14:42
  • "having one physical host for each sensible customs (for providers)" - um, what?
    – Wildcard
    Commented Jan 16, 2018 at 1:44
  • 4
    I think he means sensitive for «sensible» in all occurrences, and «customs» should be customer.
    – JDługosz
    Commented Jan 16, 2018 at 15:02

This answer is specific to the Spectre Next Generation attacks and will be updated as soon as new information are available.

Update, May 22nd:

The first patches are coming and so are more information regarding the new vulnerabilities:

Intel released this statement on May 21st 2018 which will give you a good overview over Spectre variants 3a and 4.
The respective CVEs are:

  • CVE-2018-3639 - Speculative Store Bypass (SSB) – also known as Variant 4
  • CVE-2018-3640 - Rogue System Register Read (RSRE) – also known as Variant 3a

Pretty much all Intel processors that were manufactured in the last 10 years are affected by these two vulnerabilities. Microcode updates have been made available to OS vendors, so they should be available to customers soon. Linux users should be safe if they updated their kernel recently and if their distribution uses retpolines.[citation needed]

If you want to know more about the technical details, Intel's whitepaper that analyzes speculative execution side channels - which was published after the Spectre and Meltdown attacks came to light - was extended to now cover variants 3a and 4. This is also true for this whitepaper which covers mitigation.

Further reading:
Jann Horn's original disclosure mail
AMD saying none of their products are vulnerable to SSB
ARM blog post
Debian security tracker
Intel blog Microsoft's analysis of SSB
Red Hat vulnerability response
SUSE security blog
Ubuntu security notice
US CERT vulnerability note
VMWare Knowdlege Base article

Update, May 7th:

The planned publication of technical details has been delayed until at least May 21st and perhaps even longer because Intel was not able to finish development of the needed microcode updates.
But there was some new information published today, a list of the processors that are possibly affected by at least two of the eight new vulnerabilities:

  • all i-X processors and the respective Xeon derivatives since 2010 (these are also affected by the vulnerability described under '6')
  • Atom-based Pentium, Celeron and Atom processors since 2013

These first processor types are the typically used in desktop PCs, notebooks and servers. The second ones are used in tablets, smartphones und embedded devices.
There are no CVEs and no catchy names yet.

On May 3rd the German magazine c't - which is specialized in IT - reported that researchers have found eight additional vulnerabilities in Intel CPUs that all enable Spectre-like attacks. All these new vulnerabilities are based on the same design flaws as the vulnerabilities that are exploited by Spectre V1 and V2.

The first technical and in-depth report which will cover one of these vulns will probably be released on May 7th by the Google Project Zero. It is possible though, that other researchers or independent parties will release reports earlier.

What we know so far:

  1. There are eight new vulnerabilities.
  2. Each one will get its own CVE.
  3. Each one will require its own patch. There is little knowledge about the progress of the development of patches so far. According to the c't, Intel plans two patch waves: one in May and another in August.
  4. There is no list of affected processors yet. Intel processors are probably for the most part affected. Some ARM CPUs seem also to be affected. It is unclear so far if AMD CPUs are affected.
  5. Intel classifies four of the eight vulnerabilities as "high risk", the other four as "medium risk".
  6. One of the new vulns allegedly allows for very easy cross system attacks. An adversary might be able to attack a host system or other VMs from a source VM. This is especially dangerous for cloud providers. An attack like this was possible before, but it was very complex. The new vulnerability seems way easier to exploit. All other attack vectors seem very similar to Spectre V1 and V2.

Conclusion: We know very little so far and what we know are merely abstract descriptions of the new vulnerabilities. Spectre and Meltdown are very complex attacks and the underlying vulnerabilities are no less complex. All technical details will slowly flow into the discourse over the next few weeks. But the CPU vendors are informed and it seems that they and Kernel developers are already working on solutions. Have patience.

Source: https://www.heise.de/ct/artikel/Super-GAU-fuer-Intel-Weitere-Spectre-Luecken-im-Anflug-4039134.html

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .