Refined Speculative Execution Terminology

The current terminology being used to describe speculative execution side channel vulnerabilities can be imprecise in certain situations. Newly discovered vulnerabilities are being described in terms of old vulnerabilities (“Spectre-like,” “Meltdown-like,” etc.), which can lead to misinterpretation of their operation or impact. Additionally, technical terms with different meanings such as “side channel” and “covert channel” have been applied interchangeably in certain cases. The purpose of this article is to introduce a unified terminology that is concise and unambiguous, while also aligning with the research community¹ where that makes sense. Intel plans to adopt the terms in this article for future guidance; although not all existing Intel guidance has been updated at this time.

Listen to Scott Constable, Security Researcher in Intel Labs, discuss Software Techniques to Mitigate Hardware Transient Execution Attacks during IEEE SecDev 2020.

Channels

A channel is any medium in a computing system that may transmit or signal information. Channels in the context of computing systems are of two sorts: legitimate channels are those intended by system designers for the transmission of information, and all other channels are incidental channels. Examples of legitimate channels include ethernet, shared memory, and IPC sockets. Resource contention, the state of a CPU cache, and variations in power consumption are all examples of incidental channels.

In the context of a security threat model, it is often useful to distinguish between two methods by which a malicious adversary can exploit an incidental channel. An incidental channel is functioning as a covert channel if the adversary controls both the input and output of the incidental channel. An incidental channel is serving as a side channel if the adversary cannot exert control over the input and is only able to read the output. For instance, the implementation of a cryptographic algorithm may unintentionally leak sensitive data into a side channel while the adversary is monitoring the side channel’s output.

Note that legitimate channels and incidental channels are attributes of a computing system, whereas side channels and covert channels are aspects of a threat model that describe how the adversary may use an incidental channel.

Speculative Execution Background

Modern processors execute instructions out of order to improve performance. These out-of-order processors may “speculate” that a branch or a load can use a value before the processor confirms that speculative value is correct, and execution may proceed with that speculative value temporarily. When the branch/load resolves and it is known whether the value speculatively used was correct, there are two possible cases:

1. If the speculatively used value was correct, then instructions that depend on that value are valid and can retire, meaning that their results become architecturally visible to the program.
2. Otherwise, the instructions that depend on that speculative value are invalid and must be squashed, meaning that their results are not committed to the architectural program state. These instructions are called transient² (meaning impermanent). Following the squash, the processor can resume execution with the correct value.

Figure 1 illustrates an example of this behavior for a conditional branch.

Figure 1. An example illustrating branch speculation: Chevrons show non-transient instructions; stars show transient instructions.

Although the results of transient instructions are not committed to the architectural program state, microarchitectural processor state may still be affected by transient instructions. For example, if a transient instruction attempts to load data from an address whose contents are not available in any processor cache, then the corresponding data may be loaded into a processor cache. The state of that cache constitutes an incidental channel. Data can be observed from this channel via analysis techniques such as Flush+Reload or Prime+Probe that measure the latencies of cache accesses.

Transient Execution Attacks

A transient execution attack exploits the microarchitectural side effects of transient instructions, thus allowing a malicious adversary to access information that would ordinarily be prohibited by architectural access control mechanisms. To successfully launch a transient execution attack, the adversary must be able to:

1. Access a victim’s secret.
2. Transmit that secret over a covert channel.
3. Receive the secret from the covert channel.

Steps 1 and 2 are collectively referred to as the disclosure gadget³. Note that the underlying incidental channel is functioning as a covert channel because the adversary controls both its input and its output.

Transient execution attacks can be categorized according to their impact on hardware-based protection features. A hardware protection domain (referred to simply as domain in this context) consists of code and data within a protection boundary that is defined by hardware-enforced access control mechanisms such as privilege level (ring), page tables, and protection keys. Examples of domains include processes, Intel® Software Guard Extensions (Intel® SGX) enclaves, Virtual Machines (VMs), and ring 0 operating system (OS) code. Domains can also be distinct machines or devices connected over a network, bus, or other hardware interface; the content of network/bus traffic constitutes the legitimate channel, and other measurable attributes of the transmission (latency, for instance) may create incidental channels.

A transient execution attack is characterized by the relationship between the disclosure gadget and the victim/adversary domains: a transient execution attack is domain-bypass if the disclosure gadget is in the adversary’s domain, cross-domain if the disclosure gadget is in the victim’s domain, or in-domain if the disclosure gadget is in an adversary-controlled sandbox⁴ within the victim’s domain. The following sections describe these in more detail.

Domain-Bypass Transient Execution Attack

Figure 2. Anatomy of a domain-bypass transient execution attack: Snipped blue boxes show data; rounded red boxes show adversary code; arrows depict the secret's data flow during the attack.

In a domain-bypass transient execution attack, the adversary executes transient instructions that circumvent hardware-based access controls, allowing access to a secret outside of the adversary’s domain. This sequence of transient instructions must also contain a transmitter such as a memory access that encodes the secret into the CPU’s cache state. Non-transient receiver code can recover the secret by applying a cache analysis technique such as Flush+Reload.

As a specific example, consider Rogue Data Cache Load (Meltdown). The adversary’s domain is a ring 3 application, and the victim domain is the operating system kernel (ring 0). When the adversary attempts to access kernel memory sharing the same virtual address space, transient instructions may allow kernel data to be read and transmitted before hardware-enforced permission checks are resolved. Other examples of domain-bypass transient execution attacks include Microarchitectural Data Sampling (MDS) and L1 Terminal Fault (L1TF).

Cross-Domain Transient Execution Attack

Figure 3. Anatomy of a cross-domain transient execution attack: Snipped blue boxes show data; the rounded red box shows adversary code; semi-rounded orange boxes show victim code being manipulated by the adversary; arrows depict the secret's data flow during the attack.

A cross-domain transient execution attack⁵ requires the adversary to find a disclosure gadget in the victim’s domain which, when executed transiently, can transiently access⁶ and transmit a secret over a covert channel.

Cross-domain transient execution attacks are generally the most difficult to launch successfully because the adversary is unable to construct the disclosure gadget. It is non-trivial to find a disclosure gadget in an existing victim program that can transiently access and transmit a secret prior to being squashed. If the adversary is in ring 3, then noise from other processes can substantially weaken the fidelity of the covert channel. Synchronizing with the victim (as required by Prime+Probe) may also prove challenging for a ring 3 adversary.

An example of a cross-domain transient execution attack is Branch Target Injection (Spectre variant 2) where a malicious ring 3 application (the adversary) trains a branch predictor that is shared with another ring 3 application (the victim) to predict a memory address chosen by the adversary. The target address could be a disclosure gadget that can transiently access memory and transmit secret data before the branch misprediction is squashed.

In-Domain Transient Execution Attack

Figure 4. Anatomy of an in-domain transient execution attack: Snipped blue boxes show data; rounded red boxes show adversary code; arrows depict the secret´s data flow during the attack.

An in-domain transient execution attack allows a sandboxed adversary to access a secret within the same domain by circumventing software-based access controls. For example, when a JavaScript program attempts a random access on an array object, the access is subjected to a bounds check that may involve a conditional branch. If the program attempts an out-of-bounds access—but the branch predicts the in-bounds path—the access and transmit instructions may be allowed to execute transiently before the mispredicted path is squashed. This example is a Bounds Check Bypass (Spectre variant 1) attack applied by sandboxed software against its domain.

Figure 4 is intended to be representative of in-domain transient execution attacks, though other variations may exist. For instance, the adversary-controlled receiver could be in another sandbox within the same domain, or it could be in a different domain. As an alternative to software sandboxing, it is also possible to use language-based security or other software fault isolation techniques to isolate software components that share the same domain. These approaches also employ software-based access controls that can be potentially circumvented by transient instructions.

Conclusion and Implications for Developers

This refined terminology will benefit software developers by helping to succinctly convey the impacts of newly discovered and existing vulnerabilities. For example:

• If a vulnerability is described as having domain-bypass impact, then hardware mitigation, microcode patches and/or software changes to the operating system (OS) or virtual machine monitor (VMM) are often required. Software changes to applications are usually not required.

• If a vulnerability is described as having cross-domain impact, then software changes to application, OS or VMM code may be desired to mitigate the vulnerability. These software changes may use processor features that prevent speculation or isolate branch predictors between modes. Developers should also take into consideration that cross-domain transient execution attacks are generally more difficult to launch than other kinds of transient execution attacks. Therefore, developers should use their own discretion when deciding how to mitigate their software (for example, whether to insert LFENCE automatically or only in places identified as vulnerable to Bounds Check Bypass).

• If a vulnerability is described as having in-domain impact, then affected software that uses sandboxing techniques may be vulnerable. Refer to Managed Runtime Speculative Execution Side Channel Mitigations for more information.

Consistent use of the terms outlined in this document will make it easier for the broad security research community to collaborate in identifying future potential threats and mitigations.

Transient Execution Classification

Footnotes

1. For example, see the use of the terms “transient execution attacks” and mitigations in A Systematic Evaluation of Transient Execution Attacks and Defenses.
2. The word “transient” may have other meanings in other contexts. In the context of out-of-order execution, a transient instruction is an instruction that is executed but does not retire.
3. The “disclosure gadget” term originally appeared in Mitigating speculative execution side channel hardware vulnerabilities.
4. In this article, the term “sandbox” is used loosely to refer to untrusted software that is confined from other software in the same domain by language-based security or software fault isolation.
5. Arrows in Figure 5 depict the secret's data flows during the attack. A similar diagram first appeared in DAWG: A Defense Against Cache Timing Attacks in Speculative Execution Processors∗.
6. Some cross-domain variants such as Branch Target Injection do not require the access to be transient. For example, if an architectural register already contains a secret prior to a mispredicted branch, then the secret can be (transiently) transmitted by code at the mispredicted branch target.
7. On Intel processors, there is no memory disambiguation across domain switches. This prevents Speculative Store Bypass from causing domain-bypass vulnerabilities on Intel processors.
8. Snoop Assisted L1D sampling is a domain bypass transient execution attack and is not a cross-domain transient execution attack, even though it may be facilitated through the adversary manipulating the victim behavior. This is because the disclosure gadget executes within the adversary domain. 

Software Security Guidance Home | Advisory Guidance | Technical Documentation | Best Practices | Resources