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

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…

sweetjulyAug 13, 2023View on HNParent context

> 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…

titzerMar 31, 2022View on HNParent context

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

jssmithOct 10, 2021View on HNParent context

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…

ddworkenMar 24, 2021View on HNParent context

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…

ddworkenMar 12, 2021View on HNParent context

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…

ddworkenMar 12, 2021View on HNParent context

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.

titzerMar 10, 2021View on HNParent context

> 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…

ENOTTYDec 4, 2020View on HNParent context

> 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

titzerJul 28, 2020View on HNParent context

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…

vectorEQDec 27, 2019View on HNParent context

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…

comexOct 23, 2019View on HNParent context

> 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…

rrssSep 3, 2019View on HNParent context

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]…

the_why_of_yJul 21, 2019View on HNParent context

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.

tntnJun 1, 2019View on HNParent context

> 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]…

magicalhippoApr 26, 2019View on HNParent context

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

rmbryanApr 23, 2019View on HNParent context

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

benolMar 19, 2019View on HNParent context

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

TepixMar 1, 2019View on HNParent context

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

smueller1234Feb 23, 2019View on HNParent context

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…

guiambrosFeb 23, 2019View on HNParent context