Spectre is here to stay: An analysis of side-channels and speculative execution by Ross Mcilroy, Jaroslav Sevcik, Tobias Tebbi, Ben L. Titzer, Toon Verwaest (2019) (read in 2019)

“In variant 1 we’ve shown that indirect jump prediction can be exploited to bypass the implicit type checks that are part of a typical language’s virtual dispatch mechanism. As it turns out, the branch target buffer on most CPUs are approximate in order to save space. For example, Intel 64-bit CPUs only store the low-order 32 bits of the from address (the address of the indirect jump) and the low-order 32 bits of the relative target address (the predicted address). Upon lookup, the predictor ignores the upper 32 bits of the from address and reuses a prediction for an aliased from address. This allows an attacker to train a target indirect branch to speculatively jump to any address within a 4GiB range without ever executing the victim branch.”

“This is particularly bad, because the attacker can create speculative indirect jumps to anywhere, i.e., control flow that cannot possibly exist in the original code, such as jumping into the middle of arbitrary machine code that simply happens to be a leaking gadget. That means an attacker may not even need to craft an instruction sequence, but find an extant instruction sequence in the victim’s code, similar to return-oriented programming. This can even work across processes. [20] found that the branch target buffer on Intel chips is shared across hyperthreads on the same core, allowing one process to inject predictions into another.”

“User programs should not be able to access unmapped virtual memory addresses, write to read-only memory [18], or read from kernel memory. Such attempts should result in a faults. Some CPUs seem to check for a fault too late, effectively speculating through a hardware permission check. This depends on the specific details of a CPU’s trap mechanism of course; e.g. faulting at retirement is too late if the processor has already accessed the memory and supplied its value to dependent instructions, which leaked the value into µ-state. Lipp et al. [22], describe a variant 3 attack that enables leakage of data in kernel memory to a userspace process.”

“Since memory is often the bottleneck in many programs, modern CPUs utilize not only caching but dynamic alias analysis known as memory disambiguation. When executing a store, the CPU uses a predictor to determine which, if any, subsequent loads will depend on the store. If the prediction is no-alias, the CPU may speculatively execute a later load before the store. If the prediction turns out to be incorrect and the store address and load address are in fact aliases, this will be detected when instructions are being retired in program order, and the load will be aborted and re-executed. This, too, represents a vulnerability, since loads that are speculatively executed out of order observe stale values from memory.”

“Bypassing stores is only one way a memory disambiguator can speculatively accelerate loads [33]. As long as violations are detected and repaired before retirement, other aggressive forwarding strategies could be implemented. If the memory disambiguator learns that a load typically aliases a store, it could speculatively forward the value even if the source address for the load is not yet known. Similarly the disambiguator could learn that two consecutive loads typically load from the same address, and inject the result from the first load into the second.”

“What characteristics of a programming language make it exploitable on today’s modern hardware? As we have seen, access to a timer, no matter the resolution, leaks µ-architectural information. We point out several language features whose typical implementations may be vulnerable to Spectre. In these we found that a key to constructing the universal read gadget was speculative pointer crafting, whereby an attacker exploits speculation to trick the implementation into interpreting attacker-controlled input as a machine-level pointer, feeding this pointer into a (normally innocent, but speculatively dangerous) load to achieve the universal read gadget.”

“In particular, we found variant 1 to be quite simple to exploit. For managed languages, variant 3 is only different from variant 1 in that superuser memory can be accessed. Variant 2 is only easily exploitable if one has direct control over the virtual memory addresses of code. Variant 4 can be difficult to exploit reliably due to the black box nature of the memory disambiguator state. We focused exclusively on in-process attacks and not cross-process attacks.”

“Variant 4 defeats everything we could think of. We explored more mitigations for variant 4 but the threat proved to be more pervasive and dangerous than we anticipated. For example, stack slots used by the register allocator in the optimizing compiler could be subject to type confusion, leading to pointer crafting. Mitigating type confusion for stack slots alone would have required a complete redesign of the backend of the optimizing compiler, perhaps man years of work, without a guarantee of completeness.

“We recognized quickly that a compiler backend overhaul, a complete audit of the entire runtime system, and application of (not yet designed) mitigations in the C++ compiler for the VM’s code itself were intractable for essentially any-sized codebase.

“For this reason we do not believe that variant 4 can be effectively mitigated in software, due not just to manpower, but a lack of architectural options, since reasoning about variant 4 requires the confounding assumption that in speculation, writes to memory may not be visible to subsequent reads at all.”

“Spectre defeats an important layer of software security. The community has assumed for decades that programming language security enforced with static and dynamic checks could guarantee confidentiality between computations in the same address space. Our work has discovered there are numerous vulnerabilities in today’s languages that when run on today’s CPUs allow construction of the universal read gadget, which completely destroys language-enforced confidentiality.”

“1. Finding µ-architectural side channels requires enumerating and modeling relevant µ-state, a difficult task for processors that are closed source and full of valuable and carefully-guarded intellectual property. 2. Understanding vulnerabilities requires us to model how programs can manipulate and observe µ- state, which also requires us to understand complex µ-state in black-box processors. 3. Mitigating vulnerabilities is perhaps the most challenging of all, since efficient software mitigations needed for extant hardware seem to be in their infancy, and hardware mitigation for future designs is a completely open design problem.”

“Our models, our mental models, are wrong; we have been trading security for performance and complexity all along and didn’t know it. It is now a painful irony that today, defense requires even more complexity with software mitigations, most of which we know to be incomplete. And complexity makes these three open problems all that much harder. Spectre is perhaps, too appropriately named, as it seems destined to haunt us for a long time.”