More Intel woes. http://www.digitaljournal.com/tech-and-science/technology/new-security-flaw-... Quote from the whitepaper link in the article. 3 GENERAL ATTACK OVERVIEW Before detailing specific attack scenarios, in this section, we introduce the basics of how RSB-based speculative execution can be achieved and be abused. We explore whether and how attackers may manipulate the RSB entries in order to leak sensitive data using speculative execution that they could not access otherwise. Similar to recent microarchitectural attacks [8, 10, 22, 26, 29], we trick the CPU to execute instructions that would not have been executed in a sequential execution. The goal is to leak sensitive information in speculation, e.g., by caching a certain memory area that can be detected in a normal (non-speculative) execution. The general idea of our attack can be divided into three steps: (A1) trigger misspeculations in the return address predictor, i.e., enforce that returns mispredict (A2) divert the speculative execution to a known/controlled code sequence with the required context (A3) modify the architectural state in speculation, such that it can be detected from outside (A1) Triggering Misspeculation: From an attacker’s perspective, enforcing that the return predictor misspeculates upon function return is essential to reliably divert speculative execution to attacker-controlled code (see A2 for how to control the speculated code). Misspeculations can be achieved in several ways, depending on the RSBs underflow behavior (as discussed in Section 2.3).