Rich Freeman <ri...@gentoo.org> wrote: > On Tue, May 8, 2018 at 4:19 AM Martin Vaeth <mar...@mvath.de> wrote: > >> Rich Freeman <ri...@gentoo.org> wrote: >> > >> > Higher-level languages will probably become nearly immune to Spectre > just >> > as most are nearly immune to buffer overflows. > >> Quite the opposite: Higher-level languages *always* do some checks >> for array-length etc, and it is the _checks_ which are vulnerable. >> You can only make them non-vulnerable by making them horribly slow >> (by omitting speculative execution completely for the corresponding >> conditionals). > > Sure, but my point is that you CAN make them non-vulnerable by changing the > compiler.
Which would be the horribly slow case I mentioned above. > On the other hand, if somebody manually does a range check in C the only > way to fix it is to either fix the source code If slowness is not the issue, one could fix the C compiler in the same way by avoiding speculative exection for every conditional jump. As mentioned, I wonder why gcc/clang do not yet support this horribly slow but spectre-safe option. It can't be that hard to implement in the actual code-producing back-end. Only possible optimization of that code (catching unnecessary cases or preferring alternative code-paths if there are two many bad cases) might be tricky, but perhaps this could be postponed in a first implementation: safety first.
