How to protect against the Meltdown and Spectre vulnerabilities

Meltdown and Spectre are two different (but related) vulnerabilities found in almost all modern processors, affecting mobile devices, desktop and laptops, and servers. They are the result of hardware architectures that allow user-space programs to read in-memory data that they wouldn’t normally be allowed to read. For instance, one user’s application could potentially access passwords or encryption keys from another running process. The vulnerabilities affect desktops and laptops, tablets, mobile phones, servers, and cloud server instances — pretty much everything. Of particular concern are multi-tenant or shared environments such as public/private clouds where sensitive user/company/state data could potentially be accessed by bad actors.

Initially, researchers believed the only solution would be to physically replace all affected processors – an impractical solution in the short term. Instead, researchers, processor manufacturers, and leading industry software vendors agreed that operating system and application code would be patched to provide near term protection against exploits.

For more technical detail, please refer to the published security research papers on Meltdown and Spectre.


The not so bad news:

  • There are no known exploits in the wild at the time of this writing. While the vulnerabilities are based on an old set of design decisions, it doesn’t appear any bad actors have been exploiting the issue.
  • The vulnerabilities do not appear to be remotely accessible – they are local only. In order to leverage an attack, an application needs to run locally on the machine. This could be a virtual machine reading memory contents written by another virtual machine, or possibly even malicious JavaScript loaded through a web browser.  It is possible for an attacker to leverage another vulnerability remotely (like a remote script injection attack through a web server or services API) and eventually trigger Meltdown and Spectre.
  • The attacks are read-only and do not allow exploits to directly modify the contents of memory.
  • The whole industry has been working on this for a while, with patches either on their way or already out.
  • Both attacks are highly complex and difficult to make work in a real-world environment. They are reading from a rapidly changing portion of memory, so for most data center systems, there will be an enormous amount of noise in the data.

The really bad news:

  • Everything is going to have to be patched, and there are different patches for Meltdown and Spectre with differing levels of complexity.
  • The plan was to announce the issues publicly on 1/9/2018 with coordinated patch releases across the major industry players, but news of the vulnerabilities leaked early, leading to confusion and a perceived delay in patch releases.
  • Given the nature of the patches, there is potential for degradation of application performance after applying the patches. The severity of this degradation is dependent upon the make/model of processor (especially in regards to PCID availability), the specifics of the OS or application patches, and the type of workload in question. Performance degradation could range from 5 to 40 percent.


As mentioned above, Meltdown and Spectre are related side-channel vulnerabilities but differ greatly in their scope and impact. It is important to understand their operational similarities and differences.


  • Affects most Intel processors released since 1995. Some ARM processors are affected. AMD processors do not appear to be affected at this time.
  • Meltdown can be patched by vendor-provided operating system patches.
  • Leaks kernel and user memory.


  • Affects almost all modern processors, including GPUs, are affected.
  • There is no simple patch for Spectre as it results from a core computational architecture design issue. Patching Spectre in the long term may require a core redesign of existing computational architectures.  In the short term, it will require the combined patching of the following: CPU microcode, OS kernels, drivers, libraries, compilers, and applications.
  • Leaks only user memory (not kernel memory).


Intel  Security Advisory   /    Newsroom   /    Whitepaper
ARM  Security Update
AMD  Security Information
RISC-V  Blog
NVIDIA  Security Bulletin  /   Product Security
Microsoft  Security Guidance   /    Information regarding anti-virus software   /    Azure Blog   /    Windows (Client) /   Windows (Server)
Amazon  Security Bulletin
Google  Project Zero Blog   /    Need to know
Android  Security Bulletin
Apple  Apple Support
Lenovo  Security Advisory
IBM  Blog
Dell  Knowledge Base  /   Knowledge Base (Server)
HP  Vulnerability Alert
Huawei  Security Notice
Synology  Security Advisory
Cisco  Security Advisory
F5  Security Advisory
Mozilla  Security Blog
Red Hat  Vulnerability Response  /   Performance Impacts
Debian  Security Tracker
Ubuntu  Knowledge Base
SUSE  Vulnerability Response
Fedora  Kernel update
Qubes  Announcement
Fortinet  Advisory
NetApp  Advisory
LLVM  Spectre (Variant #2) Patch  /   Review __builtin_load_no_speculate  /   Review llvm.nospeculateload
CERT  Vulnerability Note
MITRE  CVE-2017-5715  /   CVE-2017-5753   /    CVE-2017-5754
VMWare  Security Advisory  /   Blog
Citrix  Security Bulletin  /   Security Bulletin (XenServer)
Xen  Security Advisory (XSA-254)  /   FAQ

This section has been updated to reflect our most recent findings. (2/16/18)

Microsoft has been very active in releasing several patches for Spectre over the past two weeks and has also released a number of free tools and monitoring options. For more on this, check out:

One of the more interesting approaches to fighting Spectre is an effort by Microsoft to address variant #1 (bounds checking) by having its C++ compiler insert a special instruction in front of any code segment that accesses an array to prevent invalid access during speculative execution. Check out this excellent summary in Ars Techica. Unfortunately, Paul Kocher, one of the original discoverers of the Spectre vulnerability, has already tested the fix and believes it falls short of adequately blocking most Spectre-based attacks. Nevertheless, this effort is a great example of the sort of innovative research happening now that will be needed to counter Meltdown and Spectre in the long term.

Many cyber security OEMs also continue to offer their help in this battle, just two examples being Qualys and Palo Alto with new firewall signatures to detect attacks based on publicly available research code.


There are two areas of risk most organizations have regarding Meltdown and Spectre: the security risk itself, and the operational risks of patching and post-patch affects.

WWT is focusing on both and is here to help enterprise organizations make the best of a bad situation.

  • Our security team is actively researching the vulnerabilities to better understand scope and scale.  Some of our engineers/architects/analysts have deep knowledge of similar side-channel attacks, so we have the right people in place to assist. We plan to share any additional insight/updates via WWT Blog posts.
  • Our Advanced Technology Center (ATC) and global engineering teams are building out test environments in the WWT ATC to perform before and after performance testing for common scenarios and workloads. From this we hope to be able to provide real-world baseline performance guidance that organizations can leverage to make better decisions about which systems to patch, performance expectations after patching, and how to quickly and efficiently resolve compute capacity shortages post-patch.
  • For vendors and enterprise organizations that have specific applications or system builds they need to test, WWT’s ATC is an ideal place to get this done quickly and safely. Vulnerability testing, patch testing, patch procedure testing, and performance testing can all be achieved in the ATC. Learn more here.

For more information or help, please reach out to your WWT Account Team or contact WWT directly. You can also visit this page to learn more about WWT and these exploits.

Authors Note: Special thanks to Gene Geddes, cybersecurity chief scientist, and Ian Evans, compute principal solutions architect, for their contributions to this post.

Leave a Reply

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

  1. Jeffrey Coe says:

    Good information. But how often will this be updated periodically with the latest developments?

    1. Gene Geddes says:


      Thanks for checking out the post! Very interesting development — almost unbelievable in its scope.

      Not much progress has been made industry wide, essentially three steps forward and two steps back. We just updated the section on vendor activity to capture this.

      Feel free to get touch with us anytime on this (or any other topic).

      Gene Geddes
      Chief Scientist, WWT Global Security Practice