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 https://twitter.com/argvee/status/948682737057189888 …
-
This Tweet is unavailable.Show this thread
-
Replying to @FioraAeterna
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?
1 reply 0 retweets 0 likes -
Replying to @theJingster
i wrote this before the names/distinctions were out, but -- meltdown: using this technique to break VM protection (e.g. steal kernel memory)
1 reply 1 retweet 4 likes -
Replying to @FioraAeterna @theJingster
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
2 replies 1 retweet 6 likes -
Replying to @FioraAeterna @theJingster
the distinction here is that spectre *doesn't violate memory protections* and largely involves abusing existing code paths (ROP-style).
1 reply 0 retweets 5 likes -
Replying to @FioraAeterna
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?
1 reply 0 retweets 0 likes -
Replying to @theJingster
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
1 reply 1 retweet 3 likes -
Replying to @FioraAeterna @theJingster
spectre: there's no memory protection involved so good fxcking luck
1 reply 1 retweet 6 likes -
Replying to @FioraAeterna
Wow.
So what does this mean for cpu architecture?1 reply 0 retweets 1 like -
Just my 2c: Meltdown: Split supervisor/user pagetables seems to be the most obvious fix if changing the ISA is an option (this might be the direction RISC-V is going). Spectre: Run the JIT in a separate process that has no secret data mapped. That's a big SW change of course.
-
-
I wonder if this'll lead to weird OS features such as "restricted threads" which don't share the full page table with their parent process?
1 reply 0 retweets 2 likes -
I spend a lot of time thinking about that yesterday, but just having separate processes and then using traditional IPC to be explicit about the visible stuff seems much saner than everything else I was able to come up with..
1 reply 0 retweets 0 likes - Show 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.