Comment by rybosworld
Comment by rybosworld 2 days ago
I'm no expert on TLB invalidation bugs but generally they allow for an attacker to read/write arbitrary memory.
https://googleprojectzero.blogspot.com/2019/01/taking-page-f...
Comment by rybosworld 2 days ago
I'm no expert on TLB invalidation bugs but generally they allow for an attacker to read/write arbitrary memory.
https://googleprojectzero.blogspot.com/2019/01/taking-page-f...
Random access is arbitrary access, given enough time. You can try over and over again until you get lucky.
Imagine I'm a user with local shell access trying to read a secret owned by root. Maybe I can't read the secret, but I can do something which makes another program read the secret. If I can make that program swap (perhaps by wasting a bunch of RAM to create memory pressure), and swapping has some probability of triggering a TLB invalidation bug that lets me see the old page, I win, although it might take awhile.
Wow. So V8 actually back to optimizing the entire bytecode region in one fell swoop?
I had thought that such V8 optimization were still occuring (as of Chrome Blink81/SparkPlug) during JavaScript execution of untouched bytecode as a form of overhead reduction of its startup.
https://egbert.net/blog/articles/javascript-jit-engines-time...
I don't mean to be a pedant, so someone please correct me if I'm wrong, but I don't think TLB mishandling would result in arbitrary memory access (I suppose in the strictest sense arbitrary can just mean random, but generally I have understood it to imply that the address can be attacker controlled, which a stale TLB wouldn't allow).
Unless you're like Microsoft (from your link) and accidentally leave the page tables writable from userspace for 2 months. But that's not really a TLB error, that's just L-O-L, wow!