Personal use usually involves a web browser, which usually executes untrusted javascript from the web. You won't find me disabling these mitigations on any of my workstations any time soon.
Yes, the original Javascript exploit from the paper still works, because the browser cannot mitigate this attack without just disabling parts of Javascript entirely which breaks Javascript.
With all current kernels built to mitigate these exploits, and all sane people running those kernels, there's no benefit in patching the browsers too, even if it were somehow possible, which for all intents and purposes it is not.
Well the link you provide doesnt use SharedArrayBuffer, it is used as part of the exploit if you read the original paper (as a method to make a high resolution timer)
You won't find a real world exploit that does something like reading a password, SSH key, etc. It would be like winning the lottery, then getting your money out 1 penny at a time for the next several decades. You can find "academic" PoC exploits that work under pristine conditions.
I'm not super familar with spectre, but i think the linked page is misinterpreting the vuln (hopefully someone will correct me if im totally out to lunch).
So the original js from the spectre paper was:
if (index < simpleByteArray.length) {
index = simpleByteArray[index | 0];
index = (((index * 4096)|0) & (32*1024*1024-1))|0;
localJunk ˆ= probeTable[index|0]|0;
}
The code looking a bit weird (all the |0) to ensure Chrome JITs it the correct way. My understanding of what happens, the loop goes a bunch of times while index is inside the simple byte array. After the last iteration, the processor speculatively executes the loop one more time than it should (branch misprediction). It eventually figures out the loop should end and undos the speculative execution. However that only happens after the loop has already started executing (where its not supposed to). During this improper execution, index is after the end of SimpleByteArray. index = simpleByteArray[index | 0] is then executed. index is now set to the value of some memory in the current process that the current JS is not supposed to access.
index = (((index * 4096)|0) & (3210241024-1))|0; is executed to spread the memory value out (we need all possible values to be in a separate cache line in probeTable later). We now execute localJunk ˆ= probeTable[index|0]|0;. localJunk is just there to prevent dead code elimination optimization. Since we are now indexing into probeTable at 4096 byte intervals, we have to fetch that value from memory. It then gets cached by processor. This all gets undone by the processor when it realizes that the branch was incorrect, except the cache changes are not undone. If we access anything else in the same 4096 bytes later on, the access is a tiny bit quicker.
The exploit is, that after all that setup, we try accessing each 4096 byte region of probeTable, to see which one is fastest. We can than conclude that was the value of index during the branch misprediction and thus the value of that byte of memory we aren't supposed to see.
If we do this a lot, we can read the rest of the process's memory. The hope is we will be able to find cookies related to other websites currently open, and then do evil things with them.
This attack no longer works because browsers disabled SharedArrayBuffer, which provided the really precise timer. The timing difference is very small so you need a very fine grained timer to make it work. It should also be noted that this variant of spectre is in-process only. Some versions of meltdown/spectre allow accessing memory of other processes, but as far as i understand this version is in process only.
I hope that made sense, and i hope i didnt screw that up.
Eh. The amount of performance you sacrifice in order to mitigate the very small chance of actually running across any javascript in the wild that a) successfully exploits you, and b) actually retrieves anything worthwhile, just isn't worth it. It's such a tiny risk that it's really only worth mitigating against if you're paranoid or handling particularly sensitive information.
Again, JS can no longer perform this exploit. Browser vendors have disabled (made inoperable) high resolution timing. It's now at 1ms resolution. Not enough timing resolution to mount the attack.
postMessage cannot provide a reliable timing signal since it goes on the task queue on the receiving end (in the main thread) along with other pending events, and even if there were no other events, there is latency noise in postMessage due to the fact that the web worker is not the only thread running on the CPU. Some suggest that the attack would only take more time as the attacker has to collect a bigger sample, and factor out the noise, but I haven't seen a public exploit based on that.
the minimum essential behavior to implement a feature is one that takes into consideration keeping the user safe from attacks... you could call that bloat, but I wouldn't be sarcastic about it: if you can make the mitigations more concise, you can contribute your ideas, no one stopping you.
Shared Array Buffers are enabled by default in Chrome now, because Chrome has separate mitigations against Spectre.
To the best of my knowledge, it does not have mitigations against Meltdown because it assumes those protections will be implemented at the OS/firmware level, but if anyone has more experience or insight than me on that front, they're welcome to correct me.
In any case, you're making a kind of wild assumption that the type of user who disables a security feature from their OS to get a speed increase won't also likely disable security features like Site Isolation in their browser when they hear that those features increase Chrome's memory usage by somewhere between 10-20%.
So there's a known exploit in CPUs and your response is "prove to me it can be exploited or I won't use mitigations"? In 2020 no less? What can you possibly be doing that would even notice the slowdown from these mitigations? Virtually everything we actually do will be bottlenecked by something else long before the CPU becomes an issue.
In my mind javascript is so many layers removed from machine code that it would be insanely hard to even break out of the chrome sandbox let alone glean anything useful from other running processes.
"We were not able use these techniques in Firefox, as they recently reduced the timer resolution to 2ms. The techinque presented here is potentially relevant even for this timer resolution, but some parameter tweaking is required.?"
AFAIK, Chrome's highest resolution is also in the ms range.
I have some thoughts, too, but thoughts don't amount to a working exploit. Show me a currently working exploit, that is in the open. As far as state actors developing such exploits, there are a ton of holes in that scenario at every layer in the stack.
HN wouldn't let me nest another response. This is in regards to "Timers aren't necessarily even a requirement"
<<you can busyloop and count iterations of that instead as a “timer”>>
Assuming you're the only job running on the CPU, which is not the case. Threads are not running continuously. But again, if there is a working exploit in the browser then show us. Talk is cheap.
I am aware that threads don't run continuously; scheduling just makes this worse just like timer jittering does. Sadly, I'm not the kind of person who can drop full, working exploits against unpatched browsers in response to Hacker News comments; I just have a passing interest in the field :(
performance.now resolution in Chrome is between 1 and 2 ms, I believe, with jitter. If they have a working POC for Chrome why not demonstrate the full exploit and force the Chromium team to rethink their mitigations? Lots of people talking possibilities but zero working exploits in the open. That's not a good ground for rational debate.
Timers aren't necessarily even a requirement to exploit Spectre: https://news.ycombinator.com/item?id=22831067. It's pretty hard to protect against this in general unless you generate retpolines.
