| 1 |
On Tue, Mar 10, 2020 at 8:20 PM Michael <confabulate@××××××××.com> wrote: |
| 2 |
> |
| 3 |
> What-ever I may buy in the future, I'll make sure it does not contain Intel |
| 4 |
> inside ... |
| 5 |
> |
| 6 |
> https://www.theregister.co.uk/2020/03/10/lvi_intel_cpu_attack/ |
| 7 |
> |
| 8 |
|
| 9 |
It seems like the PRIMARY vulnerability here is with SGX, which I |
| 10 |
doubt most of us care about too much (does Linux even support it)? |
| 11 |
Apparently it needs to be enabled in your firmware to even work. |
| 12 |
|
| 13 |
However, it seems that SGX just makes it much easier to execute the |
| 14 |
attack, and the attack is not limited to SGX, so this still is an |
| 15 |
issue for everybody. |
| 16 |
|
| 17 |
The mitigations are indeed crazy. It seems like any instruction that |
| 18 |
accesses memory potentially has to be fenced, including the RET |
| 19 |
instruction (which pops the return value off the stack, which is |
| 20 |
memory). This is still pretty fresh, so it is hard to gauge how |
| 21 |
practical these concerns are. If you can narrow down the areas of |
| 22 |
code that are sensitive and be more selective with the mitigation that |
| 23 |
will of course greatly reduce the performance cost. If you have to |
| 24 |
basically banish the RET instruction in your compiler that can't be |
| 25 |
cheap. I could also see optimizations to inline calls become more |
| 26 |
prevalent. |
| 27 |
|
| 28 |
I'm not sure if AMD has issues like this that nobody has found yet, or |
| 29 |
if they avoided this problem in their designs. |
| 30 |
|
| 31 |
Oh, and this seems like potentially a bigger impact than meltdown as |
| 32 |
this isn't about reading memory - it is about effectively WRITING it. |
| 33 |
Not so much writing the memory itself from my initial read so much as |
| 34 |
making the CPU think it read something from memory that wasn't there, |
| 35 |
which is very similar. Indeed, with the RET instruction you're |
| 36 |
modifying a value that is going to go into the instruction pointer so |
| 37 |
you can basically hijack code execution. Of course, this still |
| 38 |
requires that you have executable code addressable by the process to |
| 39 |
jump to (which probably means in a page not marked with NX). |
| 40 |
|
| 41 |
It will be very interesting to see where this goes. I'm sure lkml is |
| 42 |
already buzzing... |
| 43 |
|
| 44 |
-- |
| 45 |
Rich |
Archives