| 1 |
Rich Freeman <rich0@g.o> wrote: |
| 2 |
> On Tue, May 8, 2018 at 4:19 AM Martin Vaeth <martin@×××××.de> wrote: |
| 3 |
> |
| 4 |
>> Rich Freeman <rich0@g.o> wrote: |
| 5 |
>> > |
| 6 |
>> > Higher-level languages will probably become nearly immune to Spectre |
| 7 |
> just |
| 8 |
>> > as most are nearly immune to buffer overflows. |
| 9 |
> |
| 10 |
>> Quite the opposite: Higher-level languages *always* do some checks |
| 11 |
>> for array-length etc, and it is the _checks_ which are vulnerable. |
| 12 |
>> You can only make them non-vulnerable by making them horribly slow |
| 13 |
>> (by omitting speculative execution completely for the corresponding |
| 14 |
>> conditionals). |
| 15 |
> |
| 16 |
> Sure, but my point is that you CAN make them non-vulnerable by changing the |
| 17 |
> compiler. |
| 18 |
|
| 19 |
Which would be the horribly slow case I mentioned above. |
| 20 |
|
| 21 |
> On the other hand, if somebody manually does a range check in C the only |
| 22 |
> way to fix it is to either fix the source code |
| 23 |
|
| 24 |
If slowness is not the issue, one could fix the C compiler in the same way |
| 25 |
by avoiding speculative exection for every conditional jump. |
| 26 |
|
| 27 |
As mentioned, I wonder why gcc/clang do not yet support this |
| 28 |
horribly slow but spectre-safe option. It can't be that hard to |
| 29 |
implement in the actual code-producing back-end. Only possible |
| 30 |
optimization of that code (catching unnecessary cases or |
| 31 |
preferring alternative code-paths if there are two many bad |
| 32 |
cases) might be tricky, but perhaps this could be postponed |
| 33 |
in a first implementation: safety first. |
Archives