Spectre is here to stay: An analysis of side-channels and speculative execution · HackerPapers discussions

Spectre is here to stay: An analysis of side-channels and speculative execution — mentioned by sweetjuly

Sun, 13 Aug 2023 02:21:37 GMT

That's not true...at all. There are amplification techniques which work in JS and wasm that amplify a cache eviction into an over 1s delta [1]. Trying to restrict timing as a mitigation has been known to be ineffective since 2019, a bunch of people at Google who worked on the mitigation in Chromium wrote a paper [2] saying as much. Site isolation is the chosen mitigation because it actually works. [1] https://www.youtube.com/watch?v=Hx6IVymJ8ZM [2] https://arxiv.org/pdf/1902.05178.pdf

Paper and discussion history. A mention is not an endorsement.

Spectre is here to stay: An analysis of side-channels and speculative execution — mentioned by titzer

Thu, 31 Mar 2022 14:27:16 GMT

> 4. Spectre attacks make single address space operating systems more complex. I will say, unequivocally, that Spectre actually makes process isolation in single address space operating systems impossible on modern hardware. There is too much speculation and too many leaks, and it's not just branches. We wrote a whole paper about it a few years back. https://arxiv.org/abs/1902.05178

Paper and discussion history. A mention is not an endorsement.

Spectre is here to stay: An analysis of side-channels and speculative execution — mentioned by jssmith

Sun, 10 Oct 2021 13:29:07 GMT

Yes, but it is more restrictive, e.g., it is not Turing complete. I’m not sure whether this directly addresses Spectre risks though. An analysis of Spectre and software isolation is here: https://arxiv.org/abs/1902.05178

Paper and discussion history. A mention is not an endorsement.

Spectre is here to stay: An analysis of side-channels and speculative execution — mentioned by ddworken

Wed, 24 Mar 2021 18:09:32 GMT

While I don't know anything specific about RedLeaf, I highly doubt that it is completely immune to Spectre. Spectre fundamentally stems from how modern CPUs are designed and the current understanding is that there is no way to fix Spectre. If you're curious, see the paper "Spectre is here to stay: An analysis of side-channels and speculative execution" [0]. Even on fully up to date OSs with the latest version of Chrome, Spectre is still exploitable (see [1]). [0]: https://arxiv.org/abs/1902.05178 [1]: https://security.googleblog.com/2021/03/a-spectre-proof-of-c...

Paper and discussion history. A mention is not an endorsement.

Spectre is here to stay: An analysis of side-channels and speculative execution — mentioned by ddworken

Fri, 12 Mar 2021 20:55:02 GMT

See this[1] paper for more information. I think from the browser POV it is more about admitting that it just isn't possible to reliably mitigate Spectre and instead focusing on what can be done at the browser level. And at the browser level, it is possible to ensure that sensitive resources don't end up in processes running attacker JS. Of course this could be fixed at the CPU level, but realistically very few people want that since that would drastically slow down modern CPUs which rely on speculative execution. [1]: https://arxiv.org/pdf/1902.05178.pdf Disclosure: I work at Google and am…

Paper and discussion history. A mention is not an endorsement.

Spectre is here to stay: An analysis of side-channels and speculative execution — mentioned by ddworken

Fri, 12 Mar 2021 20:49:16 GMT

Last year Chrome published a great paper on this[1]. The summary is that we no longer think it is possible to completely prevent speculative execution bugs. A big focus nowadays is on providing tools (mainly via HTTP headers) that allow a website to opt-in to a more strict security model where specific sensitive resources can't end up in a process that is running untrusted code. If you're curious, check out this[2] document which explains a bunch of these different mechanisms. Disclosure: I work at Google and am involved in deploying some of these features internally. [1]…

Paper and discussion history. A mention is not an endorsement.

Spectre is here to stay: An analysis of side-channels and speculative execution — mentioned by titzer

Wed, 10 Mar 2021 23:47:20 GMT

This is the conclusion of our 2019 paper: https://arxiv.org/abs/1902.05178 Side-channel vulnerabilities are too numerous and too hard to defend against. In the limit, the entire process address space is up for grabs.

Paper and discussion history. A mention is not an endorsement.

Spectre is here to stay: An analysis of side-channels and speculative execution — mentioned by ENOTTY

Fri, 04 Dec 2020 04:37:55 GMT

> they still carry all the x86 baggage in microcode, since tons of bad decisions leading to things like Spectra. ARM doesn't > AMD is not affected by Spectre This is not true. AMD, ARM, Intel, and IBM are all affected by Spectre (Bounds Check Bypass) and that particular variant has not been fixed in hardware, and short of disabling speculative execution or radical changes to ISA or microarchitecture, is likely to never be fixed purely in hardware. https://arxiv.org/pdf/1902.05178.pdf

Paper and discussion history. A mention is not an endorsement.

Spectre is here to stay: An analysis of side-channels and speculative execution — mentioned by titzer

Tue, 28 Jul 2020 13:45:38 GMT

> But in some cases, you probably could make it absolutely bulletproof. I don't believe this. Not on modern hardware. I worked on Spectre for almost two years while at Google. We wrote this: https://arxiv.org/abs/1902.05178

Paper and discussion history. A mention is not an endorsement.

Spectre is here to stay: An analysis of side-channels and speculative execution — mentioned by vectorEQ

Fri, 27 Dec 2019 11:42:38 GMT

This paper might be of interest: https://arxiv.org/pdf/1902.05178.pdf it explains the 'concept' of these kind of attacks and why its kind of impossible to make an abstraction which does not suffer from such flaws in the presence of high precision timers which are in turn needed for high precision applications (not sure what, i guess realtime applications or things which need to measure super precise.. maybe audio / video ? ) the paper goes a bit further and imo is a bit simpler to read than the original spectre / meltdown papers.

Paper and discussion history. A mention is not an endorsement.

Spectre is here to stay: An analysis of side-channels and speculative execution — mentioned by comex

Wed, 23 Oct 2019 21:17:08 GMT

That’s Meltdown, not Spectre. Meltdown arguably does fit your description, but AFAIK the cost of checking permissions in the right place is almost zero, so it’s arguably better described as “we never realized it would be dangerous to not check permissions here” than “we skipped the check for performance’s sake”. (AMD processors were not vulnerable to Meltdown.) Spectre, on the other hand, is sort of an inherent flaw of speculative execution (not related to permissions checks). Speculative execution itself is definitely a shortcut, but it’s a shortcut that’s crucial to the performance of all…

Paper and discussion history. A mention is not an endorsement.

Spectre is here to stay: An analysis of side-channels and speculative execution — mentioned by rrss

Tue, 03 Sep 2019 14:31:15 GMT

> there is no way to know as a kernel if two things that are security sensitive relative to each other The kernel has a way, and it is process isolation. The kernel doesn't care if you want two threads in the same process to be isolated from one another - that's your problem, not the kernel's. Anyway, thread isolation already doesn't work even without hyperthreading-specific attacks: "we have discovered that untrusted code can construct a universal read gadget to read all memory in the same address space through side-channels. In the face of this reality, we have shifted the security model of…

Paper and discussion history. A mention is not an endorsement.

Spectre is here to stay: An analysis of side-channels and speculative execution — mentioned by the_why_of_y

Sun, 21 Jul 2019 11:34:27 GMT

You could do that (see Singularity OS [0] and Midori [1]), but recently it was discovered that it wouldn't work on modern out-of-order CPUs due to Spectre [2]. [0] https://research.cs.wisc.edu/areas/os/Seminar/schedules/pape... [1] http://joeduffyblog.com/2015/11/03/blogging-about-midori/ [2] https://arxiv.org/abs/1902.05178

Paper and discussion history. A mention is not an endorsement.

Spectre is here to stay: An analysis of side-channels and speculative execution — mentioned by tntn

Sat, 01 Jun 2019 02:49:55 GMT

How does this do anything to alleviate spectre and friends? Software isolation doesn't work (https://arxiv.org/abs/1902.05178), so the only protection you get is from process isolation, and I assume this doesn't change the OS mechanisms to enforce that.

Paper and discussion history. A mention is not an endorsement.

Spectre is here to stay: An analysis of side-channels and speculative execution — mentioned by magicalhippo

Fri, 26 Apr 2019 13:40:10 GMT

> We don't need separate processes if the language we use is inherently safe (e.g., modern Common Lisp). I note the year of the article, which was before Spectre and friends showed that this is not a reasonable assumption these days[1]. So does this mean LispOS is doomed? [1]: https://arxiv.org/abs/1902.05178

Paper and discussion history. A mention is not an endorsement.

Spectre is here to stay: An analysis of side-channels and speculative execution — mentioned by rmbryan

Tue, 23 Apr 2019 13:24:51 GMT

The original paper is extraordinary: https://arxiv.org/pdf/1902.05178.pdf

Paper and discussion history. A mention is not an endorsement.

Spectre is here to stay: An analysis of side-channels and speculative execution — mentioned by benol

Tue, 19 Mar 2019 15:10:06 GMT

Considering the recent "Spectre is here to stay" paper [1], can anyone comment on whether Firefox should be considered secure until the work on process-per-site lands (I believe they are working on it)? [1] https://arxiv.org/abs/1902.05178

Paper and discussion history. A mention is not an endorsement.

Spectre is here to stay: An analysis of side-channels and speculative execution — mentioned by Tepix

Fri, 01 Mar 2019 14:06:56 GMT

Nice list. They may want to take Spectre off the list, however. It seems only hardware fixes actually work: https://arxiv.org/pdf/1902.05178.pdf Signify sounds great. It has been ported to Linux: https://github.com/Blitznote/signify

Paper and discussion history. A mention is not an endorsement.

Spectre is here to stay: An analysis of side-channels and speculative execution — mentioned by guiambros

Sat, 23 Feb 2019 01:49:35 GMT

The conclusion is beautifully scary: "Computer systems have become massively complex in pursuit of the seemingly number-one goal of performance. We’ve been extraordinarily successful at making them faster and more powerful, but also more complicated, facilitated by our many ways of creating abstractions. The tower of abstractions has allowed us to gain confidence in our designs through separate reasoning and verification, separating hardware from software, and introducing security boundaries. But we see again that our abstractions leak, side-channels exist outside of our models, and now, down…

Paper and discussion history. A mention is not an endorsement.

Spectre is here to stay: An analysis of side-channels and speculative execution — mentioned by smueller1234

Sat, 23 Feb 2019 00:14:53 GMT

Maybe link to the paper this is based on instead? https://arxiv.org/abs/1902.05178

Paper and discussion history. A mention is not an endorsement.

Spectre is here to stay: An analysis of side-channels and speculative execution — HN submission

Fri, 15 Feb 2019 12:43:35 GMT

Spectre is here to stay: An analysis of side-channels and speculative execution

169 points; 69 discussion replies on HN. Paper and source history. A submission is not an endorsement.