Skip to content

Comment on Speculative Dereferencing of Registers: Reviving Foreshadow [pdf]

Comments

The article's presentation of the research is completely wrong. There aren't any new side channels here. All the paper purports to show (albeit in a somewhat self-aggrandizing manner) is that the mechanisms for Meltdown and Foreshadow were incompletely understood when originally presented. But there's nothing knew in the notion that speculative execution optimizations are responsible for most side channels, nor that they played a role in Meltdown and Foreshadow. "Spectre" is a play on words--it alludes to speculative execution.

There aren't any major new exploits detailed in this paper. They introduce a slightly new gadget for exposing data, but it can be and is mitigated by existing techniques (e.g. retpolines). The only noteworthy aspect is that, as it regards SGX, the mitigations haven't yet been generally applied. But new ways to break SGX are a dime a dozen these days.

Interesting and rigorous work, but there don't seem to be any real implications here. It's more like a more concise restatement of researchers' present understanding, using the benefit of hindsight and some additional footwork to fill in some small gaps.

Yeah, if I'm understanding this correctly they just show that the part of the Foreshadow attack that loaded kernel memory contents into cache prior to leaking it, rather than working in some obscure Intel-specific way as previously thought, is actually just a known Spectre variant which works on a whole bunch of processors including AMD and ARM ones. It's not massively useful on those processors because the stage that actually leaks the memory contents and known alternatives like Meltdown are Intel-specific, so it requires a certain amount of cleverness to even detect that it's happening, but it does happen.

Beyond our thorough analysis of these previous works, we also demonstrate new attacks enabled by understanding the root cause, namely an address-translation attack in more restricted contexts, direct leakage of register values in certain scenarios, and the first end-to-end Foreshadow (L1TF) exploit targeting non-L1 data. The latter is effective even with the recommended Foreshadow mitigations enabled and thus revives the Foreshadow attack.
We demonstrate that these dereferencing effects exist even on the most recent Intel CPUs with the latest hardware mitigations, and on CPUs previously believed to be unaffected, i.e., ARM, IBM, and AMD CPUs
The latter is effective even with the recommended Foreshadow mitigations

That's different than saying it's effective even with mitigations required for other Spectre-related exploits. When larger problems arise and more general mitigations applied that also happen to be better mitigations for previous, narrower exploits, people don't usually make much effort to review and revise old papers.

AFAIU, discovery of Meltdown slightly predates Spectre, or at least the point at which the implications began to blow up. The Meltdown and Spectre papers were published the same month Foreshadow was discovered and privately reported. It seems two researchers were involved with both Foreshadow and the earlier Spectre work, but that doesn't mean they would have or should have fully grasped the deeper relationships. And all of this happened over 2 1/2 years ago. Since then researchers' understanding of the underlying issues has improved greatly.

The tone of the paper is, I think, problematic. Just read footnote #1, which self-defensively says: "Various authors of papers exploiting the prefetching effect confirmed that the explanation put forward in this paper indeed explains the observed phenomena more accurately than their original explanations. We believe it is in the nature of empirical science that theories explaining empirical observations improve over time and root-cause attributions become more accurate."

So their presentation is "more accurate". And the writers of the 2+ year-old papers readily admit it. All of which is another way of saying these were already accepted, if not yet concretely expressed, beliefs in the research community. There's much value in putting pen to paper and running confirmatory experiments. But that doesn't make it groundbreaking.

EDIT: Regarding "We demonstrate that these dereferencing effects exist even on the most recent Intel CPUs with the latest hardware mitigations, and on CPUs previously believed to be unaffected, i.e., ARM, IBM, and AMD CPUs". If you read closely it's clear that the context is Foreshadow, mechanism and mitigations. They're saying that when Foreshadow was published those architectures were believed immune. But applying the principles of their "more accurate" understanding you can in fact achieve Foreshadow (or Foreshadow-like) side channels on those architectures even with Foreshadow-specific mitigations. But, again, only subsequent to the initial discovery of both Foreshadow and Spectre did it became known that those architectures were more susceptible to speculative execution attacks than originally understood. Thus elsewhere in the paper it's admitted that more general and modern Spectre mitigations also prevent these "new" Foreshadow exploits.

AFAIU, discovery of Meltdown slightly predates Spectre, or at least the point at which the implications began to blow up. The Meltdown and Spectre papers were published the same month Foreshadow was discovered and privately reported. It seems two researchers were involved with both Foreshadow and the earlier Spectre work, but that doesn't mean they would have or should have fully grasped the deeper relationships. And all of this happened over 2 1/2 years ago. Since then researchers' understanding of the underlying issues has improved greatly.

I'm under the impression that the side channels created by caches and speculative execution have been known publicly (but with limited reach/impact) as far back as the 90s. E.g. the 1991 paper "A Retrospective on the VAX VMM Security Kernel" mentions data security problems and the creation of side channels when processor caches are used.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.