{"id":12580,"date":"2019-01-07T22:19:37","date_gmt":"2019-01-07T18:19:37","guid":{"rendered":"https:\/\/me-en.kaspersky.com\/blog\/?p=12580"},"modified":"2019-11-15T15:22:37","modified_gmt":"2019-11-15T11:22:37","slug":"35c3-spectre-meltdown-2019","status":"publish","type":"post","link":"https:\/\/me-en.kaspersky.com\/blog\/35c3-spectre-meltdown-2019\/12580\/","title":{"rendered":"Spectrology: CPU hardware vulnerabilities in 2019"},"content":{"rendered":"

At the 35th Chaos Communications Congress<\/a>, almost a year after the first publication about the CPU hardware vulnerabilities tagged Meltdown and Spectre<\/a>, a group of researchers from Graz University of Technology, Austria, spoke about the current state of affairs concerning known CPU hardware vulnerabilities. Spoiler: The past year brought a lot more of them to light.<\/p>\n

The essence of Meltdown and Spectre in brief<\/h2>\n

First, let us recall what Meltdown and Spectre are, and how they differ.<\/p>\n

The Meltdown vulnerability appeared because modern CPUs can execute instructions out of order. This is a very convenient feature that does accelerate code processing, but in some cases the CPU happens to process code prone to error, code that shouldn\u2019t be executed at all. That is, first the code is executed by the CPU, and only then does it become apparent that the operation cannot be completed \u2014 such situations happen exactly because instructions are executed out of order.<\/p>\n

Of course, the results of such operations will not be passed on or used anywhere, and yet they leave traces on the microarchitecture level \u2014 in the CPU cache memory. And they can be extracted from there. As a result, the cache can be used to get hold of data that otherwise would be inaccessible: for example, a password. Here\u2019s how it works: A program may request access to data in storage \u2014 to which the system will reasonably respond that access is denied for lack of access authorization. But because of the out-of-order execution of operations, the password will still end up in the cache, and from there it can be quite feasibly fished out. In short, Meltdown may occur when attempting to execute an unwarranted action.<\/p>\n

The Spectre vulnerability is similar to Meltdown, but although it\u2019s also related to CPU computing acceleration, it stems from modern CPUs\u2019 branch prediction feature. In essence, a CPU is able to predict, with a certain amount of accuracy, that because action B normally follows action A, it can execute action B before the results of A have become clear. If the guess was right, and action B does follow, everything\u2019s good \u2014 and if the results of A indicate that the CPU should have completed action \u0421 instead of B, the CPU will just abandon the B branch and switch to another one where it has to complete action C.<\/p>\n

The branch predictor being trainable, in most cases it remembers the action sequence patterns, therefore really improving CPU performance (if B followed A several times, the CPU logically assumes that in a given situation it will have to do B after A as well). And yet mispredictions do happen (sometimes C comes along instead of B, although the branch predictor remembers full well that A is normally followed by B).<\/p>\n

If you train the system long enough by demonstrating that a certain branch is the right one and is always executed and then change a parameter so that it becomes wrong, the CPU will first execute it anyway and then repeal it, after it finds out that another one should have been executed. But, similar to what happens with Meltdown, the result of the action may still remain \u2014 for example, in the cache, where again it will be extractable.<\/p>\n

The consequences are about the same: Spectre opens a trapdoor for unauthorized access to data. That access may occur only in cases of branch prediction goes wrong, but simple probability theory tells us it will happen.<\/p>\n

A year later: two dozen of new Spectre and Meltdown variations<\/h3>\n

Following the discovery of the first Meltdown and Spectre vulnerabilities, the researchers began to dig ever more actively into the matter, and they soon discovered similar problems differing only in minor details. As they found, CPU developers also employ other optimizations resulting in Meltdown-like or Spectre-like vulnerabilities. The Graz University team mentions 14 Meltdown-like vulnerabilities and 13 Spectre-like ones \u2014 a total of 27 CPU hardware vulnerabilities versus only two belonging to those families at the beginning of 2018.<\/p>\n

\"In<\/a>

Classification of this year\u2019s catch of Meltdown and Spectre variations<\/p><\/div>\n

Moreover, even though earlier AMD had claimed that its CPUs were not exposed to Meltdown-class vulnerabilities, researchers discovered a variation of Meltdown (called Meltdown-BR) that was perfectly operational with AMD CPUs. So at this point, the CPUs of all three of the largest global CPU vendors \u2014 AMD, ARM, and Intel \u2014 are susceptible to both Meltdown and Spectre. Well, at least to some of the variations from both these families.<\/p>\n

Happily, a good part of all of the numerous versions works with none of them \u2014 not ARM, nor AMD, nor Intel \u2014 or, at least, testers were unable to make them work. Yet most of them do work at least somewhere.<\/p>\n

Companies began to release patches<\/a> for CPU microcodes, operating systems, and individual programs back in January 2018, looking to put a stop to these nuisances. Unfortunately, Spectre and Meltdown are hardware vulnerabilities; they exist at the hardware level, so they can\u2019t be cured completely with software patches.<\/p>\n

Thus, one of the patches was implemented inside the Linux OS core, but it was slowing the system down too much, so after a while it was removed from the code.<\/p>\n

Spectre is problematic because it targets different microarchitecture components, so a separate patch has to be designed for each one. And each one of the patches will require certain functions to be deactivated or certain extra actions performed, and therefore will further downgrade performance.<\/p>\n

In fact, patches affect performance so severely in many cases that a patched system works slower than one in which the vulnerable CPU components are turned off altogether.<\/p>\n

\"Funny<\/a>

Radical solution \u2014 removing the vulnerable part of the CPU by drilling out where indicated<\/a> (it\u2019s a joke, you know)<\/p><\/div>\n

The future of Spectre and Meltdown<\/h3>\n

In October 2018, Intel announced<\/a> that its new CPUs (meaning the generation due to appear in 2019) will feature hardware-level Spectre and Meltdown protection. But this was said about the two \u201cbasic\u201d versions, of which, as we discussed above, there are quite a few more. AMD also plans to patch one of the Spectre variations in its new generation of Zen 2 architecture processors to be released in 2019. ARM, too, promises hardware updates, claiming<\/a> that \u201call its future CPUs will be resilient to Spectre-style attacks.\u201d<\/p>\n

Great news, of course \u2014 for those buying new devices in the future. And those of us who happened to buy a computer, smartphone or other device built around an Intel, AMD, or ARM CPU in 2018 or earlier will have to install patches for pretty much everything, thereby greatly reducing performance. Chances are, some people won\u2019t get around to it.<\/p>\n

CPU manufacturers have ignored hardware-level vulnerabilities for too long, optimizing their CPUs solely for the sake of performance. But all these optimizations have come at a cost: Some things were indeed improved, but others ended up with more problems. Now it will be quite a challenge to get rid of these vulnerabilities, buried as deep as they are. Yet, it must be said, it is not all that easy to exploit such vulnerabilities, and that\u2019s cause for hope \u2014 at least until the next generation CPUs are out.<\/p>\n