3 ms·
Am I wrong in recalling that Itanium (IA-64) was an in-order architecture that relied on the compiler to explicate the potential for parallelism? Again, if I re
by qubex 9y ago
Am I wrong in recalling that Itanium (IA-64) was an in-order architecture that relied on the compiler to explicate the potential for parallelism? Again, if I recall correctly, the struggle to construct compilers that could do this versus the apparent success (and lack of trade-offs) in letting in-processor circuitry to reshuffle instructions at run-time was one of the main reasons why x86’s 64-bit extensions prevailed (the other being poor performance when running legacy x86 32-bit code).
Now it turns out that we really were benefitting from an advantage that had a hidden cost, not in terms of performance (though power might be a concern) but in terms of breaking the implicit model we have of how software executes, and that this disconnect in turn opens us to a host of “architectural” risks and metaphor breakages.
Maybe at this point we should consider reverting to the original plan and insist on compilers doing the legwork, so that approaches such as langsec have a hope of succeeding. Systems must be comprehensible (at least in principle) and reliably deterministic from the top all the way to the bottom.
- gpderetta 9y agoItianium relies on advance loads which is a form of speculation introduced by the compiler to perform competitively. It is not unlikely that this is as exploitable as spectre.
- qubex 9y agoI respectfully disagree for two main reasons. Firstly, because the compiler is not transversal to all processes currently executing on the system at runtime, so it isn’t a ”unifying step” that conjoins otherwise independent processes and can allow them to interact. Secondly, if the compiler were found to be leaking state between processes, simply changing the compiler’s logic would allow rectification of these issues (albeit at the expense of recompiling all software with the new compiler), with circuits etched onto a processor die one has no such opportunity. What could be (at least potentially) an open-source fix becomes the umpteenth binary blob from an opaque entity that tell us to ”trust them because [they] know best”.
- gpderetta 9y agoSpectre is not (at least not directly), a cross address space vulnerability (although it can be exploited in some cases from other address spaces). A JS JIT running on itanium that generates advanced loads before bounds checks will be vulnerable. It is true that it can be fixed purely by software changes, by simply avoiding issuing advanced loads [1], but then again software changes can also plug the spectre v1 vulnerability on OoO architectures by adding artificial dependencies on load-load sequences (see the WebKit mitigation article that was discussed here a few days ago). Both software fixes have potentially significant performance issues (more so on in-order architectures). So yeah, in-order CPUs are less microarchitecturally vulnerable [2] to spectre by default, but the compiler tricks required to make them competitive with OoO CPUs might reintroduce the issue. [1] In principle compiler issued prefetches and load hoisting can be an issue on OoO CPUs as well, but as these are less important for performance compilers can be more conservative. On the other hand some VLIW architectures have special instructions and architectural support (like Itanium ALAT) to make this load hoisting easier. [2] There are in-order ARM CPUs that have been reported to be affected though.
- gpderetta 9y agoThinking more about this, the vulnerability would be in any load issued speculatively which whose address depends on the result of a previous load. This can be detected at compile time and avoiding just this scenario it will not have such a performance effect as avoiding any speculative load.