3 ms·
We can't really get rid of speculative execution, but we will effectively need to get rid of the idea that you can run untrusted code in the same process as dat
by Negitivefrags 8y ago
We can't really get rid of speculative execution, but we will effectively need to get rid of the idea that you can run untrusted code in the same process as data you want to keep secure.
It's interesting that the future predicted by excellent (and entertaining) talk The Birth & Death of Javascript [1] will now never come to pass.
[1] https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
- wnoise 8y ago> We can't really get rid of speculative execution Why not? > but we will effectively need to get rid of the idea that you can run untrusted code in the same process as data you want to keep secure. If we accept that, then we also need to get rid of the idea that we can branch differently in trusted code based on details of "untrusted data".
- nhaehnle 8y agoYour last point is basically what Spectre v1 mitigations are all about, at least if you throw in the word "speculation" somehow. The rule is: don't speculate past branches that depend on untrusted data (though there are certain additional considerations about what the speculated code would actually do). It's just that there are a lot of branches that don't depend on untrusted data. Speculatively executing past them is perfectly fine and extremely valuable for performance. That's why nobody wants to get rid of speculative execution.
- int_19h 8y agoIt sounds like what we really need is a memory model that reflects this notion of trusted and untrusted data. The "evil bit", basically, but for real.