No poetry today. Instead, a reminder to update your computing devices and to keep abreast of any upcoming operating system patches. Nearly every computer in use has at least one of two security flaws in today’s news headlines. Apple has patches at least one of the problems and expect Microsoft and the Linux teams to offer patches today (4 Jan 2018) or tomorrow.
Computers and most computing devices are, to one degree or another, insecure. In some ways, they are insecure in the same way a briefcase of folder is insecure: you might lose the briefcase, it might be stolen, or you might leave it unattended long enough for someone to browse through documents. In other ways, computing devices are insecure much as living in an apartment with thin walls or working in a cubicle is insecure: your words can be heard by anyone making a bit of effort.
The latest CPU insecurities remind us that computers are different, too. They have vulnerabilities a locked briefcase in your office, behind a locked door, would not have. Computers send and receive data constantly, and those bits and bytes are rarely secured from prying hackers.
The Meltdown and Spectre CPU vulnerabilities are highly technical. They come down to a simple issue, however: speed. To improve the performance of operating systems and software CPUs have long relied on caching. A cache keeps a copy of data close to the CPU, usually in a block of RAM on the same physical die. Your computer’s CPU cache improves overall performance by as much as 30 percent, keeping data and maps to other chunks of data on hand. RAM on a motherboard is relatively slow. Cache is fast. Even keeping maps to data offers a performance gain.
I’m oversimplifying a lot, but think of it this way: you memorize what you need to know constantly and memorize how to find data you might need occasionally. You computer does something similar. The “brain” of the computer keeps essential information in the cache, including tables of where to find other data.
Now, add in speculation. That’s the attempt by a CPU to anticipate which data software might need and which instructions might need to be executed. Speculation is like working ahead based on familiarity with a client or boss. Sure, you’re correct most of the time, but you could guess wrong and end up needing to do something else. At least a computer doesn’t grumble if it has speculated incorrectly.
All this storing what a computer might need and doing what might need to be done is great for speed. Not so great for security.
That cache memory on the CPU is only secure after the CPU determines data should be off-limits to user software. Until the CPU secures the data, usually by command of the operating system, the cache data are open to being read by malicious applications. Other manipulations might be possible, too.
“Meltdown” and “Spectre”: Every modern processor has unfixable security flaws | Ars Technica:
Meltdown
The first problem, Meltdown, is the one that stimulated the flurry of operating system patches. It uses speculative execution to leak kernel data to regular user programs.Enlarge / Meltdown
Our original coverage gave a high-level summary of how operating systems virtualize system memory, the use of page tables to map from virtual memory addresses to physical addresses, how processors cache those mappings, and how the kernel’s page table mapping is shared between processes in order to maximize the value of this special cache.While all modern processors, including those from Intel, AMD, and ARM, perform speculation around memory accesses, Intel’s processors do so in a particularly aggressive way. Operating system memory has associated metadata that determines whether it can be accessed from user programs or is restricted to access from the kernel (again: our original coverage has more detail about this point). Intel chips allow user programs to speculatively use kernel data, and the access check (to see if the kernel memory is accessible to a user program) happens some time after the instruction starts executing. The speculative execution is properly blocked, but the impact that speculation has on the processor’s cache can be measured. With careful timing, this can be used to infer the values stored in kernel memory.
The researchers say they haven’t been able to perform the same kind of kernel memory-based speculation on AMD or ARM processors, though they hold out some hope that some way of using this speculation offensively will be developed. While AMD has stated specifically that its chips don’t speculate around kernel addresses in this way, ARM has said that some of its designs may be vulnerable, and ARM employees have contributed patches to Linux to protect against Meltdown.
Basically, Intel makes fast computer CPUs faster through aggressive cache use and speculative code execution. In theory, that’s fine when your computer isn’t accessible to potential malware or viruses. Before we were all connected, it was definitely a fine way to design computer CPUs.
The challenge is, today we run all manner of software from the Internet. We invite new applications into memory with every website we visit.
Now, on to the Spectre threat, and not in the James Bond universe.
Spectre
Owners of AMD and ARM systems shouldn’t rest easy, though, and that’s thanks to Spectre. Spectre is a more general attack, based on a wider range of speculative execution features. The paper describes using speculation around, for example, array bounds checks and branches instructions to leak information, with proof-of-concept attacks being successful on AMD, ARM, and Intel systems. Spectre attacks can be used both to leak information from the kernel to user programs, but also from virtualization hypervisors to guest systems.Moreover, Spectre doesn’t offer any straightforward solution. Speculation is essential to high-performance processors, and while there may be limited ways to block certain kinds of speculative execution, general techniques that will defend against any information leakage due to speculative execution aren’t known.
Sensitive pieces of code could be amended to include “serializing instructions”—instructions that force the processor to wait for all outstanding memory reads and writes to finish (and hence prevent any speculation based on those reads and writes)—that prevent most kinds of speculation from occurring. ARM has introduced just such an instruction in response to Spectre, and x86 processors from Intel and AMD already have several. But these instructions would have to be very carefully placed, with no easy way of identifying the correct placement.
The basic problem is that security comes with a price. To turn off all speculative code execution and data caching would slow computers significantly. If CPUs didn’t employ speculation there would be less risk, but then they’d sit there idling for cycles at a time. The entire point of speculation and caching is to use every CPU cycle to do something that might be useful.
We want everything to be faster. We want security. Compromises never satisfy customers, but that’s what is needed if we want greater security. The technical and theoretical complications of these two flaws will require some time to sort through.