3 ms·

>Except that the Spectre paper already takes degraded timers into account and suggests to use a Web Worker thread that increments a value in a loop as a replace

>Except that the Spectre paper already takes degraded timers into account and suggests to use a Web Worker thread that increments a value in a loop as a replacement. Yeah, which was why SharedArrayBuffer was disabled when spectrev1 was released. It is still disabled in Chrome if site-isolation is disabled and it's still disabled in firefox. You should really know all this if you are so very well versed in the subject. >Even if I was wrong, and very wrong, why the hell would you choose to be less safe? this whole thread chain is absolutely baffling. Buy an AMD CPU or leave the mitigations on. Everything else is needlessly opening yourself up. I don't run without migrations. I commented on the original parent comments threat model and that I think it's perfectly logical. And I maintain this, if your threat model is so strict, that you are afraid of speculative execution vulnerabilities hitting you through javascript, you should not run JS at all, as regular js 0days have hit while no actual speculative execution browser exploits have hit.

dijit 7y ago
“Threat model is so strict” is weird to say when any ad network can access any and all memory on your desktop potentially. That’s a very wide attack scope.
- scandinavian 7y ago
  You have misunderstood how the browser attacks work. They are limited to the memory assigned to the browser process. If site-isolation and the other browser mitigations were somehow bypassed, an ad-network would potentially be able to read some data from other loaded tabs. You can't use the speculative execution vulnerabilities to just read all system memory using a javascript exploit. Like the exploit that is the topic of this post can't be used in a browser at all, as you are limited to what the JIT executes, you can't just execute TSX instructions in a browser. You might be thinking of when you have native code execution.
  - saurik 7y ago
    The website covers a handful of things, and the RIDL exploits don't require special instructions. > We leak a string from another process using Javascript and WebAssembly in the SpiderMonkey engine.
    - scandinavian 7y ago
      > We leak a string from another process using Javascript and WebAssembly in the SpiderMonkey engine. They leak in flight data, using a detached spidermonkey engine, patched to make performance.now() return rdtscp at a rate of 1B/s while the victim application is spamming a load string instruction as fast as possible. This does not allow: >any ad network can access any and all memory on your desktop This allows any ad-network to access random bits on the cache line. If the timing mitigation didn't already fix this, it seems impossible to me to get anything useful from it, the precision and bitrate is just too low (which is why the exploit just spams load instructions in a while 1 loop). >and the RIDL exploits don't require special instructions. Weird, in the new addendum it says it uses TSX, and in the PoC it uses XBEGIN. Must be a mistake.

dijit 7y ago

“Threat model is so strict” is weird to say when any ad network can access any and all memory on your desktop potentially. That’s a very wide attack scope.

scandinavian 7y ago
You have misunderstood how the browser attacks work. They are limited to the memory assigned to the browser process. If site-isolation and the other browser mitigations were somehow bypassed, an ad-network would potentially be able to read some data from other loaded tabs. You can't use the speculative execution vulnerabilities to just read all system memory using a javascript exploit. Like the exploit that is the topic of this post can't be used in a browser at all, as you are limited to what the JIT executes, you can't just execute TSX instructions in a browser. You might be thinking of when you have native code execution.
- saurik 7y ago
  The website covers a handful of things, and the RIDL exploits don't require special instructions. > We leak a string from another process using Javascript and WebAssembly in the SpiderMonkey engine.
  - scandinavian 7y ago
    > We leak a string from another process using Javascript and WebAssembly in the SpiderMonkey engine. They leak in flight data, using a detached spidermonkey engine, patched to make performance.now() return rdtscp at a rate of 1B/s while the victim application is spamming a load string instruction as fast as possible. This does not allow: >any ad network can access any and all memory on your desktop This allows any ad-network to access random bits on the cache line. If the timing mitigation didn't already fix this, it seems impossible to me to get anything useful from it, the precision and bitrate is just too low (which is why the exploit just spams load instructions in a while 1 loop). >and the RIDL exploits don't require special instructions. Weird, in the new addendum it says it uses TSX, and in the PoC it uses XBEGIN. Must be a mistake.