first of all: the attack isn't intel-specific. it's not (QUITE) a hardware bug. it's extraordinarily clever.
-
-
Show this thread
-
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.
Show this thread -
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
Show this thread -
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.
Show this thread -
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.
Show this thread -
and given the right circumstances, you can use this to recover "b", one bit at a time.
Show this thread -
you can now recover arbitrary data from any memory in the system. you win.
Show this thread -
(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)
Show this thread -
someone who read more of the article than me tell me if i'm wrong tho
Show this thread -
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.
Show this thread -
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
Show this thread -
hey
@erincandescent, feel like writing some verilog verification proving that it's impossible to pass any knowledge from kernel to userspace, , , , ,Show this thread -
also if you like this kind of tech nonsense it's probably worth reading the whole thing, since they did stuff like thishttps://twitter.com/mczub/status/948691303574810624 …
Show this thread -
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
Show this thread
End of conversation
New conversation -
-
-
As I understand, this is the basic concept for meltdown and spectre but everyone says spectre is harder to exploit and affects all processors, including AMD with no way to patch. Can you explain the difference between meltdown and spectre that explains this tidbit?
-
i wrote this before the names/distinctions were out, but -- meltdown: using this technique to break VM protection (e.g. steal kernel memory)
-
spectre: harder to exploit, more general, far harder to mitigate: using this technique to steal data *within* a program, e.g. a website's javascript stealing other data in the browser
-
the distinction here is that spectre *doesn't violate memory protections* and largely involves abusing existing code paths (ROP-style).
-
I see. That’s more clear. Thanks! I am still a bit confused why spectre can’t be patched w/out hardware architecture changes while meltdown can. These proposed hardware changes basically mean adding security checks prior to speculation right? So slower speeds vs. previous gen?
-
meltdown: unmap kernel memory before returning to userspace, thereby making speculation impossible. only possible to begin with on chips that allow speculation across privilege boundaries
-
spectre: there's no memory protection involved so good fxcking luck
-
Wow.
So what does this mean for cpu architecture? - 5 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.