Rich Freeman <ri...@gentoo.org> wrote: > On Thu, May 10, 2018 at 1:34 AM Martin Vaeth <mar...@mvath.de> wrote: > >> As a simple example, assume that you have read a password file >> into a string of your language and now access a single password. >> No matter, how you mark the end of the password (fixed-length, \0, \n, >> ...) speculative execution might always access the next password(s) >> unless you prevent it globally. Whether it is exploitable depends >> of course on other things. There is no difference to C. > > [...] I don't see how > having the next password speculatively read would on its own create a > vulnerability.
That's what I meant by "whether it is exploitable depends of course on other things". *Most* speculative executions are probably not exploitable, whether in C or any other language: you need a really unfortunate setup. However, to be on the really safe side you just have to prevent everything which might potentially exploitable. > You would also need some kind of indirect memory access > based on the speculatively-accessed data For the "classical" spectre (v2?) variant: In the "speculative" execution you copied more data. Exploitability depends completely on the subsequent code, i.e. what will happen with this data (and on whether an attacker can execute and time the whole function). However, everybody expected (and perhaps spectre-ng will confirm that) that there are a lot more of processor bugs involved with speculative execution: AFAIK, there were already reports that some internal processor bits were cleared/set depending on some results (i.e. meltdown type bugs). So maybe just doing the right thing in another process might reveal some information. Whether it is again possible to fix this in the kernel is unclear yet. > Consider: > > for x = 1 to 10 : y=5+3 : next x I don't understand what you want to say here. Of course, non-sensical code is not exploitable. The question is whether the compiler can recognize it. I haven't tried, but I am rather sure that the above loop disappears in C w/ gcc -O2 due to flow analysis (the constant assertion is pulled out and then the loop recognized as empty). > I still tend to think that the additional context around these memory > accesses that is available in a high-level language could be used by a > compiler The compiler needs to detect whether a speculative execution might be dangerous. This is similarly hard for every Turing-complete language; I do not see any language having a considerable advantage for this.
