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