4 ms·
Eliminating speculation entirely would be an utter disaster for performance, more than a factor of 10. Eliminating speculation across certain security boundari
by Symmetry 8y ago
Eliminating speculation entirely would be an utter disaster for performance, more than a factor of 10. Eliminating speculation across certain security boundaries seems to be viable and not too horrible from a performance standpoint, though you have to be careful to get the boundaries and I imagine this'll be something like buffer overflow attacks where we occasionally find new ones that have to be patched.
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.
- StreamBright 8y agoGiven the CPU architectures we are currently using yes. There are other architectures not affected by it like Mill.
- pkaye 8y agoHow does the Mill architecture handle branch prediction?
- Symmetry 8y agoIt speculates of course but because the speculation is so shallow it can't read then pass on privileged information before the mis-speculation is caught. 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.
- pkaye 8y agoWhat about it terms of performance given this limited speculation?
- Symmetry 8y agoI was counting those under shallow in order processors. The ARM A8 was vulnerable and I'd guess the POWER 6 was as well. But the A53s you've got in a modern phone are safe. 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 ;)
- cwzwarich 8y agoBoth Itanium and Mill support load speculation, which introduces Spectre-like vulnerabilities depending on how it is used. Someone on the Mill team said they had to make a compiler change for this: https://news.ycombinator.com/item?id=16125519 https://news.ycombinator.com/item?id=16125519
- Symmetry 8y agoYeah, if the compiler hoists both loads to before the check that would be a problem. But that's not really anything tied to the architecture, you could have the same problem with the prelude of an unrolled loop on a conventional machine.
- cwzwarich 8y agoThe same code would be an ordinary compiler correctness bug on a conventional architecture, because the second load could trap when reading from an invalid address. Itanium and Mill offer instructions that don’t trap, return an invalid value instead, and allow the trap to be forced later (if desired). This is fundamentally new functionality that exposes new vulnerabilities if it is used in certain ways.
- Symmetry 8y agoAh, right, that makes a lot of sense.
- gpderetta 8y ago
- stcredzero 8y agoEliminating speculation across certain security boundaries seems to be viable and not too horrible from a performance standpoint, though you have to be careful to get the boundaries and I imagine this'll be something like buffer overflow attacks Can these be detected in the same manner that valgrind can detect buffer overflows?