|
|
Subscribe / Log in / New account

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.


to post comments

Spectre V1 defense in GCC

Posted Jul 11, 2018 13:13 UTC (Wed) by matthias (subscriber, #94967) [Link] (1 responses)

> 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 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?

Spectre V1 defense in GCC

Posted Jul 11, 2018 14:16 UTC (Wed) by epa (subscriber, #39769) [Link]

I think it could only be exploited if there were other code running which could sniff for the effects of speculation (changes in the cache state). That code could be in another userland process if it has addresses which happen to share the same cache lines -- I think?


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds