New speculative execution bug leaks data from Intel chips’ internal buffers

First disclosed in January 2018, the Meltdown and Spectre attacks have opened the floodgates, leading to extensive research into the speculative execution hardware found in modern processors, and a number of additional attacks have been published in the months since.

Today sees the publication of a range of closely related flaws named variously RIDL, Fallout, ZombieLoad, or Microarchitectural Data Sampling. The many names are a consequence of the several groups that discovered the different flaws. From the computer science department of Vrije Universiteit Amsterdam and Helmholtz Center for Information Security, we have "Rogue In-Flight Data Load." From a team spanning Graz University of Technology, the University of Michigan, Worcester Polytechnic Institute, and KU Leuven, we have "Fallout." From Graz University of Technology, Worcester Polytechnic Institute, and KU Leuven, we have "ZombieLoad," and from Graz University of Technology, we have "Store-to-Leak Forwarding."

Intel is using the name "Microarchitectural Data Sampling" (MDS), and that's the name that arguably gives the most insight into the problem. The issues were independently discovered by both Intel and the various other groups, with the first notification to the chip company occurring in June last year.

A recap: Processors guess a lot

All of the attacks follow a common set of principles. Each processor has an architectural behavior (the documented behavior that describes how the instructions work and that programmers depend on to write their programs) and a microarchitectural behavior (the way an actual implementation of the architecture behaves). These can diverge in subtle ways. For example, architecturally, a processor performs each instruction sequentially, one by one, waiting for all the operands of an instruction to be known before executing that instruction. A program that loads a value from a particular address in memory will wait until the address is known before trying to perform the load and then wait for the load to finish before using the value.

Microarchitecturally, however, the processor might try to speculatively guess at the address so that it can start loading the value from memory (which is slow) or it might guess that the load will retrieve a particular value. It will typically use a value from the cache or translation lookaside buffer to form this guess. If the processor guesses wrong, it will ignore the guessed-at value and perform the load again, this time with the correct address. The architecturally defined behavior is thus preserved, as if the processor always waited for values before using them.

But that faulty guess will disturb other parts of the processor; the main approach is to modify the cache in a way that depends on the guessed value. This modification causes subtle timing differences (because it's faster to read data that's already in cache than data that isn't) that an attacker can measure. From these measurements, the attacker can infer the guessed value, which is to say that the attacker can infer the value that was in cache. That value can be sensitive and of value to the attacker.

Buffering...

MDS is broadly similar, but instead of leaking values from cache, it leaks values from various buffers within the processor. The processor has a number of specialized buffers that it uses for moving data around internally. For example, line fill buffers (LFB) are used to load data into the level 1 cache. When the processor reads from main memory, it first checks the level 1 data cache to see if it already knows the value. If it doesn't, it sends a request to main memory to retrieve the value. That value is placed into an LFB before being written to the cache. Similarly, when writing values to main memory, they're placed temporarily in store buffers. Through a process called store-to-load forwarding, the store buffer can also be used to service memory reads. And finally, there are structures called load ports, which are used to copy data from memory to a register.

All three buffers can hold stale data: a line fill buffer will hold data from a previous fetch from main memory while waiting for the new fetch to finish; a store buffer can contain a mix of data from different store operations (and hence, can forward a mix of new and old data to a load buffer); and a load port similarly can contain old data while waiting for the new data from memory.

Just as the previous speculative execution attacks would use a stale value in cache, the new MDS attacks perform speculation based on a stale value from one of these buffers. All three of the buffer types can be used in such attacks, with the exact buffer depending on the precise attack code.

The "sampling" in the name is because of the complexities of this kind of attack. The attacker has very little control over what's in these buffers. The store buffer, for example, can contain stale data from different store operations, so while some of it might be of interest to an attacker, it can be mixed with other irrelevant data. To get usable data, many, many attempts have to be made at leaking information, so it must be sampled many times.

On the other hand, the attacks, like the Meltdown and Foreshadow attacks, bypass the processor's internal security domains. For example, a user mode process can see data leaked from the kernel, or an insecure process can see data leaked from inside a secure SGX enclave. As with previous similar attacks, the use of hyperthreading, where both an attacker thread and a victim thread run on the same physical core, can increase the ease of exploitation.

Limited applicability

Generally, an attacker has little or no control over these buffers; there's no easy way to force the buffers to contain sensitive information, so there's no guarantee that the leaked data will be useful. The VU Amsterdam researchers have shown a proof-of-concept attack wherein a browser is able to read the shadowed password file of a Linux system. However, to make this attack work, the victim system is made to run the passwd command over and over, ensuring that there's a high probability that the contents of the file will be in one of the buffers. Intel accordingly believes the attacks to be low or medium risk.

That doesn't mean that they've gone unfixed, however. Today a microcode update for Sandy Bridge through first-generation Coffee Lake and Whiskey Lake chips will ship. In conjunction with suitable software support, operating systems will be able to forcibly flush the various buffers to ensure that they're devoid of sensitive data. First-generation Coffee Lake and Whiskey Lake processors are already immune to MDS using the load fill buffers, as this happened to be fixed as part of the remediation for the level 1 terminal fault and Meltdown attacks. Moreover, the very latest Coffee Lake, Whiskey Lake, and Cascade Lake processors include complete hardware fixes for all three variants.

For systems dependent on microcode fixes, Intel says that the performance overhead will typically be under three percent but, under certain unfavorable workloads, could be somewhat higher. The company has also offered an official statement:

Microarchitectural Data Sampling (MDS) is already addressed at the hardware level in many of our recent 8th and 9th Generation Intel® Core™ processors, as well as the 2nd Generation Intel® Xeon® Scalable Processor Family. For other affected products, mitigation is available through microcode updates, coupled with corresponding updates to operating system and hypervisor software that are available starting today. We've provided more information on our website and continue to encourage everyone to keep their systems up to date, as it's one of the best ways to stay protected. We'd like to extend our thanks to the researchers who worked with us and our industry partners for their contributions to the coordinated disclosure of these issues.

Like Meltdown, this issue does appear to be Intel-specific. The use of stale data from the buffers to perform speculative execution lies somewhere between a performance improvement and an ease-of-implementation issue, and neither AMD's chips nor ARM's designs are believed to suffer the same problem. Architecturally, the Intel processors all do the right thing—they do trap and roll back faulty speculations, as they should, as if the bad data was never used—but as Meltdown and Spectre have made very clear, that's not enough to ensure the processor operates safely.

Listing image by Marina Minkin