Linux has flags that allow disabling mitigations to get performance back. MacOS and Windows probably have the same. Pretty much the only thing that is running unauthenticated workloads on my dev machine are my browser and mail client. Is there a way to disable the mitigation’s globally but enable them per process? I don’t mind much getting a 10-30% performance hit on browsing, but I do mind when compiling/testing things.
A thought just came to my mind. Let's say 30 years ago, I said to a colleague with whom I shared accesses to some Unix systems, "You know, I can use 'ps' to see what processes you are running. If I know the details about certain flaws of those binaries, I may be able to run a custom binary simultaneously on the system and figure out some of your data!" Would he/she be surprised or alarmed?
Can we change the link to the actual paper?<p>Speculative Dereferencing of Registers:Reviving Foreshadow<p>Martin Schwarzl, Thomas Schuster, Michael Schwarz, Daniel Gruss<p><a href="https://arxiv.org/abs/2008.02307" rel="nofollow">https://arxiv.org/abs/2008.02307</a>
Direct link to research: <a href="https://arxiv.org/pdf/2008.02307.pdf" rel="nofollow">https://arxiv.org/pdf/2008.02307.pdf</a>
Has anyone used these techniques in the wild to steal certificates from another customer on AWS or use Javascript to start probing memory on my machine from the browser? Are these attacks really severe or is it all theoretical?
Side-channel attacks are an inherent property of computing hardware. You can never fully "disguise" a computation as a different one or as no computation.<p>You can just lower the signal to noise ratio by various means, so you gain some time until better statistical methods or clever tricks filter out the signal again.
DJB wrote a paper about how "Speculative execution is much less important for performance than commonly believed." <a href="https://arxiv.org/abs/2007.15919" rel="nofollow">https://arxiv.org/abs/2007.15919</a>
Some might enjoy a teaser video of related work by some of the same authors: <a href="https://www.youtube.com/watch?v=baKHSXeIIaI" rel="nofollow">https://www.youtube.com/watch?v=baKHSXeIIaI</a>. For context, the teaser was produced due to the conference going virtual because of the pandemic.
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 <i>originally</i> <i>presented</i>. 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.<p>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.<p>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.