Re: [gentoo-user] Re: Spectre-NG

[Rich Freeman]

On Wed, May 9, 2018 at 2:18 PM Martin Vaeth <martin@×××××.de> wrote:

> Rich Freeman <rich0@g.o> wrote:
> > On Tue, May 8, 2018 at 4:19 AM Martin Vaeth <martin@×××××.de> wrote:
> >
> >> Rich Freeman <rich0@g.o> 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