Back at the start of the year, a set of attacks that leveraged the speculative execution capabilities of modern high-performance processors was revealed. The attacks were named Meltdown and Spectre. Since then, numerous variants of these attacks have been devised.
In tandem, a range of mitigation techniques has been created to enable at-risk software, operating systems, and hypervisor platforms to protect against these attacks.
A research team—including many of the original researchers behind Meltdown, Spectre, and the related Foreshadow and BranchScope attacks—has published a new paper disclosing yet more attacks in the Spectre and Meltdown families. The result? Seven new possible attacks. Some are mitigated by known mitigation techniques, but others are not. That means further work is required to safeguard vulnerable systems.
The previous investigations into these attacks have been a little ad hoc in nature: examining particular features of interest to provide, for example, a Spectre attack that can be performed remotely over a network or Meltdown-esque attack to break into SGX enclaves. The new research is more systematic, looking at the underlying mechanisms behind both Meltdown and Spectre and running through all the different ways the speculative execution can be misdirected.
Meltdown, in general
Consider, for example, the Meltdown attack (used to leak kernel data to user-mode programs on most Intel and some ARM chips, including those from Apple) and the Level 1 Terminal Fault (L1TF) attack (used to break into an SGX enclave). At a high level, both of these attacks work in a similar way: an attempt is made to access memory to which access is forbidden. , however, the processor is able to access the forbidden memory and perform speculative execution based on the values the memory holds. The processor notices that access was forbidden and rolls back the speculative execution, but the speculation has caused small disturbances to the processor cache. These disturbances can be detected and used to read data that should be inaccessible.
In the original Meltdown attack, the access is forbidden because a user program is trying to access “supervisor” (which is to say, kernel) memory. In L1TF, the access is forbidden because code from outside an SGX enclave is attempting to access data within an SGX enclave. In both cases, the processor does correctly block the forbidden access; it just takes a few cycles to do so, enabling speculative execution to run ahead of the permissions check.
Further Meltdown-style attacks discovered over the past year include an attempt to read a privileged system register from user code (which, again, generates an error because the access is forbidden but not before some speculation was allowed to occur); an attempt to use the processor’s floating point unit when it is not presently enabled (which generates an error to say that there’s no floating point unit available—operating systems trap this error and respond by enabling the floating point unit); and an attempt to write over read-only data.
In the new research, these Meltdown variants are joined by a new one using Intel’s “Protection Keys for Userspace” (PKU). Protection keys introduced with Skylake allow an application to mark pieces of memory with a four-bit key. Applications set the processor to use a particular protection key, and, during that time, attempts to access memory that is labeled with a different key will generate an error. Yet again, a few nanoseconds of speculation can occur between making an invalid access (accessing memory with a mismatched protection key) and the processor reporting the error, enabling information that should be protected to leak.
Similarly, another Intel extension is the Memory Protection eXtensions (MPX). MPX is designed to allow the processor to detect and trap certain attempts to access out-of-bounds memory. The story here is the same as the other Meltdown problems: after attempting to perform an out-of-bounds access, a few nanoseconds of speculation are performed before the “out-of-bounds” error is generated, once more allowing information to leak. MPX is only available for 64-bit x64 programs. Thirty-two-bit x86 has a simpler form of bounds protection that’s both on Intel and AMD chips; this simpler bounds protection is also susceptible to Meltdown-style information leakage, and, unusually, AMD processors are susceptible to this attack.
In every case, the processor generates a kind of error (classified by Intel as a “fault”). This error creates a small window of speculation between the action that generates the fault and the fault actually being reported.
The researchers looked at further fault conditions but found that many of them don’t create a Meltdown-like vulnerability. For example, division by zero generates a fault, but speculative execution only ever sees a zero result, providing no scope to leak information. Intel chips can generate alignment exceptions when attempts are made to access memory addresses that aren’t whole multiples of 16, 32, or 64; these, too, don’t permit Meltdown attacks. Neither do the faults generated by violations of memory segmentation or those created by trying to execute invalid instructions.
Just as all the Meltdown variants follow a similar pattern, so, too, do the Spectre variants. The processor makes a prediction about which way a branch will be taken and speculatively executes on the basis of that prediction. It then discovers that the prediction is wrong and undoes its speculation, but it disturbs cache in a measurable way, enabling information leakage. In a Spectre attack, the attacker will try to prime the processor to predict a certain way and then use that misprediction to leak information.
Spectre attacks were categorized in a number of ways. There are several different predictors in a processor: predictions are made based on the address of the branch itself and the targets of the branch, for example; the processor also predicts where execution will continue when returning from one function to another, with a special predictor there.
Priming the branch predictor can be done in a couple of ways: the predictor can be trained to mispredict the exact branch being attacked or with a branch that’s at a related but different memory address. Spectre also opens the possibility of prediction training in one process being used to force mispredictions in a different address space or within the kernel. Misprediction can also occur when a value in memory is overwritten without the speculative execution machinery “noticing” and executing based on the old value.
In total, five different misprediction scenarios were identified (four based on branch predictors, one based on stores to memory being overlooked momentarily). Of the four branch predictor attacks, each attack can be used either against the same address space or a different one, and it can be used against the same branch or one that’s related. This creates 16 branch predictor-based variants as well as the store-based attack. Not every single combination has so far been tested, but in the paper, several new Spectre-style attacks are described. They use various combinations of the predictor being exploited, the address being attacked, and the address space being attacked.
In particular, one of the variants of the original Spectre attacks has been shown to have greater applicability against AMD’s latest processors than previously known; likewise the attack has also been shown to be effective against ARM processors.
Intel and AMD have both since introduced mechanisms for constraining the speculation and predictions made by the processor to give application and operating system developers the tools to limit the impact of Spectre. These include a way to prevent user mode code from influencing speculation in kernel mode, a way to prevent predictions on one logical core of a processor from influencing predictions made by the other logical core, and a way to flush certain data structures used by predictions to prevent the predictors from being trained in any particular way.
Going forward, we’ll likely continue to see improvements to the mitigation techniques, both to improve their performance and make them more effective. It’s unlikely that we’ve seen the last of the speculative execution attacks, but this systematic analysis should at least mean that all the low-hanging fruit has been discovered.