On Wed, May 9, 2018 at 2:18 PM Martin Vaeth <mar...@mvath.de> wrote: > 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. I'm saying that high-level languages can be made safe. You're saying that making high-level languages safe comes at a performance cost. These are not in contradiction. In fact the whole reason low-level languages still exist to this day (besides legacy code) is that most of the benefits of high-level languages come at a performance cost. Safety is just one of them. This is just as true for buffer overflows and memory management. If you take a lot of care, you can avoid the need for bounds checks on every array access. If you get it wrong, it can go horribly wrong. High-level languages tend to compensate by doing bounds checks even when they might not be needed. A lot of C programmers do the same with manual bounds checks or equivalent functions like strncpy. Again, I'm using buffer overflows as a more familiar analogy for others - I fully understand that bounds checks actually make Spectre worse. > If slowness is not the issue, one could fix the C compiler in the same way > by avoiding speculative exection for every conditional jump. Sure, but that is way more overhead than necessary. We only need to sterilize these for data passed from an untrusted source (I think). If a function declares an internal variable as a loop counter you don't need to disable speculative execution every time you increment and check the counter, and a loop is obviously exactly where you want to make this distinction. A low level language needs to use heuristics to try to figure out if a conditional jump is safe to speculatively execute (probably at compile time). A high-level language has access to more context and can probably more reliably determine which ones need protection. On the other hand it will probably do a lot more bounds-checking in general. I'm not sure which would end up costing more to make reliably safe. I think that in general language features that more clearly separate trusted vs untrusted data would probably help here. -- Rich
