google-site-verification: google30a059f9a075f398.html

Meltdown and Spectre Flaw and Vulnerability Implementation Guide

meltdown-spectre icon

Meltdown and Spectre Flaw and Vulnerability Implementation Guide

Meltdown and Spectre Chip flaws arise from features built into chips for performance with available software patches and may have impacts on system performance

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 Meltdown and Spectre. 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?

Meltdown and Spectre 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.


Security vulnerabilities

Meltdown and Spectre security vulnerabilities are affecting modern computer processors – the connections were external and the connections were external. Exploiting these vulnerabilities could give attackers access to sensitive information.
Many CPU hardware are susceptible to Meltdown and Spectre attacks. These attacks are described by CERT / CC Vulnerability VU # 584653, National Cyber ​​Security Center guidance on Meltdown and Spectre, Google Project Zero (External links), and Institute for Applied Information Processing and Communications (IAIK) at Graz Technologies University (Graz). The Linux kernel mitigation for this vulnerability, known as KAISER, was later called KPTI to improve the separation of kernel and user memory pages.


Exploiting these Meltdown and Spectre vulnerabilities could give attackers access to sensitive information.


We encourages users and administrators to refer to their hardware and software vendors for the latest information. In the case of Spectre, the vulnerability exists in the CPU architecture rather than in the software and is not easy to fix; however, the vulnerability is harder to exploit.


Microsoft temporarily stopped the update of AMD machines. More information can be found here:

For computers running Windows Server, in addition to installing patches, you must also make many registry changes. A list of registry changes can be found here: (link is external)


Microsoft recommends that a third-party antivirus vendor change the registry entry to the computer that is running the antivirus software. Without it, the machine will not receive any of the following fixes from Microsoft:

– Windows Update
– Windows Server Update Service
– System Center Configuration Manager

More information can be found here: (links are external).

Mitigation through patches by vendors
Meltdown and Spectre 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.

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.

The following table lists the available suggestions and patches. As patches and firmware updates continue to be released, be sure to contact your hardware and software vendor to confirm that the appropriate patches are applicable, as some updates may cause unexpected results.

NCCIC recommends using a test environment to validate each patch prior to implementation.

After patching, performance impact may vary, depending on usage. Administrators should ensure that the performance of key applications and services is monitored and, where possible, work with their suppliers and service providers to mitigate their impact.

In addition, users and administrators who rely on the cloud infrastructure should use CSPs to mitigate and mitigate any impact of host operating system patching and forced restarts.

The following table contains links to suggestions and patches posted in response to these vulnerabilities. This table will be updated as the information becomes available.


Meltdown and Spectre Links to Vendor Information Date Added
Amazon (link is external) January 4, 2018
AMD (link is external) January 4, 2018
Android (link is external) January 4, 2018
Apple (link is external) January 4, 2018
ARM (link is external) January 4, 2018
CentOS January 4, 2018
Chromium January 4, 2018
Cisco (link is external) January 10, 2018
Citrix (link is external) January 4, 2018
Debian January 5, 2018
DragonflyBSD January 8, 2018
F5 (link is external) January 4, 2018
Fedora Project January 5, 2018
Fortinet (link is external) January 5, 2018
Google (link is external) January 4, 2018
Huawei (link is external) January 4, 2018
IBM (link is external) January 5, 2018
Intel (link is external) January 4, 2018
Juniper (link is external) January 8, 2018
Lenovo (link is external) January 4, 2018
Linux January 4, 2018
LLVM: variant #2 January 8, 2018
LLVM: builtin_load_no_speculate January 8, 2018
LLVM: llvm.nospeculatedload January 8, 2018
Microsoft Azure (link is external) January 4, 2018
Microsoft (link is external) January 4, 2018
Mozilla January 4, 2018
NetApp (link is external) January 8, 2018
Nutanix (link is external) January 10, 2018
NVIDIA (link is external) January 4, 2018
OpenSuSE January 4, 2018
Qubes January 8, 2018
Red Hat (link is external) January 4, 2018
SuSE (link is external) January 4, 2018
Synology (link is external) January 8, 2018
Trend Micro (link is external) January 4, 2018
VMware (link is external) January 4, 2018
Xen January 4, 2018

Meltdown and Spectre Reference Sources:


If you like to receive more of these articles then subscribe to my mailing list. and come back soon at and read further CyberWisdom Safe Harbor Commentaries. Home » Defend » Meltdown and Spectre Flaw and Vulnerability Implementation Guide