[gentoo-user] Re: Spectre-NG

[Martin Vaeth]

Rich Freeman <rich0@g.o> wrote:
> On Thu, May 10, 2018 at 1:34 AM Martin Vaeth <martin@×××××.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.