MDS: Microarchitectural Data Sampling

Attacks on the newly-disclosed "MDS" hardware vulnerabilities in Intel CPUs

New (Jun 9, 2020): CrossTalk (SRBDS) now public (see also paper)

Update (Mar 10, 2020): LVI and Snoop now public

Update (Jan 27, 2020): L1DES and VRS now public (see also addendum 2)

Update (Nov 12, 2019): TAA and other RIDL issues now public (see also addendum 1)

The RIDL and Fallout speculative execution attacks allow attackers to leak private data across arbitrary security boundaries on a victim system, for instance compromising data held in the cloud or leaking your data to malicious websites. Our attacks leak data by exploiting the 4 newly disclosed Microarchitectural Data Sampling (or MDS) side-channel vulnerabilities in Intel CPUs. Unlike existing attacks, our attacks can leak arbitrary in-flight data from CPU-internal buffers (Line Fill Buffers, Load Ports, Store Buffers), including data never stored in CPU caches. We show that existing defenses against speculative execution attacks are inadequate, and in some cases actually make things worse. Attackers can use our attacks to leak sensitive data despite mitigations, due to vulnerabilities deep inside Intel CPUs.

RIDL

RIDL (Rogue In-Flight Data Load) shows attackers can exploit MDS vulnerabilities to mount practical attacks and leak sensitive data in real-world settings. By analyzing the impact on the CPU pipeline, we developed a variety of practical exploits leaking in-flight data from different internal CPU buffers (such as Line-Fill Buffers and Load Ports), used by the CPU while loading or storing data from memory.

We show that attackers who can run unprivileged code on machines with recent Intel CPUs - whether using shared cloud computing resources, or using JavaScript on a malicious website or advertisement - can steal data from other programs running on the same machine, across any security boundary: other applications, the operating system kernel, other VMs (e.g., in the cloud), or even secure (SGX) enclaves.

We presented our paper titled RIDL: Rogue In-Flight Data Load on these attacks at the 40th IEEE Symposium on Security and Privacy, on May 20th 2019.

VUSec logo             CISPA logo

 Paper  Cite  Slides  Code

Fallout

Fallout demonstrates that attackers can leak data from Store Buffers, which are used every time a CPU pipeline needs to store any data. Making things worse, an unprivileged attacker can then later pick which data they leak from the CPU's Store Buffer.

We show that Fallout can be used to break Kernel Address Space Layout Randomization (KASLR), as well as to leak sensitive data written to memory by the operating system kernel.

Ironically, the recent hardware countermeasures introduced by Intel in recent Coffee Lake Refresh i9 CPUs to prevent Meltdown make them more vulnerable to Fallout, compared to older generation hardware.

We presented our paper titled Fallout: Leaking Data on Meltdown-resistant CPUs at the 26th ACM Conference on Computer and Communications Security, on November 13th 2019.

 Paper  Cite

People

RIDL attacks were independently discovered and reported by:

Fallout attacks were independently discovered and reported by:

MDS-class vulnerabilities were also reported by (in alphabetical order):

Overview

Our attacks can leak confidential data across arbitrary security boundaries in real-world settings (cloud, browsers, etc.). The reason our attacks are impervious to all the existing defenses against speculative execution attacks is that they can leak in-flight data. Unlike other recent attacks such as Spectre, Meltdown, and Foreshadow which are based on vulnerabilities leaking data from the CPU caches, RIDL and Fallout collect data from internal CPU buffers (Line Fill Buffers, Load Ports, Store Buffers). Intel describes the exploited vulnerabilities as "Microarchitectural Data Sampling" (MDS) - where "sampling" is another way of saying that we can leak in-flight (or "sampled") data from many of these microarchitectural buffers. A total of 5 CVEs were assigned by Intel for RIDL ([MFBDS] CVE-2018-12130, [MLPDS] CVE-2018-12127, [MDSUM] CVE-2019-11091, [TAA] CVE-2019-11135) and Fallout ([MSBDS] CVE-2018-12126) exploits. Additional RIDL variants were later assigned 2 CVEs ([L1DES] CVE-2020-0549, [VRS] CVE-2020-0548).

Most importantly, our research shows that what last year appeared to be exceptional one-time speculative execution bugs are actually systemic, and the problems in modern CPUs may go much deeper than we initially thought. If CPUs have become so complex that chip vendors cannot keep their security under control, hardware vulnerabilities will be the new hunting ground for sophisticated attackers. And we may have no idea how many zero-day hardware vulnerabilities are still up for grabs. If we can no longer trust our hardware, the foundation on which we build all security solutions is crumbling away.

Exploit demos

Check out three RIDL exploits in action, leaking the root password hash from an unprivileged user, sensitive data from the Linux OS kernel, and JavaScript.

In this video, we leak the /etc/shadow file by repeatedly trying to authenticate a user. Using our latest RIDL-TAA exploit, we can leak the full root password hash from /etc/shadow in only 4 seconds.
In this video, we show how to leak recent kernel data using RIDL. This demo first reads 0 bytes from /proc/version, whereafter we are able to leak the full contents of /proc/version without the data ever present in userspace.
We leak a string from another process using Javascript and WebAssembly in the SpiderMonkey engine.

Interactive guide to speculative execution attacks

image/svg+xml

Click on the various components to interact with them. The full interactive version can be found here and the raw SVG can be found here. There is also a more vibrant colored version (the one used in our paper), which can be found here. These diagrams have been made by Stephan van Schaik ( @themadstephan).

RIDL Test Suite and PoCs

Verify whether your system is vulnerable today with our MDS tool or have a look at the source code of our PoCs!

MDS Tool
Windows
Linux
Mac OS X
Github

Besides the MDS Tool, we have now released a test suite containing a number of different PoCs that we developed. This test suite can be found on Github.

FAQ

Very likely. Our attacks affect all modern Intel CPUs in servers, desktops and laptops. This includes the latest 9th-generation processors, despite their in-silicon mitigations for Meltdown. Ironically, 9th-generation CPUs are more vulnerable to some of our attacks compared to older generation hardware.

Processors from other vendors (AMD and ARM) do not appear to be affected. Official statements from these vendors can be found in the RIDL and Fallout papers.

Multiple teams and researchers independently discovered, studied, and reported MDS-class vulnerabilities and attacks to Intel. Unfortunately, the different timelines (see below), as well as the fine-grained vulnerability classification and embargo strategy enforced by Intel (which coordinated the disclosure process) made proper coordination across teams difficult. The year-long disclosure process (the longest to date) ultimately resulted in independent finders of even closely related MDS-class vulnerabilities to be completely unaware of one another until very late in the process.

At the same time, VUSec would like to thank Intel for sharing the full list of finders in advance -- which was crucial to give proper credit to everyone involved in the disclosure of MDS vulnerabilities in academia and industry -- and for allowing it to share information with all the other academic finders as of May 1. We made an effort to coordinate the different academic finders and present a unified message to the community and the public.

Unfortunately, as some teams felt unable to share their findings before the May 14 disclosure date, this effort was only partially successful, resulting in the present website (mdsattacks.com) presenting only the two independent RIDL and Fallout papers. See the timeline below for more information.

MDS attacks exploit hardware security flaws deep inside the processor and this makes malware that exploit MDS vulnerabilities very hard to distinguish from benign software. While anti-virus software could theoretically detect MDS exploits, it is very unlikely to happen in practice.

Intel has provided CPU microcode updates, and recommendations for mitigation strategies for operating system (and hypervisor) software. See Intel's Security Advisory for more details. We recommend you install the software updates provided by your operating system and/or hypervisor vendor.

In addition, we recommend disabling Simultaneous Multi-Threading (SMT), also known as Intel® Hyper-Threading Technology, which significantly reduces the impact of MDS-based attacks without the cost of more complex mitigations. Note that you might still be vulnerable despite disabling SMT, as MDS does not strictly rely on the presence of SMT.

A Virtual Machine (VM for short) is a software emulation of the computer's physical hardware. VMs are often used by clouds to allow customers to rent time on the cloud's physical hardware, rather than maintaining their own infrastructure. As clouds often run multiple VMs from different clients on the same physical hardware, it is important that cloud vendors maintain isolation between VM (security) boundaries.

To guarantee even stronger isolation (e.g., with protection against a compromised operating system), cloud providers can also run software inside secure (SGX) enclaves.

As shown in the RIDL paper, an attacker can exploit hardware security vulnerabilities inside the processor to break VM and SGX boundaries. However, countermeasures deployed by cloud providers resulting from our work should make MDS hard to exploit.

The kernel is the operating system core, and as such is responsible for most operations performed by the operating system. In particular, the kernel has access to all the data stored in the machine's memory, and to the secrets in it. As such, it is vital to properly isolate the kernel from other applications running on the machine.

Both the RIDL and Fallout attacks violate the kernel privacy by extracting information from within it. Moreover, both attacks can expose the kernel's location in the system's memory, simplifying other exploits.

RIDL and Fallout are related to, and inspired by, previous speculative execution attacks, including Spectre and Meltdown. In contrast to previous attacks, MDS attacks do not need to make assumptions about the memory layout of the victim data and do not depend on the processor cache.

This makes our attacks very difficult to mitigate. For instance, RIDL's ability to observe data used by other code running on the same physical core (hyperthread) is not trivial to mitigate without disabling the hyperthreading functionality entirely. However, note that both RIDL and Fallout can read recently accessed data across security boundaries even if hyperthreading is disabled.

A detailed analysis of the many existing speculative execution vulnerabilities, their relationship to each other and to RIDL and Fallout, can be found in the RIDL and Fallout papers.

We don't know whether malicious actors have abused these vulnerabilities in the wild. However, RIDL and Fallout show the potential impact is serious with several proof-of-concept exploits. For example, an attacker could launch an attack using malicious JavaScript in a web page or from a co-located Virtual Machine in the cloud (see our exploits and demos), allowing them to leak confidential data present on your system such as passwords and crypto keys.

Yes, similar to existing attacks, attackers can only mount our attacks in practical settings once they have the ability to execute (unprivileged) code on the victim machine. We could convince ourselves this is still an obstacle, but we should first be prepared to disable JavaScript (and similar) in the browser, abandon cloud computing, etc.

Detailed information about these in-flight buffers can be found in the papers above.

As a quick preview, the first diagram below shows the relevant parts of Intel's CPU pipeline and the relationship to the Line Fill Buffers, Load Ports, and Store Buffers used by our attacks. All data read/written from/to memory goes through some of these buffers.

The second diagram shows an example of how we leak data from these buffers. We perform a carefully crafted speculative load to an address the CPU is not immediately prepared to handle (e.g., resulting in a page fault). This lures the CPU into incorrectly pulling in-flight data from the target buffers, and then similarly to other speculative execution attacks, we leak this data using a Flush+Reload attack before the CPU realizes the mistake.

Intel CPU pipeline Attack overview

While performing some experiments on a rainy Amsterdam day, we realized we were able to leak data across security boundaries. We knew we could leak arbitrary in-flight (the "I" in RIDL) data but the cause was initially a big riddle to us. We came to know we were leaking from various CPU buffers only later...

It is also a reference to Intel's formal name for Meltdown: RCDL (related to RIDL, but instead leaking "C"ached data).

Internally, we referred to RIDL (and MDS in general) as the `cat pictures' vulnerability. :)

We started working on Fallout immediately after Meltdown, and Fallouts are typically a direct consequence of Meltdowns.

The following is the fine-grained vulnerability classification adopted by Intel, together with their CVSS score (their rating of the severity of the bug):

CVE-2018-12126: "Microarchitectural Store Buffer Data Sampling (MSBDS)" (CVSS score 6.5: Medium). See the Fallout paper for more information.

CVE-2018-12127: "Microarchitectural Load Port Data Sampling (MLPDS)" (CVSS score 6.5: Medium). See the RIDL paper for more information.

CVE-2018-12130: "Microarchitectural Fill Buffer Data Sampling (MFBDS)" (CVSS score 6.5: Medium). See the RIDL paper for more information.

CVE-2019-11091: "Microarchitectural Data Sampling Uncacheable Memory (MDSUM)" (CVSS score 3.8: Low). See the RIDL paper for more information.

CVE-2019-11135: "TSX Asynchronous Abort (TAA)" (CVSS score 6.5: Medium). See the RIDL paper (with addenda) for more information.

CVE-2020-0549: "L1D Eviction Sampling (L1DES)" (CVSS score 6.5: Medium). See the RIDL paper (with addenda) for more information.

CVE-2020-0548: "Vector Register Sampling (VRS)" (CVSS score 2.8: Low). See the RIDL paper (with addenda) for more information.

CVE-2020-0551: "Load Value Injection (LVI)" (CVSS score 5.6: Medium). See the LVI website for more information.

CVE-2020-0550: "Snoop-assisted L1 Data Sampling (Snoop)" (CVSS score 5.6: Medium). See Intel's Deep Dive for more information.

CVE-2020-0543: "Special Register Buffer Data Sampling (SRBDS)" (CVSS score 6.5: Medium). See the CrossTalk project page for more information.

Not really. And some of the researchers do share your same feelings.

VUSec in particular doesn't really like vulnerability logos. But we do like beer. So here is a MDS-branded one just in case (and yes, VUSec students like to troll their supervisors, who take a hard stance against vulnerability logos...):

MDS beer

Yes, with rights waived via CC0. Logos are designed by Marina Minkin. Click here for the logo in SVG format and here for the logo in PNG format.

MDS rack
Intel patents

Questions about RIDL and MDS vulnerabilities in general can be sent to [email protected].

L1DES and VRS

On Jan 27, 2020, we (VUSec) disclose two "new" RIDL/MDS variants at the end of another (third) embargo, as described in our second RIDL addendum. We do not think either of these variants is particularly novel or interesting and they are simply "more RIDL" (focusing on ways to get data into microarchitectural buffers RIDL can leak from).

  • L1D Eviction Sampling (L1DES).

    The first issue, which Intel refers to as L1D Eviction Sampling (L1DES), is a RIDL variant that leaks from L1D evictions (assigned CVE-2020-0549). It may seem that sometimes history does repeat itself, because this is again something that we had already shown in our original RIDL paper, as shown in Figure 6. In the camera-ready version of the RIDL paper, we also explicitly mentioned that, at every context switch, "the entire L1 cache needs to be flushed first since the entries go through the LFBs" to properly mitigate RIDL. We removed this sentence in the original version of the RIDL paper released on May 14, 2019, since Intel had not yet mitigated the RIDL variant based on L1D evictions (which would eventually become L1DES). Since then, we spent months trying to convince Intel that leaks from L1D evictions were possible and needed to be addressed.

    On Oct 25, 2019, we reported to Intel that this variant would bypass their latest VERW mitigation (and so did a PoC shared with Intel on May 10, 2019), resulting in Intel finally acknowledging the L1D eviction issue and requesting another (L1DES) embargo. We learned that Intel had not found this issue internally and that the only other independent finder was the Zombieload team, which reported a PoC to Intel in May, 2019. The CacheOut team did an independent security analysis of L1DES. Our RIDL-L1DES PoC is available on GitHub.

  • Vector Register Sampling (VRS).

    The second issue, which Intel refers to as Vector Register Sampling (VRS), is a RIDL variant that leaks from vector registers (assigned CVE-2020-0548). This variant shows that RIDL can also leak values that are never even stored in memory. In reality, this is possible with a small, 1-line of code variation of our 'alignment write' PoC (originally leaking values stored in memory using alignment faults), which we shared with Intel on May 11, 2019. Since then, we spent months trying to convince Intel that our 'alignment write' PoC and its variations needed to be properly addressed.

    On Oct 1, 2019, we reported to Intel that a 1-line modification of our 'alignment write' PoC can leak vector register values, resulting in Intel requesting a new (VRS) embargo. We are not aware of other independent finders to acknowledge for VRS. Our RIDL-VRS PoC is available on GitHub.

In other news: RIDL leaks the root passwd hash in a few seconds

Meanwhile, our students have been playing with RIDL last year. As shown below, one of our bright students, Finn de Ridder, built a new RIDL-TAA exploit that can leak the entire root hash password in only 4 seconds (!!!).

Our latest optimized RIDL-TAA exploit can leak the root password hash from the /etc/shadow file on Linux in only 4 seconds.

TAA and other RIDL issues

On Nov 12, 2019, we (VUSec) disclosed TSX Asynchronous Abort (TAA), a new speculation-based vulnerability in Intel CPUs as well as other MDS-related issues, as described in our first RIDL addendum. In reality, this is no new vulnerability. We disclosed TAA (and other issues) as part of our original RIDL submission to Intel in Sep 2018. Unfortunately, the Intel PSIRT team missed our submitted proof-of-concept exploits (PoCs), and as a result, the original MDS mitigations released in May 2019 only partially addressed RIDL. You can read the full story below.

In particular, at the request of Intel, we withheld the following details on the original RIDL/MDS disclosure date:

  • TSX Asynchronous Abort (TAA). Intel's TSX hardware feature can be used to efficiently mount a RIDL attack even on allegedly non-vulnerable CPUs (with hardware mitigations).
  • Alignment faults. These can be used to trigger an exception, giving an attacker yet another way of leaking data. This attack vector seems to be fixed in the latest generation of Intel CPUs.
  • Flawed MDS mitigation. The initial mitigations against MDS clear the buffers by writing stale, potentially sensitive, data into these buffers, allowing an attacker to leak information despite mitigations being enabled.
  • The RIDL test suite. We can now release the RIDL test suite at https://github.com/vusec/ridl.

Impact

TL;DR: an attacker can mount a RIDL attack despite the in-silicon mitigations/microcode patches published in May 2019 being in place.

In particular, TSX Asynchronous Abort (TAA) allowed us to mount a practical RIDL exploit (as already shown in /etc/shadow leak presented in the RIDL paper) even on systems with in-silicon/microcode MDS mitigations enabled. Moreover, one of our brilliant Master students (Jonas Theis) used TAA to optimize our initial password-disclosing exploit to run in just 30 seconds (!!), rather than the initial 24 hours (as seen in the video below).

We leak the full root password hash from the /etc/shadow file on Linux in around 30 seconds using a TAA-optimized RIDL exploit.

Why only release this now?

In short, this was part of our original RIDL submission but was missed by Intel during the first embargo and a new last-minute embargo followed. Check out the updated timeline at the end of the page or keep reading for the full story.

On Sep 29, 2018, we submitted several proof-of-concept exploits (PoCs) for a number of RIDL variants to Intel. Despite our many attempts, we received no technical feedback/questions on our submission except that Intel was working on the mitigations.

In fact, due to a lack of transparency on Intel's part, we only got a complete picture on Intel's MDS disclosure plan on May 10, 2019, just 4 days before public disclosure. We were able to find the microcode updates published by Intel online and tested them on the same day. We quickly found that Intel's fixes did not fully mitigate the vulnerabilities we had reported in Sep 2018 and immediately informed Intel.

On May 13, 2019, just one day from the RIDL/MDS public disclosure date, Intel requested TAA and any other RIDL issues that were not mentioned in the MDS whitepaper to be placed under a new last-minute embargo until Nov 12, 2019. At the request of Intel, and to protect users, we complied to the new embargo, withheld several details from the RIDL paper (leaving only some traces of our results in Table I), and did not release our now public RIDL test suite.

On July 3, 2019, we finally learned that, to our surprise, the Intel PSIRT team had missed the PoCs from our Sep 29 submission, despite having awarded a bounty for it, explaining why Intel had failed to address - or even publicly acknowledge - many RIDL-class vulnerabilities on May 14, 2019.

On Oct 15, 2019, we learned that Intel had not found this issue internally and the only other independent finder was the Zombieload team, which disclosed TAA to Intel in April, 2019. The MEDUSA team later published an independent analysis using TAA.

On Oct 25, 2019, we tested Intel's latest microcode update, and still saw leaks with the VERW mitigation enabled, using the RIDL PoCs we shared with Intel in May 2019. We notified Intel and shared a polished PoC to make the issue clear. Intel requested a new embargo and yet suggested adding the following to our first RIDL addendum: "A new microcode update release by Intel in November is required to adequately address the issue".

On Nov 12, 2019, TAA and the other scheduled RIDL issues are disclosed. Unfortunately, we believe that, given the piecemeal (variant-by-variant) mitigation approach pursued by Intel, RIDL-class vulnerabilities won't disappear any time soon.

We are particularly worried about Intel's mitigation plan being PoC-oriented with a complete lack of security engineering and underlying root cause analysis, with minor variations in PoCs leading to new embargoes, and these "new" vulnerabilities remaining unfixed for lengthy periods. Unfortunately, until there is sufficient public / industry pressure, there seems to be little incentive for Intel to change course, leaving the public with a false sense of security. Slapping a year-long embargo after another (many news cycles apart) and keeping vulnerabilities (too) many people are aware of from the public for a long time is still a viable strategy.

Media attention

The attacks presented on this page got quite the media attention. RIDL and Fallout were covered amongst others by New York Times, Ars Technica, WIRED, De Volkskrant, NRC Next, Tweakers, RTL nieuws, AVRO Tros, The Verge, ZDNet

Known Timeline

Based on the information shared with us by Intel and other finders.

2018
28
MAR
  • TU Graz reports Meltdown UC to Intel
  • TU Graz reports Meltdown UC - Meltdown leaks from Uncacheable Memory - (identified as MDSUM) to Intel.

JUN
  • Microsoft reports to Intel
  • Microsoft independently reports a new issue (identified as MFBDS) to Intel on behalf of Giorgi Maisuradze (interning at MSR).
17
AUG
  • Bitdefender reports to Intel
  • Dan Horea Lutas' team at Bitdefender independently reports a L1TF mitigation bypass (identified as MFBDS) to Intel.
25
AUG
  • Volodymyr Pikhur reports to Intel
  • Volodymyr Pikhur independently reports a L1TF mitigation bypass (identified as MDSUM) to Intel.
12
SEP
  • VUSec reports RIDL to Intel
  • The RIDL authors from VU Amsterdam (VUSec) independently report the RIDL class of vulnerabilities (identified as MFBDS, and later also acknowledged as MLPDS, MDSUM, TAA, L1DES, and VRS) to Intel. Upon request, Intel communicates none of the existing (MFBDS) finders are interested in collaborating on a research paper with VUSec.
29
SEP
  • VUSec reports more RIDL PoCs including TAA
  • VUSec reports updated RIDL PoCs to Intel and Microsoft, including TAA
01
NOV
  • RIDL submitted @ IEEE S&P '19
  • The RIDL paper is submitted for publication to the IEEE Symposium on Security & Privacy, 2019.
29
NOV
  • Giorgi Maisuradze joins RIDL team
  • Giorgi Maisuradze and VUSec merge research efforts into the RIDL paper, after discussing common findings for the first time.
30
DEC
  • RIDL accepted @ IEEE S&P '19
  • The RIDL paper is accepted for publication at the IEEE Symposium on Security & Privacy, 2019.
2019
31
JAN
  • Minkin, Genkin, and Yarom report to Intel
  • Minkin, Genkin, and Yarom report Fallout vulnerabilities (identified as MSBDS) to Intel.

    The finders would also like to acknowledge all the other authors on the Fallout paper.
19
FEB
  • VUSec and Volodymyr Pikhur share information
  • VUSec and Volodymyr discuss their findings for the first time.
21
FEB
  • VUSec and Dan Horea Lutas share information
  • VUSec and Dan discuss their findings for the first time.
12
APR
  • TU Graz reports ZombieLoad to Intel
  • TU Graz reports ZombieLoad (identified as MFBDS and later also acknowledged as TAA and L1DES) to Intel.
1
MAY
  • VUSec allowed to share by Intel
  • VUSec allowed to share findings with all academic finders by Intel. VUSec starts sharing information and making plans with the other teams, in an attempt to converge to a common website with a unified message and acknowledgements for all the finders. Unfortunately, as some teams felt unable to share their findings before the disclosure date, this effort was only partially successful, resulting in the present website (mdsattacks.com) presenting only the two independent RIDL and Fallout papers. See also FAQ#2.
3
MAY
  • VUSec receives a partial whitepaper from Intel
  • The partial/draft whitepaper only mentions Fill Buffers, and none of the other issues.
7
MAY
  • VUSec, Genkin, and Yarom share information
  • VUSec, Genkin, and Yarom discuss their findings for the first time. VUSec shares the RIDL paper with Genkin and Yarom.
10
MAY
  • VUSec gets technical feedback from Intel
  • Intel shares the full MDS whitepaper with the RIDL team for the first time
11
MAY
  • VUSec reports a number of missed issues to Intel
  • The issues include TAA, alignment faults, and the flawed MDS mitigation
13
MAY
  • VUSec, Genkin, and Yarom share information
  • The Fallout paper is shared with VUSec.
13
MAY
  • Intel requests last-minute blanket embargo
  • Intel requests a new embargo on all RIDL-related issues not covered in their whitepaper. This includes withholding details from the RIDL paper and no release of the RIDL test suite
14
MAY
  • Public disclosure of MDS attacks
  • The first embargo is over after nearly a year and RIDL, Fallout, ZombieLoad, and MDS are now publicly disclosed.
?
MAY
  • ZombieLoad team reports L1DES to Intel
  • The ZombieLoad team reports a PoC (later identified as L1DES) to Intel.
3
JUL
  • Intel reports having missed RIDL PoCs
  • Intel reports having missed the PoCs from VUSec's Sep 29, 2018 RIDL submission, including TAA and other issues. Moreover, Intel informs the RIDL team and the ZombieLoad team they are both under the second (TAA/VERW) embargo and allowed to exchange information.
1
OCT
  • VUSec reports VRS to Intel
  • VUSec reports a slightly modified RIDL 'alignment_write' PoC (later identified as VRS) to Intel.
25
OCT
  • VUSec reports L1DES to Intel
  • VUSec reports a PoC (later identified as L1DES) bypassing the latest microcode mitigation to Intel.
5
NOV
  • Intel requests a third embargo
  • Intel requests a third embargo for L1DES and VRS. We also confirmed VERW (latest microcode mitigation) leaks with RIDL PoCs shared with Intel on May 11, 2019.
12
NOV
  • Public disclosure of more RIDL-related issues
  • The second RIDL embargo is over. Details about issues such as TAA that have been embargoed for more than a year are now public. And so is our RIDL test suite. The embargoed material has been added to the RIDL paper by means of a first addendum.
2020
27
JAN
  • Public disclosure of even more RIDL-related issues
  • The third RIDL embargo is over, with the public disclosure of the L1DES and VRS variants. The embargoed material has been added to the RIDL paper by means of a second addendum.
10
MAR
  • Public disclosure of LVI and Snoop
  • LVI and Snoop are disclosed by the LVI team and Pawel Wieczorkiewicz (respectively).
9
JUN
  • Public disclosure of CrossTalk / SRBDS
  • VUSec discloses CrossTalk and SRBDS.

Acknowledgements

The RIDL work at VUSec was supported by the European Union's Horizon 2020 research and innovation programme under grant agreements No. 786669 (ReAct) and No. 825377 (UNICORE), by the United States Office of Naval Research (ONR) under contracts N00014-17-1-2782 and N00014-17-S-B010 "BinRec", by Intel Corporation through the Side Channel Vulnerability ISRA, and by the Netherlands Organisation for Scientific Research through grants NWO 639.023.309 VICI "Dowsing", NWO 639.021.753 VENI "PantaRhei", and NWO 016.Veni.192.262. The public artifacts reflect only the authors' view. The funding agencies are not responsible for any use that may be made of the information they contain.