A major security vulnerability affecting all Intel chips released in the past decade has apparently been discovered, and since the chips can’t be updated, developers are getting ready to push out software solutions. The good news is that Microsoft is getting ready to push out a major software update to users, and Linux developers have baked a fix into Linux kernel 4.15.

The bad news is that these fixes are expected to make devices Intel-powered desktop, laptop, and server chips about 5 to 30 percent slower when performing some tasks.

Update: Intel has issued a brief statement on the matter, with more details likely coming next week. The long and short of it is that the company acknowledges and exploit has been discovered and that it’s working with software and hardware companies on a solution, but Intel tries to downplay the severity of the issue (and suggests that not only Intel products are affected). 

Update 2: Yup, it’s not just Intel. AMD and ARM chips are also affected by some, but not necessarily all of the vulnerabilities that affect Intel chips. Google’s Project Zero discovered the vulnerabilities, code-named Spectre and Meltdown, and lays out the details in a blog post.

Intel hasn’t officially disclosed the details of the vulnerability yet, and while Linux kernel development is happening out in the open, some of the details of the vulnerability have been redacted to prevent it from being exploited before a patch is in place.

But The Register has pieced together many relevant details and the long and short of it is that it seems to allow software running on a PC to access protected kernel memory without appropriate permission.

A kernel is the core of an operating system that tells the OS how to interact with the CPU, memory, and other hardware. Because it’s such as an important component of the operating system, it has a special, protected area of memory called “kernel space” that’s separate from the “user space” which is what you mostly use when you’re running programs on a PC.

But it looks like the vulnerability could allow software running in user space to access the contents of kernel memory. Among other things, that means if you’re surfing the web you might encounter a website that uses JavaScript to access passwords or other cached data that’s supposed to be isolated and protected in kernel space.

Since this is a chip-level vulnerability, software developers have had to implement a pretty big workaround by completely changing the location of the kernel. Unfortunately, that means it will take longer to complete some tasks.

You can find more details about why the security patch will slow down computers at Python Sweetness and The Register, but some folks are predicting Intel-powered computers could take a performance hit of between 5 and 30 percent. Some technologies added to recent Intel processors could help mitigate that, so it’s possible that chips released in the past few years won’t be affected as much as older models. And not all activities are likely to be slower after the software updates roll out.

Phoronix has already run some benchmarks on systems using the new Linux 4.15 kernel, and finds little change in video gaming performance, video transcoding or Linux kernel compilation tasks, but a big slow-down in PostgreSQL and Redis performance.

We could see a major impact on performance of servers, with Amazon, Microsoft, and Google set to roll out security updates soon.

While we already know that Microsoft and Linux developers are working on patches, it’s likely that Apple will also issue its own update soon, since the company’s desktop and notebook computers also use Intel processors.

Update: It turns out Apple is already on the case. Part of the fix was included in macOS 10.13.2, which was released last month, and the upcoming macOS 10.13.3 should take care of most security issues affected by the vulnerability.

Interestingly, it looks like an upcoming Linux kernel update will also separate the kernel and user spaces for 64-bit ARM processors, suggesting it may not just be Intel chips that are affected by the vulnerability.

AMD notes that it’s chips aren’t affected by the same vulnerability, which could be very, very good news for the company now that it’s got a line of Ryzen processors that are within striking distance of their Intel counterparts when it comes to pre-patch performance. It’ll be interesting to see how Ryzen-powered laptops and desktops compare to Intel-powered machines after the security updates are fully rolled out.

For now, Phoronix notes, it looks like Linux kernel 4.15 still treats AMD chips as if they were vulnerable though, so it may be a while before everything shakes out.

It’ll also be interesting to see how long it takes Intel to release new processors that aren’t affected by the vulnerability. Since the company still hasn’t issued any official statements on the matter it’s unclear how long the company has known about the problem, how much work it will take to design it out of future products, and if that work will delay the launch of any chips on the company’s current roadmap.

Support Liliputing

Liliputing's primary sources of revenue are advertising and affiliate links (if you click the "Shop" button at the top of the page and buy something on Amazon, for example, we'll get a small commission).

But there are several ways you can support the site directly even if you're using an ad blocker* and hate online shopping.

Contribute to our Patreon campaign


Contribute via PayPal

* If you are using an ad blocker like uBlock Origin and seeing a pop-up message at the bottom of the screen, we have a guide that may help you disable it.

9 replies on “Most PCs and servers are about to get slower thanks to security updates patching major Intel CPU vulnerability”

  1. I tried to make an explanation for people like me who don’t understand the problem intuitively. This is my understanding, which may be helpful, or unhelpful.

    All modern processors “guess ahead” on instructions from the program. In a process, (Say, Firefox) the process Firefox.exe contains the instructions for Firefox, plus the Kernel. The Kernel instructions are hidden from the program side of Firefox.exe, because the kernel is what interfaces between the hardware (RAM, disk controller, etc) and the software. It’s like God on a cloud. You can ask it to do things, and it will… If you have permission.

    Why guess? These modern processors have a problem: When you ask the processor to do X, the instructions for X are stored somewhere. The CPU can only read what’s in its Cache, but NOT what’s in RAM or on the storage drive. So the CPU-god that is running Firefox has parts of Firefox.exe and also the system kernel loaded into its Cache (Directly accessible storage). It’s like a robot that can know six verbs, including how to look up verbs from its verb library on the desk, Or how to get more volumes from the verb library from the bookshelf.

    Now the trick is, since it takes several processor cycles to get an instruction, look it up, and do it… Modern CPU-gods guess. “OK, they picked up bread, and peanut butter, and let’s pre-calculate peanut butter spread on bread, AND peanut butter plus jelly on bread to save time. OK, they wanted peanut butter and jelly. Here it is! Throw out the PB and bread.”

    The design embodied in this guessing is highly linked to computer performance especially on hypervisor programs like the Amazon Cloud system. Now, these guesses are time-savers. But there are some programs that aren’t allowed to, say, access the piece of RAM that also stores your saved password being used to login at your bank web site.

    Now the problem: What if Intel’s instruction-guesser carried out instructions, saved the results to its cache as part of the branch-prediction, and… hadn’t authenticated whether you were allowed to do that actual instruction? It doesn’t. So if I can guess how to fake it out into performing operations my program isn’t allowed to, AND I can also guess where it saves those results, then I can do this and then steal them.

    This has been successfully done by people unrelated to the feverish, secret programming teams doing open-heart surgery for each operating system kernel right now. These other programmers are posting screenshots on Twitter showing that they have compromised this link in practice: Javascript programs accessing predictive branch program outputs that ran without authentication.

    Certain people (Amazon, Google) subscribed to these kernel fix mailing lists are highly invested in doing so securely! And AMD has already pointed out that they don’t have this problem. Intel can’t quickly redevelop the branch prediction stuff. Branch prediction is like voodoo. Somehow the prediction software fits in the cache, and saves enough lookup time (The slow part) to be worth the space.

    Instead of replacing every Intel CPU produced for the past decades, kernel programming teams will put all Kernel code in a different place completely* outside of the reach of programs. *Completely means I hope!

    But now the poor CPU cache has to discard the Firefox.exe lookup tables, and pull up the kernel.exe lookup tables every time it hands hardware control from kernel to software. That is 5-30% slower on tasks Amazon likes to do. Every hypervisor they made to simulate a “As capable as ___Xeon E5-whatever____ system” is now about 20% under spec, since it’s all hypervisor-related. This is like having thousands of cars that don’t quite fit families, or thousands of pre-made meals that aren’t quite enough to feed people.

  2. The most interesting thing is that Intel CEO sold as many shares as possible on Nov 29th [1]… now we know about this. Conspiracy theory or not, it doesn’t look good!.

    The main problem that we may face in the coming days are all the server/vm/switch/gateway/router restarts that will be needed to deploy all of those software patches… things will be very problematic for some time.

    At least it seems (from the benchmarks) that most user applications won’t be affected…

    [1] https://www.fool.com/investing/2017/12/19/intels-ceo-just-sold-a-lot-of-stock.aspx

  3. “Linux kernel 4.15 still treats AMD chips as if they were vulnerable “. It’s good to get the patch into the kernel early, but this is BS. There has to be a secure way to identify affected chips and use the slower code.

      1. if (c->x86_vendor != X86_VENDOR_AMD)
        + setup_force_cpu_bug(X86_BUG_CPU_INSECURE);

        Not sure if this patch will go mainstream… looks hilarious. The patch submitter works for AMD by the way (Tom Lendacky).

Comments are closed.