I suspect that in a decade or two we will see speculative execution as we see shared mutable state today: a dangerous trap that should be best avoided in any new designs.
Or the mistake is that we're running different trust domains on the same CPU core.
All the various mitigations have already been very costly (something like a performance loss of 10% on current-gen CPUs?). Getting rid of speculative execution entirely would cost far, far more.
There is state shared between cores too though, at the very least L3, probably IOMMUs, etc. I wouldn’t be entirely surprised if there are issues we haven’t found that exist there.
> Or the mistake is that we're running different trust domains on the same CPU core.
It's very hard to not make that mistake. Think of all the websites running in your browser on your laptop. Isolating all those trust domains is going to be quite costly.
I feel like that became apparent with Spectre and Meltdown - they really opened the floodgates. I do wonder if there is some way to have formally proven correctness for speculation - a sort of analogue to the borrow checker in Rust if you like.
isn’t every attack based on speculative execution actually just an attack over shared mutable state? i.e., if the branch predictions, cache, and so on weren’t both shared and mutable, speculative execution wouldn’t be so problematic?
Indeed. Not just shared, but shared across security domains, e.g. across OS processes, or across the kernel / userspace boundary.
Speculating within one security domain would not be problematic, because anything such speculation allows to glean is already accessible normally. This is sort of similar to having a single reference to a mutable object, which is also safe.
