okay i actually fucking LOVE this bug so much omg. this is even better than i thought it was. sorry, i apologize, i'm gonna fangirl a little bit here sorry
first of all: the attack isn't intel-specific. it's not (QUITE) a hardware bug. it's extraordinarily clever.
if i understand right: the simplest variant works like this.
basically all modern CPUs speculate loads far beyond the point where they know it's safe. this is necessary for even half-decent performance in a big pipeline.
basically all modern CPUs speculate loads far beyond the point where they know it's safe. this is necessary for even half-decent performance in a big pipeline.
so if you do this:
a = x[4];
b = y[a];
c = z[b];
it may load "c" long before it even knows the load of "a" was safe!
this is fine as long as it can roll things back in the case the first load failed. completely normal
a = x[4];
b = y[a];
c = z[b];
it may load "c" long before it even knows the load of "a" was safe!
this is fine as long as it can roll things back in the case the first load failed. completely normal
the catch here is: doing the load puts that data in the cache.
so... imagine you're not supposed to be able to know "b" because it's in kernel memory.
it'll load b, and then load z[b] to get c. then at some point it will fail and roll back.
so... imagine you're not supposed to be able to know "b" because it's in kernel memory.
it'll load b, and then load z[b] to get c. then at some point it will fail and roll back.
but this will have a side effect: the chunk of memory containing "c" will end up getting loaded into cache.
the rollback *isn't total*.
it's like the CPU went ahead to the next page of an assignment before it was supposed to, but didn't completely hide that fact.
the rollback *isn't total*.
it's like the CPU went ahead to the next page of an assignment before it was supposed to, but didn't completely hide that fact.
and given the right circumstances, you can use this to recover "b", one bit at a time.
you can now recover arbitrary data from any memory in the system. you win.
(there's other variants that use branch prediction, etc to apply the approximate same attack. but the core idea is the same: construct a case where the CPU leaves a visible trail of its speculative execution)
someone who read more of the article than me tell me if i'm wrong tho
oh, and one last thing: the thing that gets me most about this exploit is it isn't really a single exploit, it's a whole *category* of exploits. verifying that no further attacks exist sounds EXTREMELY hard.
i kinda get why they had to use such a big software hammer on this: i'd be reaaallllyyy nervous about some clever trick solution purporting to patch up an infinity of tiny holes
hey @erincandescent, feel like writing some verilog verification proving that it's impossible to pass any knowledge from kernel to userspace, , , , ,
also if you like this kind of tech nonsense it's probably worth reading the whole thing, since they did stuff like this
oh i guess i should add: AMD's claim that they're safe is bc they made the design choice not to allow speculation past privilege boundaries. which isn't airtight but is a pretty hella solid chunk of safety
