5 ms·
Given the CPU architectures we are currently using yes. There are other architectures not affected by it like Mill.
by StreamBright 8y ago
Given 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 agoSure, the problem is those optimizations are critical to make in order machines competitive. The idea of Itanium and friends was about moving the complrxity to the compiler. Speculation and dependency breaking is critical for performance, whether it is done by the compiler, cpu or programmer.
- gpderetta 8y agoI believe that Nvidia Denver, an in order VLIW design is vulnerable. In the case of Denver the speculation is mostly done in the firmware JIT frontend, but I wouldn't be surprised that the aggressive optimizations done by compilers to make VLIW and in order CPUs are similarly exploitable.
- Symmetry 8y agoI hadn't been thinking of the JIT frontend. It's fair to call that part of the architecture and yeah, I can see how it could be vulnerable to Spectre.