Chances are you’ve owned or worked with a computer that has had some kind of Intel processor in it from 1995 to now. Countless servers and phones also use these processors, so it’s safe to say they’re a fairly commonly-used computer part globally. It was revealed by security researchers that there is a flaw in the kernel used in these processors that affects both Windows and Linux/UNIX systems. This flaw is known as two separate exploits, Meltdown and Spectre.
The vulnerability explained
Something that the system kernel typically does is what’s called kernel address space layout randomization (KASLR). This causes the kernel to choose random spaces in memory to store and execute code. It’s a defense mechanism built into the kernel so that there is no single point of failure or location in the kernel’s memory space for known exploits to be found by an attacker. This vulnerability in Intel chips could potentially allow for KASLR to be disabled, making it easier to find anything in memory space as it’s no longer randomized.
The vulnerability takes advantage of the modern architecture of pipelined processors. Using what’s called speculative execution of branch instructions, the processor tries to predict the path of execution for a program’s branch instructions based on the history of previous branch instructions from that same program. It does this to improve performance and use of system resources and thus be able to determine if it should queue up instructions ahead of the current branch with the assumption that they will be executed soon.
The way Meltdown and Spectre take advantage of this is one of three ways.
Eager execution tries to speculatively execute both sides of the branch instructions and the results are only committed to be executed if the predicate is true. The other two ways of execution are predictive and lazy. Predictive attempts to predict the outcome, and if the prediction is true, the branch instructions are executed. Lazy execution does not use speculation and is still a concept being researched. You can find more detailed information on the speculative execution Wikipedia page.
Details on the current patch
The patch that has come out moves the kernel into a different separate address space so that it’s beyond being invisible to a process, it simply isn’t really there at all. The result of this however is a heavy expense in system resources and thus a noticeable downgrade in hardware performance and a reduction in speed of your processors performance. An example given by researchers at The Register showed PostgreSQL SELECT 1 after being patched with the KPTI work around showed performance drops ranging from 17-23%. More details can be found over at PostgreSQL’s blog on the tests.
The performance degradations being tested, however, are worst-case, and in testing, most real-world workloads are 1-2% degradation or less. There’s been a lot of discussion that announcements need to de-emphasize the artificial worst-case 20-40% slowdowns because these won’t occur in real-world workloads and are more likely to scare people off from patching than actually be useful.
Patching your system
As of right now, to patch your systems, the easiest way on Linux is to run either an apt-get update or yum update and then restart your servers. Windows already released a patch so be sure to check for updates on your windows work stations and OS X 10.13.2 has the fix implemented as well. To avoid hardware performance problems, you may be required to replace the processor with a newer processor. And although yes, this vulnerability exists, there have been no reported cases of actual attacks in the wild because there are generally layers of security that make it difficult, if not impossible, to actually exploit.
Please also refer to this incredibly detailed blog post from the researchers of Google’s Project Zero as it can provide a much more technical and comprehensive look into the mechanics of this issue.
We also offer a way of identifying Spectre variant 1 in your code base, using Klocwork static code analysis. The Klocwork SPECTRE.VARIANT1 checker flags any possible instances of the exploit in your C/C++ code – this blog offers a detailed explanation of how it works.