- these issues are inherent in speculative execution
- speculative execution is critical for performance
- therefore these issues are really hard to eliminate
- these attacks can break out of VM's
Are these points correct? Because if they are, it seems like a safe conclusion that most of the cloud will be compromised.
Also, as far as I'm aware the sort of shallow speculation used by most in order processors doesn't tend to provide enough of a window for an attacker to exfiltrate data after loading it, though it's possible that I'm unaware of one that does.
Can these be detected in the same manner that valgrind can detect buffer overflows?
I don't know of any VLIW design that's vulnerable to these whether they're open pipeline like the Mill or Transmeta lineage or closed like the Itanium. Or the Hexagon which uses round robin multi-threading to make every operation look like 1 cycle so it can be both ;)
EDIT: Oh, I should also point out that it isn't just branches. A pipelined processor is also speculating if it continues issuing institutions before memory accesses are fully resolved, because those accesses might result in exceptions that render the following instructions invalid.
Some chips (mostly Intel) have seen pretty big performance drops. But nothing like 50%+.
Cloud could cost 50% more. We will bear it.
Likely far less impact than this, as much of the cloud isn't CPU-bound, right?
This is an idea that I personally love, but that hasn't fared well so far. Compilers are not as good as assigning instruction schedules statically as hardware can do dynamically.
I can understand "not being able to statically compile it because every architecture is different" but, presuming our compiler compiled to a specific platform - why wouldn't it be able to dynamically rearrange in, say, a JITted fashion using exactly whatever logic is available in the hardware.
I'm not sure on if and how well these things can be mitigated in the hypervisor, but given that current mitigations don't seem to work in all cases, I'm not hopeful for the x86 speculative execution.
Perhaps new cpu instructions?
- nspex - No SPeculative EXecution from here
- espex - Enable SPeculative EXecution from here
Even that does not work.
If the kernel can do speculative execution and user code can cause the kernel to do work (that's kind of the kernel's job), then user code can cause the kernel to leak secret data. This was one of the first set of attacks.