The patch for Meltdown is rumoured to incur a 30% performance penalty, which would be nice to avoid if possible. So this becomes a Security vs Performance risk-assessment problem.

I am looking for a rule-of-thumb for assessing the risk of not patching a server or hypervisor.

From reading the whitepapers, my understanding is that you definitely need to apply the patch if your machine:

  • is a workstation that runs random potentially malicious code - including, it turns out, java script from random websites,
  • is a VM that could potentially run malicious code (which essentially becomes the first case).
  • is a hypervisor that runs untrusted VMs next to sensitive VMs (which essentially becomes the first case),

My understanding is that the risk is (significantly) lower in the following cases:

  • server running on dedicated hardware running a tightly-controlled set of processes in a tightly-controlled network (including not using a web browser to visit untrusted sites)
  • VM running a tightly-controlled set of processes on a virtualization stack of other tightly-controlled VMs, all in a tightly-controlled network.

Is that logic sound, or am I missing something?

UPDATE: early adopters of the patch in Azure are reporting no noticeable slowdown, so this may all be moot.

Related question: What are the risks of not patching a workstation OS for Meltdown?

  • 11
    Rumor has it the performance implications aren't that bad, particularly for newer processors with PCID. Commented Jan 4, 2018 at 6:06
  • 1
    @AlexanderO'Mara "a Linux developer measured it to be roughly 5% for most workloads and up to 30% in some cases, even with the PCID optimization"
    – ave
    Commented Jan 4, 2018 at 16:23
  • 7
    "is rumoured to incur a 30% performance penalty" - When I first heard of this, people were saying "likely 5-30%" penalty. The estimated worst possible performance hit seems to have rapidly started to be treated as the likely performance hit...
    – Izkata
    Commented Jan 4, 2018 at 21:02
  • 2
    @Ave Most practical desktop workloads are looking at 1-2%, if even that much. Synthetic I/O benchmarks are hardest hit (at >20%), and some server workloads (especially DB servers?) will suffer at 10-15%. So if performance is a consideration, you're probably better off actually testing your real workload (and using the config options available in both Linux and Windows to toggle PTI) rather than going off publicly reported numbers.
    – Bob
    Commented Jan 5, 2018 at 1:45
  • 3
    I also want to stress the part mentioned by @Izkata : 30% is mentioned as a worst-case scenario (though even 5% is high for enterprise environments). We'll know A LOT more on January 9th when the embargo on many parts of this subject will be lifted and the patch from Microsoft arrives. Commented Jan 5, 2018 at 10:02

2 Answers 2


Basically, if you run code from untrusted sources on a machine that has data you don't want that code to have access to, you need to patch. Desktop computers should be patched because they've got an unfortunate habit of encountering untrusted code; shared-hosting servers, particularly virtual private server hosts, must be patched, because Meltdown lets one user access every other user's data.

Note that the Meltdown attack cannot be used to break out of a virtual machine. You can break out of a container, sandbox, or a paravirtualized system, but performing the Meltdown attack in a fully-virtualized system just gets you access to that VM's kernel memory, not the host's kernel memory.

  • 16
    I respectfully disagree, from VMWare's security bulletin: "Result of exploitation may allow for information disclosure from one Virtual Machine to another Virtual Machine that is running on the same host". The whitepaper only mentions breaking out of containers, but I suspect the exploit can be applied more broadly. Commented Jan 4, 2018 at 16:33
  • 2
    @MikeOunsworth (and Mark), the VM piece of this question should be addressed in a separate question.
    – NH.
    Commented Jan 4, 2018 at 19:21
  • Despite the excellent other Q&A pair, this answer and the above comment should be updated to reflect the content of that post - is it the answer or comment here which is incorrect?
    – Tim
    Commented Jan 5, 2018 at 0:06
  • 9
    @Tim, the comment is based on a misreading of the security advisory. Spectre can break out of a virtual machine, Meltdown can't.
    – Mark
    Commented Jan 5, 2018 at 1:03
  • To re-iterated: the VMWare bulletin is discussing Spectre, aka CVE-2017-5753 and CVE-2017-5715. This answer is discussing Meltdown, aka CVE-2017-5754.
    – Mark
    Commented Jan 5, 2018 at 19:06

My understanding of the issue is that it is a local information leak, where local means that the information are leaked "only" to processes on the same physical hardware and not (directly) to remote systems. And, it is an attack which was shown to be actually usable in practice to extract sensitive information, even it is currently not trivially to exploit. But how easy the exploit is might quickly change as seen by Rowhammer, which evolved within a short time from only being a mostly theoretical problem to more reliable exploiting the issue using Javascript inside a browser or to root Android phones.

Thus, if there is the chance that some untrusted code is executed on the server you should patch. That's why all the larger cloud providers already patched their systems or will do shortly. And that's why the patches were so quickly incorporated into the Linux kernel, which is very unusual for changes to the memory subsystem.

Note that untrusted code might not only be run if you have untrusted users on the system. It can also happen if you process data originating from an untrusted source. For example an attacker could use existing functionality of your web server to upload an image which then gets converted on your server (i.e. scaling or similar). Given the history of bugs in graphic libraries it would not be unlikely that this conversation could result in code execution. And giving the nature of the issue I doubt that sandboxes, docker or similar will stop exploitation of the bug.

  • 4
    The severity is half the reason the patches were incorporated into Linux so quickly. The other half is that the patches were already under development, as an extension to the KASLR protection mechanism.
    – Mark
    Commented Jan 4, 2018 at 8:59
  • 9
    @strugee: yes, citation is very much needed. But anyway: running Javascript inside the browser definitely counts in most cases as running code from an untrusted source. Commented Jan 4, 2018 at 9:13
  • 9
    @SteffenUllrich @strugee source is in the whitepaper, page 6 Example Implementation in JavaScript. Quote: JavaScript code was written that, when run in the Google Chrome browser, allows JavaScript to read private memory from the process in which it runs Commented Jan 4, 2018 at 14:01
  • 1
    @JohnDvorak: Only if Firefox doesn't JIT its JavaScript.
    – Joshua
    Commented Jan 4, 2018 at 23:36
  • 2
    @JohnDvorak Firefox 57.0.4 - that was launched just yesterday (Jan 4, 2018) - included "fixes" (mitigation measures) for Meltdown and Spectre attacks, according to: [1] mozilla.org/en-US/firefox/57.0.4/releasenotes ; [2] blog.mozilla.org/security/2018/01/03/… and [3] mozilla.org/en-US/security/advisories/mfsa2018-01
    – ricmarques
    Commented Jan 5, 2018 at 10:58

You must log in to answer this question.

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