3 ms·
The mitigations are to disable SharedArrayBuffer and severely round performance.now(). Not good that there aren’t other less intrusive ways to mitigate.
by dannyw 9y ago
The mitigations are to disable SharedArrayBuffer and severely round performance.now(). Not good that there aren’t other less intrusive ways to mitigate.
- kibwen 9y agoI don't get the impression that those are the full extent of the changes though; I think those two were called out only because they're API changes rather than implementation details. Haven't checked the code so I could be wrong, of course.
- deleted 9y ago[deleted]
- deleted 9y ago[deleted]
- mirashii 9y agoA little bit more info can be found here [1]. In particular, site isolation [2] will also assist in protecting against this vulnerability. [1] https://support.google.com/faqs/answer/7622138#chrome https://support.google.com/faqs/answer/7622138#chrome [2] http://www.chromium.org/Home/chromium-security/site-isolation http://www.chromium.org/Home/chromium-security/site-isolatio...
- jchw 9y ago> ...severely round performance.now(). This sucks, and is a side-effect that I didn't even think about. I guess it's probably pretty effective, but it will make benchmarking a lot harder, since you'll probably now have to do a lot more runs.
- user5994461 9y agoDoubt that. The Firefox news said they will round to 20 us. That's much more accurate than necessary to benchmark any software code.
- gchadwick 9y agoIf it was a big issue you can always introduce a 'benchmark mode' switch that allows you to put resolution back into the counter when you want to run a benchmark. Display a 'WARNING BROWSER INSECURE IN THIS MODE' banner for good measure.
- aidenn0 9y agoThat can't be right because they already round performance.now() so the Spectre attack didn't use it (it instead used a webworker with a tight-loop incrementing a counter)
- olliej 9y agothe tight loop iteration used a shared array buffer to provide a high resolution timer, specifically to deal with the obvious fix of truncating precision of performance.now(). The reason for /further/ truncating performance.now() is that the relative cost in this attack means that you don't need as much precision as was needed for the original (page table? I think) attack. A SAB timer just needs to increment a counter in one thread and read it in the host thread and the granularity is however long it takes to get through a for-loop.
- aidenn0 9y agoThanks, I missed how important SAB was to their webworker timer.
- DannyDaemonic 9y agoWould it be practical to run each javascript VM in it's own sandbox? Edit: Apparently you can already do something like this. Seems to be an option for Chrome starting with 63. (Which was an October release I believe? http://www.chromium.org/Home/chromium-security/site-isolation#TOC-1-Isolating-All-Sites http://www.chromium.org/Home/chromium-security/site-isolatio...
- mschuetz 9y agoFor some reason, performance.now() and even the performance profiler are capped at 1 milisecond precision on my machine, which make both pretty much useles. Can only get better for me. :|
- londons_explore 9y agoThose are the mitigations firefox is doing. Is chrome doing the same?