| 1 |
On Thu, Jan 4, 2018 at 9:12 PM, Walter Dnes <waltdnes@××××××××.org> wrote: |
| 2 |
> |
| 3 |
> There are 2 vulnerabities at play here, both caused by speculative |
| 4 |
> execution... |
| 5 |
|
| 6 |
Actually, there are 3 related ones, with two names between them. |
| 7 |
Can't imagine why there is so much confusion... |
| 8 |
|
| 9 |
> 2) "Spectre" is the reading, by one userland process, of memory |
| 10 |
> belonging to another userland process. Since this does not require |
| 11 |
> jumping to kernel privilege level, AMD's ring-level permission checking |
| 12 |
> is not invoked, and AMD cpus are vulnerable. Think "cross-site-scripting |
| 13 |
> on steroids", or "cross-process memory access" on your PC. |
| 14 |
|
| 15 |
Spectre describes two variants. It can be used from userland to |
| 16 |
kernel, or between two userland processes. However, it doesn't |
| 17 |
require jumping priv levels - it is a side-channel leak. |
| 18 |
|
| 19 |
Variant 1 requires that code be executed in the context of the process |
| 20 |
being attacked. So, there isn't a cross-priv issue here - just a |
| 21 |
"skipped" bounds check. When the out-of-bounds memory is accessed the |
| 22 |
CPU sees that it is running in the correct priv level, which is |
| 23 |
probably why AMD is vulnerable. |
| 24 |
|
| 25 |
I'm a little hazy on variant 2, but I believe that this also requires |
| 26 |
execution in the target context. I suspect it doesn't run on AMD64 |
| 27 |
due to some details of how its CPUs actually work - it might not |
| 28 |
speculatively do an indirect call, or it might not get far enough into |
| 29 |
it to affect the cache. |
| 30 |
|
| 31 |
> This is a problem that's associated with "speculative execution". I |
| 32 |
> wonder how much of a performance hit it would be to turn off speculative |
| 33 |
> execution. That would probably require at least a microcode/firmware |
| 34 |
> update, if not a new cpu. |
| 35 |
|
| 36 |
Turning it off entirely would be a huge performance hit. However, |
| 37 |
Intel announced that they're going to add instructions to selectively |
| 38 |
turn it off, presumably so that compilers can use this in situations |
| 39 |
where Spectre is possible. That will require a microcode change. It |
| 40 |
sounds like there are also workarounds. For example, Intel suggests |
| 41 |
doing an lfence after a bounds check to defeat variant 1, and I've |
| 42 |
seen comments that suggest this works for some Intel users. It |
| 43 |
doesn't seem to work on my Phenom II or Ryzen 5. Go figure, Intel |
| 44 |
promoting an Intel-specific fix, though to be fair this is all rushed |
| 45 |
and they might not even realize it doesn't work on AMD, or maybe I'm |
| 46 |
doing it wrong. (My code is at: |
| 47 |
https://gist.github.com/rich0/056eebebc1f88a624e36680e0de36011 ). |
| 48 |
|
| 49 |
-- |
| 50 |
Rich |
Archives