Meltdown and Spectre

maddog's Doghouse

Article from Issue 208/2018

A serious security problem requires your attention.

I was lying in my bed in the early morning of January 3rd, 2018 when a tweet woke me from my sleep; not a tweet from a bird (nor from the president of the United States), but a tweet from a security researcher discussing two rather bad hardware issues with a large number of CPU chips.

These issues, now known as "Meltdown" and "Spectre," have been rocking the computing world for the past couple of days. Unlike many other security exploits, these are not really "fixable" by a simple software patch, are not operating-system specific, and cannot be avoided by telling your mother not to post her password on her computer screen.

Both have to do with modern hardware architecture and an issue called "out-of-order instruction execution," used to speed up the processor. Sometimes this feature is used to fetch instructions on both sides of a branch (both the "true" and the "false" side), so as soon as the condition is known, the instructions are ready to execute. Access to this "pre-fetched" data could allow a carefully crafted user-level program to access kernel memory, and once that happens, any data on the machine is vulnerable to be read, including passwords, security certificates, and so forth.

At first this was painted as a problem mostly or even solely with Intel processors, but as people investigated it was projected that at least some AMD and some ARM processors are affected. AMD has now stated that none of its processors have this problem. It also depends on when the processor was designed (starting in 1965) and what class of processor it is (Intel 64-bit processors seem to be prime culprits), as not all processors perform out-of-order execution.

The bad news is that the more powerful and expensive the processor is (think server systems, high-end desktops, gaming systems, and superior grade notebooks), the more likely it is to have this feature. Cloud server systems are particularly vulnerable, since they typically run lots of applications at one time.

It is conceivable that even applets and web-based applications could trigger this type of exploit, although the Apache Software Foundation (as an example) has taken steps to make sure that Apache based applications cannot exploit this by restricting access to the high-precision timers that can be used for the exploit. Google has also applied these types of fixes to their systems.

As with many security exploits, this was "embargoed" by the security research groups as people scrambled, first to understand the problem and then to find a solution. Eventually, as solutions were found, the problem was "leaked," which resulted in my early morning tweet. Before I wrote anything or contacted anyone, I checked sources for the "leak," and, feeling assured that the information was both true and correct, I sent out messages to other people I knew.

Understand that these are reasonably hard exploits to utilize, and the application trying to exploit them needs to be on the local machine. But in the day of shared cloud servers, the heavy use of containers, and web-based applications, this is not a rare occurrence.

There are now tens of thousands of people in the world who have the expertise to exploit this, and perhaps hundreds who would have the expertise and the desire. With todays Internet, you really only need a few such people.

The Linux kernel has released a patch that stops most of the exploits, and Microsoft and Apple will do the same. By the time you read this, your favorite distribution should have a replacement kernel ready for you.

Lack of detailed information about which processor is in your server, desktop, tablet, or device, and whether that processor is affected by this exploit, will make it harder to determine if you need the patches. This is a problem on two fronts.

Current patches in the Linux kernel (and I assume in other affected operating systems) cause a slowdown. The slowdown occurs because the kernel no longer shares address space with user programs, and this causes overhead for the hardware as the system shifts back and forth between kernel memory and user memory during interrupts and system calls. The percentage of slowdown depends on the programs being executed, and typically heavy I/O programs (such as database engines or network-heavy programs) take the brunt of the slowdown.

You can partially disable these patches by booting with nopti as a kernel boot option if your environment is secure or you are using a processor that is unaffected.

This exploit has roots back to 1995; there are thousands of systems still being used that will not get their kernel updated. Desktops running Microsoft Windows XP (yes, they are still out there), as well as older Apple systems, are just two examples.

Caveat emptor.

The Author

Jon "maddog" Hall is an author, educator, computer scientist, and free software pioneer who has been a passionate advocate for Linux since 1994 when he first met Linus Torvalds and facilitated the port of Linux to a 64-bit system. He serves as president of Linux International®.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

comments powered by Disqus

Direct Download

Read full article as PDF:

Price $2.95