| 1 |
On Tue, May 8, 2018 at 4:19 AM Martin Vaeth <martin@×××××.de> wrote: |
| 2 |
|
| 3 |
> Rich Freeman <rich0@g.o> wrote: |
| 4 |
> > |
| 5 |
> > Higher-level languages will probably become nearly immune to Spectre |
| 6 |
just |
| 7 |
> > as most are nearly immune to buffer overflows. |
| 8 |
|
| 9 |
> Quite the opposite: Higher-level languages *always* do some checks |
| 10 |
> for array-length etc, and it is the _checks_ which are vulnerable. |
| 11 |
> You can only make them non-vulnerable by making them horribly slow |
| 12 |
> (by omitting speculative execution completely for the corresponding |
| 13 |
> conditionals). |
| 14 |
|
| 15 |
Sure, but my point is that you CAN make them non-vulnerable by changing the |
| 16 |
compiler. |
| 17 |
|
| 18 |
On the other hand, if somebody manually does a range check in C the only |
| 19 |
way to fix it is to either fix the source code (which is about as likely to |
| 20 |
work as trying to prevent programmers from create buffer overflows), or use |
| 21 |
heuristics to figure out what is going on and apply the fixes |
| 22 |
automatically. That is going to be just as slow, and the compiler might |
| 23 |
not be able to catch every situation where it applies. |
| 24 |
|
| 25 |
The compiler doesn't have to guess where the range checks are in a |
| 26 |
high-level language because it is the compiler that is doing the range |
| 27 |
checks in the first place. |
| 28 |
|
| 29 |
-- |
| 30 |
Rich |
Archives