In June 2017, a team constituted of independent researchers, university research labs, and some of Google’s Project Zero members and cyberus technology discovered two security vulnerabilities enabled by the widespread use of speculative execution in most of the CPU. The problem was also independently discovered by other researchers, at about the same time. These vulnerabilities, called Meltdown and Spectre, were made public in January 2018.

Meltdown and Spectre are critical vulnerabilities existing in several modern CPU: these hardware bugs allow programs to steal data which is currently processed on the computer. Meltdown and Spectre can affect personal computers, mobile devices, server and several cloud services.

Depending on the bug, the affected CPU are Intel processors (since 1995!), some AMD CPUs, and several ARM-based Samsung and Qualcomm system-on-chips used for mobile phones.

There are three separate vulnerabilities that were discovered and reported by multiple security teams, named Spectre (variant 1 & 2) and Meltdown (variant 3).

But what’s the status of the patches, after more than one month of the announce of those threads?

Patches status

Meltdown is the vulnerability that melts security boundaries which are normally enforced by the hardware; this issue afftects Intel CPU (AMD seems to be safe) and some ARM CPU.

This exploit it’s easy to be used: if your computer has a vulnerable processor and runs an unpatched operating system, it is not safe to work with sensitive information without the chance of leaking the information.

But it’s also “easy” to be fixed by software patches that already exists for several operating systems, for example for the most used software in the server market:

• Linux it’s using KPTI (formerly KAISER), and it’s included in several kernels, but the recommended it’s the 4.15 version.
  Users can choose to turn it off with a the special pti=off kernel boot option.
• Microsoft Windows OSes has provide patches for all Windows Server versions starting with 2008 R2 through 2016 (except Windows Server 2012)
• VMware’s hypervisor products are not affected by the known examples of Meltdown attacks. Virtual appliances and others VMware’s products may require specific software patches depending by the operating system used.

CVE-2017-5754 – CVSSv3 7.9 (Rogue Data Cache Load) is the official reference to Meltdown. Sometimes it’s also called Variant 3 of the speculative execution exploits.

Spectre breaks the isolation between different applications. It allows an attacker to trick error-free programs, which follow best practices, into leaking their secrets. In fact, the safety checks of said best practices actually increase the attack surface and may make applications more susceptible to Spectre.

The name is based on the root cause, speculative execution. Compared to Meltdown, Spectre is harder to exploit, but it is also harder to mitigate. However, it is possible to prevent specific known exploits based on Spectre through software patches and CPU microcode updates. But note that today it’s not totally fixed!

This because there isn’t a clear and simpe way to solve this issue, considering also that there are two different types of Spectre:

• Variant 1 (or Spectre v1): bounds check bypass
• Variant 2 (or Spectre v2): branch target injection

On January 4, 2018, Google detailed a new technique on their security blog called “Retpoline” which can overcome the Spectre v2 vulnerability with a negligible amount of processor overhead. It involves compiler level steering of indirect branches towards a different target that does not result in a vulnerable speculative out-of-order execution taking place.

But there are also different types of approaches to minimize or mitigate those issues, include the usage of CPU microcode update (that have been delayed by Intel, due to stability issues) to implement specific new security functions.

Actually there are some software patches that solves part of the problem, for example for the most used software in the server market:

• Linux kernel actually has a fix for the Spectre v2 (available for both Intel and AMD processors, not yet for ARM), that comes in the form of a retpoline mechanism. It requires use of a compiler (GCC) that is compatible, so users will need to update accomplying fixes as well. The Spectre-inhibiting mechanism can be turned of. To do so, use the spectre_v2=off option at boot time. But the Spectre v1 vulnerability is still at not covered, although it’s difficult to exploit.
• Microsoft, while Intel tests, updates and deploys new microcode, they havemaking available an update, KB4078130, that specifically disables only the mitigation against Spectre v2. Spectre v1 was already covered.
• VMware’s hypervisor products are affected by the known examples of variant 1 and variant 2 vulnerabilities and do require the associated mitigations. Spectre v1 is managed by ESXi updates, but Spectre v2 require specific CPU microcodes.
  Although VMware strongly recommends that customers obtain microcode patches through their hardware vendor, as an aid to customers, VMware also included the initial microcode patches in ESXi650-201801402-BG, ESXi600-201801402-BG, and ESXi550-201801401-BG. But due to some possible issues, VMware is delaying new releases of microcode updates while it works with Intel to resolve microcode patch issues as quickly as possible (but still there is no news).
  For all VMware’s virtual appliances, see this page.

CVE-2017-5753 – CVSSv3 8.2 (Bounds Check Bypass) and CVE-2017-5715 – CVSSv3 8.2 (Branch Target Injection) are the official references to Spectre.

This table summarize most of concepts:

Support and maintenance

Having supported hardware and software components it’s the crucial part: actually those issues may affect system with more than 10 years (also 15 years), but patches and microcode updates will be provided only for “recent” systems!

What does it mean? If you are still using an old operating systems (like Windows XP or Windows Server 2003) or an old hypervisor (like VMware vSphere 4.x, or also vSphere 5.0 and 5.1!) or are you using an old server (with not specific microcode patches), you may be exposed to potential security risks.

How old can be my system? It’s depends, but potentially around 8 years could be the limit for server systems: for example Dell will provide microcode updates also for PowerEdge generation 11 systems (not sure when)

And anyway it’s a more general discussion, maintenance and support are critical and crucial for each production environment… you cannot really consider to don’t have them.

In those cases it’s really the time to consider an hardware / software refresh cycle!

Performance impact

The performance impact as always will depend on the specific workload being tested, and while industry benchmarks are nice, companies will ultimately need to measure the impact on their own infrastructure. Intel does note that “workloads that incorporate a larger number of user/kernel privilege changes and spend a significant amount of time in privileged mode will be more adversely impacted.”

Performance are affected by those software patches, but patches are going better and better and so, for example with Linux kernel 4.15 version “Turning kpti on makes 4.15 1-2% slower than 4.11”. So with the security patches the system is little slowest than before. Not so bad, considering that the (initial) expect overhead where around 20-30%!

Intel has published some data, of it’s patches:

For many of the benchmarks, the performance delta is relatively small. Integer, floating-point, Linpack, Stream, server-side Java, energy efficiency, and OLTP brokerage all show a 0-4 percent drop in performance. When we get to the storage benchmarks, however, things get a bit more complex.

But it’s really too early to estimate the real impact of all those patches, also considering that the microcode update is still missing for several systems and that some optimizations may balance (at least a part of) the performance drops.

Some vendors are providing some responses:

• Red Hat: the Red Hat Performance Engineering team characterized application workloads to help guide partners and customers on the potential impact of the fixes supplied to correct CVE-2017-5754, CVE-2017-5753 and CVE-2017-5715, including OEM microcode, Red Hat Enterprise Linux kernel, and virtualization patches. The performance impact of these patches may vary considerably based on workload and hardware configuration. Measurements are reported based on Industry Standard Benchmarks (ISB) representing a set of workloads that most closely mirror common customer deployments. The results are available on this page.
• Microsoft: enabling these mitigations may affect performance. The actual performance impact will depend on multiple factors, such as the specific chipset in your physical host and the workloads that are running. Microsoft recommends that customers assess the performance impact for their environment and make necessary adjustments.
• VMware is currently evaluating the performance costs of the Meltdown/Spectre mitigations for VMware products. They will plan to test with a wide variety of workloads using both unpatched and patched guest operating systems to provide a comprehensive view of relevant performance characteristics. See also KB 52337

Andrea Mauro

Virtualization, Cloud and Storage Architect. Tech Field delegate. VMUG IT Co-Founder and board member. VMware VMTN Moderator and vExpert 2010-24. Dell TechCenter Rockstar 2014-15. Microsoft MVP 2014-16. Veeam Vanguard 2015-23. Nutanix NTC 2014-20. Several certifications including: VCDX-DCV, VCP-DCV/DT/Cloud, VCAP-DCA/DCD/CIA/CID/DTA/DTD, MCSA, MCSE, MCITP, CCA, NPP.