Intel Proposes New Type of Memory to Fix Speculative Execution Flaws

DRAM-Feature

Ever since the disclosure of side-channel attacks like Spectre and Meltdown, the semiconductor industry in general and Intel in particular have been grappling with the security problems this class of attacks creates. While these ongoing attacks have mostly been discussed in terms of what they mean for Intel, the security implications of side-channel attacks go beyond any single company. Thus far, many of the countermeasures deployed against Spectre and its ill-spawned children have been specific to the attacks they were intended to counter. Security researchers vastly prefer to lock down systems against entire classes of attack rather than having to fix each individual problem as it occurs, and a team of researchers at Intel STORM (Strategic Offensive Research and Mitigation) have proposed a means of doing so using a new type of memory they call Speculative Access Protected Memory.

Certain memory ranges would be defined as SAPM-protected memory. (PDF) When the CPU detects a memory access targeting this protected RAM, it begins processing instructions in strict serial fashion and refuses to engage in speculative execution until the SAPM-targeting instruction has been retired. Applications would be free to store secret data in SAPM as required, but there would only be a performance penalty for reading this information when it’s actually accessed.

Intel believes this approach is not only possible but preferable. The following chart from Microsoft’s Security Response Center is an older one, from March 2018. It predates the disclosure of a number of additional speculative execution vulnerabilities. The reason I’m showing it is that it illustrates how complex the mitigation strategies against just Spectre and Meltdown potentially were, to say nothing of attacks discovered since or additional methods that may be found in the future.

Image by the Microsoft Security Response Center

Intel’s white paper also refers extensively to the discussion framework adopted by the MSRC, which conceptualizes speculative execution attacks as containing a front-end and a back-end component. In Microsoft’s framing, the front-end of a speculative execution side-channel attack is what varies from attack method to attack method. The back-end of the attacks discovered to date has been largely similar in all cases and involves a “cache-based covert channel.” The back-end, Intel writes: “transforms the speculatively loaded secret into a secret-dependent cache-line loading that is measurable using timing side-channel analysis. The back-end needs to be executed speculatively AFTER the speculative load of the secret.”

While the need to stop speculative execution during a SAPM access is an obvious performance penalty, Intel believes that proper and judicious use of this capability would ultimately result in a much smaller performance hit than the one imposed by the various solutions already implemented to resolve Spectre, Meltdown, and other vulnerabilities to date. A CPUSEEAMAZON_ET_135 See Amazon ET commerce that detects a memory access aimed at a SAPM-protected memory region would immediately flush its own pipeline, re-fetch only those instructions related to the execution of the SAPM-accessing instruction, and then proceed stepwise and in serial fashion until the SAPM-accessing instruction is retired. The advantage of this method is that it ensures that a speculative execution leak targeting a sensitive memory area can’t happen, no matter what the underlying vulnerability is.

The SAPM approach would address Spectre, Meltdown, L1TF (Foreshadow) and SSB. It would not guard against RIDL or MDS, though the real-world risk of these approaches is quite limited. To the best of our knowledge, no real-world attacks leveraging Spectre, Meltdown, or any of the associated speculative execution vulnerabilities have ever been spotted in the wild, and some of these attack methods are intrinsically difficult to take advantage of, even in ideal circumstances. Just because you can trick a CPU into disclosing speculatively executed information does not mean you can trick it into disclosing useful information. Thus far, we have not seen any black hats using these tactics to exfiltrate data.

The STORM team has released their paper as a proposal for the community, so we’ll see what other developers think of it. If this tactic works, it could significantly narrow the total attack surface presented by Spectre-style attacks. While other kinds of side-channel exploits are possible — side-channel attacks, by their intrinsic nature, cannot be entirely prevented — eliminating cache-based methods would still represent a significant improvement. Nothing in the proposal is specific or unique to Intel, so this solution could be deployed by any firm that found it a useful mitigation strategy.

Now Read:

  • Intel Discloses New Speculative Execution Security Vulnerabilities
  • Intel Performance Hit 5x Harder Than AMD After Spectre, Meltdown Patches
  • Modern CPUs Likely Permanently Haunted by Spectre Security Flaws