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 community1 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.
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.
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:
Figure 1 illustrates an example of this behavior for a conditional branch.
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.
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:
Steps 1 and 2 are collectively referred to as the disclosure gadget3. 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 sandbox4 within the victim’s domain. The following sections describe these in more detail.
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).
A cross-domain transient execution attack5 requires the adversary to find a disclosure gadget in the victim’s domain which, when executed transiently, can transiently access6 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.
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.
This refined terminology will benefit software developers by helping to succinctly convey the impacts of newly discovered and existing vulnerabilities. For example:
LFENCEautomatically or only in places identified as vulnerable to Bounds Check Bypass).
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.
|Variant 1: Bounds Check Bypass (Spectre v1) includes Bounds Check Bypass Store||X||X||
In-Domain can be addressed by replacing sandbox techniques with other techniques (for example, process isolation, protection keys, etc.); Alternative techniques to strengthen sandboxes are described here.
Cross-Domain is often mitigated through predictor isolation or by defensive software techniques (for example, SLH, LFENCEs, etc.) deployed in victim to prevent gadget exploitation.
|Variant 2: Branch Target Injection (Spectre v2)||X||X|
|Variant 4: Speculative Store Bypass (Spectre v4)||X||X||See footnote 7|
|Load Value Injection (all types)||X||X|
|Variant 3: Rogue Data Cache Load (Meltdown)||X||Domain-Bypass is often mitigated through hardware changes or through flushing state on domain transitions.|
|Variant 3a: Rogue System Register Read||X|
|Microarchitectural Data Sampling||X|
|TSX Asynchronous Abort||X|
|Vector Register Sampling||X|
|L1 Terminal Fault||X|
|L1D Eviction Sampling||X|
|Snoop Assisted L1D Sampling||See footnote 8||X|
|Special Register Buffer Data Sampling||X|