3 ms·
It feels like you should be able to make a version of branch prediction with speculative execution that behaves the same as the non-speculative-fo-real executio
by revelation 9y ago
It feels like you should be able to make a version of branch prediction with speculative execution that behaves the same as the non-speculative-fo-real execution. As in accessing memory you can't actually access doesn't cause a load and does not speculatively execute further instructions with data you weren't supposed to be able to load in the first place.
This is after all what the real execution does; when you try to load from a memory address that you are not allowed to, it does not cause a memory load, it does not affect the cache and it does not continue executing instruction but instead generates a page fault. We skip the page fault thing in speculative execution, obviously, but we shouldn't continue normal control flow.
I'm sure that is a lot more difficult to implement in silicon and may end up negating the performance benefits of speculative execution, but right now it feels like not having the memory protection in place in speculative execution is a performance hack that exploded in all our faces.
- Gracana 9y agoIn spectre, the victim process is coerced (via branch misprediction, in their first example) to speculatively access its own memory, resulting in side-effects that you can measure to determine the memory contents. No violation of memory protection needed.