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.

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.

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.

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 6 shows the CPU has bet on the lower path based upon historical analysis.

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 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).

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.

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 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.

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 13 shows the Cinebench Release 20 benchmark.

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).

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.