Spectre V1 defense in GCC
Spectre V1 defense in GCC
Posted Jul 11, 2018 0:41 UTC (Wed) by lambda (subscriber, #40735)In reply to: Spectre V1 defense in GCC by roc
Parent article: Spectre V1 defense in GCC
There is another example which uses return *__builtin_speculation_safe_value (mem + untrusted);
so that it will speculate a NULL pointer dereference instead, if you can't afford to leak mem[0]
, or are in code where you can't tell if leaking mem[0]
is safe.
Point taken that the first example isn't necessarily good if you, say, have a zero-length slice that you're bounds checking against, or something of the sort.
Luckily, this intrinsic should only need to be used in relatively few places, which can be intensively code reviewed; anything which allows code to execute within a process but shouldn't have access to all of the data in the process, such as a JavaScript or wasm engine. I feel like it shouldn't be too hard to encapsulate most such bounds checks into a relatively small number of functions, which could be thoroughly checked.
Posted Jul 11, 2018 13:13 UTC (Wed)
by matthias (subscriber, #94967)
[Link] (1 responses)
I am less optimistic. Actually this affects all parts of code that deal with user input, not only scripting languages. A JPEG image needs to be interpreted to be printed on screen. If I tamper with the image, I might trigger speculative execution in the JPEG library. Certainly harder to exploit than using JavaScript, but is it impossible?
Posted Jul 11, 2018 14:16 UTC (Wed)
by epa (subscriber, #39769)
[Link]
Spectre V1 defense in GCC
Spectre V1 defense in GCC