This post is also available in: Italian

After few weeks of the recent Intel CPU security bug, not yet closed (considering that affect also the recent Skylake family), there are new threads on the CPU.

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.

It’s not easy, like in the past, fix those issues with a simple new CPU microcode upgrade; also because in some cases are based on a fundamental design flaw. So, there are some fixes at the operating system layer to minimize the security impact, but with a potential performance impact cost from 5 to 20% of degradation!. Red Hat was one of the first does perform some benchmark, but the performance degradation affect in a different way depending also by the type of applications. See also this post, for other considerations about performance impact.


Meltdown breaks the most fundamental isolation between user applications and the operating system. This attack allows a program to access the memory, and thus also the secrets, of other programs and the operating system.

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. This applies both to personal computers as well as cloud infrastructure. Luckily, there are software patches against Meltdown.

Desktop, Laptop, and Cloud computers may be affected by Meltdown. More technically, every Intel processor which implements out-of-order execution is potentially affected, which is effectively every processor since 1995 (except Intel Itanium and Intel Atom before 2013). At the moment, it is unclear whether AMD processors are also affected by Meltdown. According to ARM, some of their processors are also affected.

CVE-2017-5754 – CVSSv3 7.9 (Rogue Data Cache Load) is the official reference to Meltdown.


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 actual flaws reside in a technique called “speculative execution” that is employed by all modern CPUs. This is a basic optimization technique that processors employ to carry out computations for data they “speculate” may be useful in the future.

Spectre is harder to exploit than Meltdown, but it is also harder to mitigate. However, it is possible to prevent specific known exploits based on Spectre through software patches.

Almost every system is affected by Spectre: Desktops, Laptops, Cloud Servers, as well as Smartphones. More specifically, all modern processors capable of keeping many instructions in flight are potentially vulnerable. In particular, we have verified Spectre on Intel, AMD, and ARM processors.

Recently, Oracle has admitted that also Sparc architecture can be affected:

Oracle believes that certain versions of Oracle Solaris on SPARCv9 are affected by the Spectre vulnerabilities. […] Oracle is working on producing the patches for all affected versions that are under Premier Support or Extended Support.

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.


Patching it’s not so easy… you cannot just fix the CPU with a microcode or a BIOS upgrade. Potentially you need to patch each level as this tweet synthesize well:

Actually, the different operating systems and hypervisors vendors are providing different patches and solutions for those bugs. For more information see:

But also hardware’s vendors has published several information on how patch this level:


Most of the CPU are affected, but not all… The ARM11 cores in the Raspberry Pi and RISC-V seem to be immune. But most of the mobile, client and server systems will be affected!

Those bugs are really serious, considering that are on the hardware level, so the attacks are also hard to detect, because potentially an exploitation does not leave any traces in traditional log files! And you can risk a lot in your security, for example for the passwords:

Anyway, at this stage, the proof-of-concept exploit can read the memory content of your computer (this may include passwords and sensitive data stored on the system) but require a local access to run the command… so you have to first attack the system with a traditional way to gain a local access.

The only solution, at this time, is to patch your operating systems and your hypervisors (if you are running virtual machines). There will be also some BIOS and firmware upgrade provided by the different hardware vendors, but to reach a good protection you need both.

For the cloud providers, actually, Google says that tests on virtual machines used in cloud computing environments extracted data from other customers using the same server. But same will be with Amazon (for AWS) and Microsoft (for Azure)… will be interesting see how local and small providers will reach this issue (and inform the customers).

Anyway, the impact of those fixes could be huge: Red Hat said that depending on workloads, performance will slow by up to 20 per cent, with the most vulnerable being “highly cached random memory, with buffered I/O, OLTP database workloads, and benchmarks with high kernel-to-user space transitions.” Your mileage may vary.

Intel has realized some benchmarks to see the impact on different workloads and different CPU generation. For more information see this post. But seems too much optimistic with only 6-7% of performance degradation.

And the storage? Aren’t they based all (or most of them) on Intel Xeon processors? Potentially they are affected by both problems, but in most cases storage arrays are “embedded” system with no 3rd parties codes on it, and usually in isolated (or protected) networks. But we have also to consider that some storage vendors have build their products to run additional apps… And there are also the hyper-converged storage where CPU is shared with other workloads!

For more information see also:

This post has already been read 1838 times.

Andrea MauroAbout Andrea Mauro (2660 Posts)

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

Related Post: