3 ms·

I respectfully disagree for two main reasons. Firstly, because the compiler is not transversal to all processes currently executing on the system at runtime, so

by qubex 9y ago

I 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 ago
Spectre 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 ago
  Thinking 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.

by qubex 9y ago

gpderetta 9y ago

Spectre 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 ago
Thinking 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.