ZombieLoad And Other Things That Go Bump In The Night

May 14, 2019 may not have seemed a particularly important date for those who edit and color grade on Mac’s and PC’s. But it was. By chance, that day I went looking for the May Windows 10 Feature Update (1903). I was surprised to find a scary warning about something I had never heard of: MDS.

MDS stands for Microarchitecture Data Sampling. MDS is a way of stealing from computer systems, data the computer owner does not want made public. Such information includes passwords for the infected computer, as well as other private information. Figures 1 and 2 show the alert with information that caught my eye.

Figure 1: First Portion of “MDS” Alert.

Figure 1: First Portion of “MDS” Alert.

Figure 2: Second Portion of “MDS” Alert.

Figure 2: Second Portion of “MDS” Alert.

The word “vulnerabilities” got my attention. Vulnerability means while assaults have been made on microprocessors in laboratories, no known user computers have been attacked. Which suggests you presently have nothing to fear.

Nevertheless, the alert continued with the phrase “… what you should do to protect yourself.”

I realized I had to learn about RIDL (Rogue In-Flight Data Load), Fallout, and Zombieload. Anything with “Zombie” in its name can’t be good for your computer.

Noting the alert only mentioned Intel microprocessors, I checked the AMD security website (https://www.amd.com/en/corporate/product-security) where I learned AMD does not believe its microprocessors are vulnerable.  My next step was to check the May 14, 2019 “Intel MDS page.” See Figure 3.

Figure 3: Intel Side Channel Vulnerability Microarchitectural Data Sampling Overview.

Figure 3: Intel Side Channel Vulnerability Microarchitectural Data Sampling Overview.

The full impact of the alert hit me when I realized Intel microprocessors, prior to select 8th and 9th Generation chips, were vulnerable. That’s most of the world’s microprocessors! (According to reports, early builds of 8th and 9th Generation chips may also be vulnerable.) See figure 4.

Figure 4: Intel Generational Microarchitecture.

Figure 4: Intel Generational Microarchitecture.

Because these vulnerabilities affect so many Intel microprocessors, it means computers running MacOS, Linux, as well as Windows are all vulnerable. No wonder this alert has an “Industry-wide” scope.

To be safe from these vulnerabilities you need to check with your computer vendor to see if you need to install any required BIOS updates. Then, appropriately update your computer’s operating system.  If you are a Mac user, upgrade or update, to 10.14.6 (Mojave).

Windows 10 users should install the May 2019 Windows 1903 Feature Update. Windows users should also regularly check for BIOS updates and should allow “Patch Tuesday” updates. To be safe from bugs sometimes introduced by updates, set a 2-week update delay.

Of course, we know many, if not most, computer owners do not update their computers. Should these vulnerabilities become active threats, all non-updated systems are at risk.

Unfortunately, updating as recommended may cause your programs to run very slightly slower. This is the cost of protection from RIDL and Fallout. Intel, however, states updating does not provide full protection from Zombieload. (See text in Figure 2’s blue box.)

Speculative Branches

In the modern microprocessor world, MDS involves what is called Speculative Execution. One example of speculative execution: Speculative Branches. A computer’s branch instruction makes a comparison between two items that yields, for example, an EQUAL or a NOT EQUAL result.

Modern microprocessors have the ability to look at code (light blue) immediately preceding a branch instruction (dark blue block) and compare it to past branch instruction code that has led to a correct speculation (Figure 5).

Figure 5: Speculative Branch—code before the branch instruction is examined to predict whether code (yellow) in the upper or lower path should be executed.

Figure 5: Speculative Branch—code before the branch instruction is examined to predict whether code (yellow) in the upper or lower path should be executed.

Figure 6 shows the CPU has bet on the lower path based upon historical analysis.

Figure 6: Speculative Prediction—based on code (light blue) that previously has led to a correct prediction, the lower branch is selected for execution. The upper path code (orange) is not discarded.

Figure 6: Speculative Prediction—based on code (light blue) that previously has led to a correct prediction, the lower branch is selected for execution. The upper path code (orange) is not discarded.

The microprocessor now executes the code before the branch instruction simultaneously (in parallel) with the code in the lower path (Figure 7). The branch instruction ultimately is executed and the program’s code following the branch instruction is then executed. A speculation, when it is correct, saves execution time (short pink bar) thereby making a microprocessor faster.

Figure 7: Correct Speculation—The microprocessor executes the code in the lower path simultaneously (in parallel) with the code before the branch instruction. The upper branch code (red) is discarded.

Figure 7: Correct Speculation—The microprocessor executes the code in the lower path simultaneously (in parallel) with the code before the branch instruction. The upper branch code (red) is discarded.

Figure 8 shows how a speculation error causes the alternate (upper) path code to be executed thereby adding time to the speculative branch (longer pink bar).

Figure 8: Speculation Error—the lower instruction branch was executed as history predicted this was the correct choice. This prediction was wrong. Thus, the upper branch is executed immediately after the branch instruction.

Figure 8: Speculation Error—the lower instruction branch was executed as history predicted this was the correct choice. This prediction was wrong. Thus, the upper branch is executed immediately after the branch instruction.

Overtime, the microprocessor learns the most likely correct speculation. In future, more often than not, the correct branch is chosen so the correct code is simultaneously executed thus saving time as is shown by Figure 7.

My Speculation on How MDS Works

I’m not able to explain how MDS works because, despite programming for over 50-years, these attacks aren’t based upon understanding microprocessor architecture. An understanding of MDS requires a profound knowledge of microprocessor microarchitecture.

Microarchitecture is the deep and sometimes undocumented logic which executes microcode that determines how each CPU instruction is executed. It’s the code you never see that runs on a chip’s hardware you typically don’t know exits.

By study and experimentation, researchers are exploring this micro-world to learn the ways in which a microprocessor’s microarchitecture and microcode can result in “data leakage.”

Attacks, called exploits, make use of micro-structures within a microprocessor’s cache memory. Cache is a relatively small amount of super-fast memory in a microprocessor that stores instructions and data.

Each program is allotted its own private cache memory called User Cache. Kernel Cache is private cache memory allocated for the Operating System.

Ideally cache logic obtains instructions and data from a computer’s virtual memory before a microprocessor needs them. This prevents a microprocessor from stalling while waiting for instructions or data. Data generated by a microprocessor are written to cache where the cache logic writes them to a computer’s virtual memory.

Within the cache there are many complex micro-structures: the Fill Buffer, the Store Buffer, and Load Ports. RIDL exploits the Fill Buffer while Fallout exploits the cache Store Buffer.

Here’s a link to relatively brief explanation of MDS:https://www.redhat.com/en/blog/understanding-mds-vulnerability-what-it-why-it-works-and-how-mitigate-it.

Because our computing future will be threatened by a continuing stream of exploits, I have created a hopefully understandable, but wholly inaccurate explanation of MDS. Its purpose is to provide a sense of how cache exploits work and how they are mitigated.

Programming a Speculative Branch

Speculative branching assumes past branch decisions have a high probability of predicting the best current branch. Figure 9 shows a speculation (bet) has been made on the lower (green) code.

Figure 9: Speculation—a bet has been made on the lower (green) code.

Figure 9: Speculation—a bet has been made on the lower (green) code.

Data (results) generated by the lower (green) path are stored in Kernel cache. When the branch instruction is executed, its choice is compared to the prediction. When both choice and prediction match, data are moved from the Kernel cache to User cache, and hence, to variables in the program’s memory.

Upon a speculation error, the contents of the Kernel are ignored. Eventually the Kernel cache becomes full and these data are overwritten.

Figure 10: Speculation Error—the work of the lower path has been “rolled back.” The alternate code (upper branch) is now executed.

Figure 10: Speculation Error—the work of the lower path has been “rolled back.” The alternate code (upper branch) is now executed.

Figure 10 shows that from a programmer’s viewpoint the work of the lower path has been “rolled back.” Programmer attention now turns to the execution of the alternate code where again data (results) are saved in Kernel cache. Only when the branch is finished are these data moved to User cache and hence to RAM.

A Speculative Branch Exploit

An exploit involves malicious information inserted into a computer system. For example, by modifying speculative branch historical data, speculation errors can be forced. The malicious coder understands that data generated prior to a speculation error remain in Kernel cache. A second malicious process samples the Kernel cache.

However, it’s not simple to steal specific information from Kernel cache. Therefore, the second malicious code statistically samples the cache, for example, to get data that has a ###-##-#### pattern which might represent a Social Security number. The repeated sampling is why the exploit is called Microarchitecture Data Sampling.

MDS Mitigation

To mitigate MDS, the operating system (and possibly the BIOS) must be updated to perform a cache flush of the relevant portion of Kernel cache after a speculation error. Of course, this mitigation adds execution time to programs thus reducing computer performance. See Figure 11.

Figure 11: MDS Mitigation Performance Loss Reported by Intel.

Figure 11: MDS Mitigation Performance Loss Reported by Intel.

To check Intel’s estimates, I ran the Cinebench R20 benchmark on my computer. (https://www.maxon.net/en/support/downloads).  Then I installed the Microsoft 1903 Feature Update. See Figure 12.

Figure 12: Windows 1903 Feature Update.

Figure 12: Windows 1903 Feature Update.

Figure 13 shows the Cinebench Release 20 benchmark.

Figure 13: Cinebench R20—eight orange boxes show 8-threads from a 4-core microprocessor drawing eight portions of the whole image. Each box draws its portion of the image.

Figure 13: Cinebench R20—eight orange boxes show 8-threads from a 4-core microprocessor drawing eight portions of the whole image. Each box draws its portion of the image.

After the update to 1903, the Cinebench R20 benchmark ran about a 3-percent slower. A result which matches the average mitigation performance loss reported by others.

Some confusion does remain. In May, Intel published a performance chart, Figure 14, showing the performance loss from disabling Hyper-Threading (HT). Intel stated, “To be fully protected, customers may also need to disable Hyper-Threading…” (https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/adv190013).

Figure 14: Intel’s Reported Pre- and Post-mitigation ZombieLoad Results.

Figure 14: Intel’s Reported Pre- and Post-mitigation ZombieLoad Results.

These Intel comments refer to the ZombieLoad exploit which takes advantage of two threads running on the same core. Two threads executing on the same core share the same cache.

Zombieload attaches a malicious thread to a core whose other thread is processing private data. The ZombieLoad thread, via the shared cache, samples data from the other thread. The simplest way to mitigate ZombieLoad is to disable Hyper-Threading.

So, the open question is who needs to be fully protected (possibly only Virtual Machines running on public servers). Intel’s HT chart shows about a 10-percent slowdown. Other reports indicate disabling Hyper-Threading results in a 25- to 35-percent slowdown.

Another Microsoft note comments on a number of MDS threats: https://support.microsoft.com/en-us/help/4073757/protect-windows-devices-from-speculative-execution-side-channel-attack. This note includes this provocative statement, “Important: These issues will affect other systems such as Android, Chrome, iOS, and MacOS.”

Stay tuned.

Note: Prior to May 2019, Amazon Web Services (AWS), Microsoft Azure, and Google installed mitigations to their web services. Google, it is reported, also disabled Hyper Threading for ChromeOS.

Let us know what you think…

Log-in or Register for free to post comments…

You might also like...

Color and Colorimetry – Part 5

In a multi-disciplinary subject such as color space, it is hard to know where to start. John Watkinson argues that the starting point is less important than the destination.

Esports Expands Audiences Using Broadcast IP Production & Distribution – Part 2 – The IP Technology

Esports viewership worldwide is on a steep upward trajectory and will soon begin to challenge traditional sports broadcast audience figures. As the esports and traditional sports communities converge, what can traditional broadcasters learn from the remote production workflows being pioneered…

What Does PCI 4.0 Offer?

When, in May 2019, AMD announced their Ryzen Zen 2 architecture, beyond the amazing performance offered by the new Series 3000 microprocessors, they announced the new chips would support PCI 4.0. Although I was pretty confident the step from 3.0 to 4.0 meant 2X greater bandwidth,…

Esports Expands Audiences Using Broadcast IP Production & Distribution – Part 1 – The Business Case

Esports viewership worldwide is on a steep upward trajectory and will soon begin to challenge traditional sports broadcast audience figures. As the esports and traditional sports communities converge, what can traditional broadcasters learn from the remote production workflows being pioneered…

Shooting HDR: A More Efficient Way

As High Dynamic Range (HDR) and Wide Color Gamut (i.e.BT.2020) are increasingly mandated by major industry players like Netflix and Amazon, DOPs in the broadcast realm are under intense pressure to get it right during original image capture.…