SharedArrayBuffer and timing attacks (Meltdown and Spectre)

[evilpie]

I think everyone was aware that ShareArrayBuffer allows for creating accurate timers. With the recent release of Meltdown and Spectre, SharedArrayBuffer was disabled in all browsers.

[mathiasbynens]

Is non-wasm SharedArrayBuffer still useful? +@erights

[erights]

I see no remaining utility in JS SABs. All the use cases that motivated JS SABs are now well served by wasm SABs. Or rather, were served by wasm SABs before all SABs were disabled. The pressure to re-enable wasm SABs, once it is safe to do so, is probably unstoppable. However, I think we should take this opportunity to permanently kill JS SABs.

[xtuc]

Are you planning to remove SAB in JS entirely (apart for WebAssembly)?
It's still useful for sharing data across JS workers.

[mathiasbynens]

tc39/ecma262#1060

[getify]

Does this mean that essentially atomics is dead?

[syg]

Until the committee reaches consensus (my opinion is removal is premature), please refrain from taking away from this thread any definite future of SABs.

[lars-t-hansen]

Off the top of my head:

I think that at the moment, it would create usability issues for wasm if we were to remove SAB from JS, since JS provides services to wasm that can't be expressed in wasm at the moment. As wasm evolves this will be less of a problem but right now wasm in the browser it is strongly dependent on JS.

For example, wasm currently only supports a single memory, which is shared or non-shared. If SAB is removed from JS, and a wasm memory is shared, then JS can no longer use that memory for communicating with wasm. That can possibly be fixed by supporting multiple memories in wasm (a big job probably) or by adding some memcpy-like functionality to wasm memory objects (clearly a smaller job). In effect this amounts to not allowing the underlying memory buffer of a wasm memory to be exposed, which is probably not a bad idea, but novel.

Removing SAB from JS might also be a suboptimal place to cut if it prevents JS from even talking about SAB objects in meaningful ways (such as structured clone); one could equally effectfully remove the ability to create views on SABs.

I think we need an investigation of impacts here. cc @flagxor @juj

[lars-t-hansen]

On a more general note, we've always been aware that SAB created a high-resolution timer and that there might be attacks (tc39/proposal-ecmascript-sharedmem#1). At Mozilla we've been discussing for some time how the undesirable timer functionality of SAB can be controlled better. One solution that has been mentioned in the past is to pin agents that share memory to the same core, unless the user opts in (somehow) to using more cores on a site. That type of opt-in (how much CPU do you want to allow this site to use) might be more generally useful in these bitcoin-mining times, I've seen it pop up elsewhere. There are other possible solutions but really too premature to bring up here.

Browsers will mitigate against the bounds checking attacks of Spectre and will likely do so soon, at fairly modest run-time cost, and that will bring us back to pretty much where we were, assuming operating systems and compilers are updated to mitigate other issues. (In the "where we were" world the HR timer remains worrying, of course; see above.)

As @jfbastien mentions we feel that shared memory is important for the web and probably not just for wasm, and though this is just my opinion and not Mozilla's, I feel that it is premature to remove SAB from the spec now. If it is disabled in all browsers no content will be developed for it, and we can afford to delay removing it.

[trusktr]

I don't know what it takes to solve the security issues, but what I do know is that in writing a library like mine I would really like to be able to send binary data quickly to other threads to optimize calculations (physics, world transforms, etc). Passing strings (encoding/decoding) simply doesn't seem right for something like a real-time multiplayer first-person shooter, and it's unfair to the web not to have something that avoids that overhead. So, I don't know if SAB should go or stay, but I definitely do want some fast way to send data between threads in a web app.

[AdaRoseCannon]

@trusktr You can still transfer ArrayBuffers from one thread to another to avoid the stringification but it still requires a postMessage.

https://developer.mozilla.org/en-US/docs/Web/API/Transferable

[getify]

@AdaRoseCannon AFAICT, that only works in browsers, but doesn't offer any hope for shared memory in node. I was really excited about SAB for the benefits it would bring for node and multi-process programming, but now I'm back to slowly/inefficiently passing data between processes through local file sockets. :(

[allenwb]

I've always thought we were going a bit to far to make SharedArrayBuffer and Atomics a required part of the global environment of every ECMAScript program.

Why not place them a built-in module that requires an explicit import to use. This would allow different host environment to impose their own independent policies for when they accept or reject imports of that module.

TC39 hasn't yet had a use case that was significant enough to specify anything as a built-in module and work out any details of the built-in module syntax/semantics. Maybe this is that use case.

Alternatively, any browser that supports <script type="module"> could push things forward by doing the implementation specific work of defining such a built-in module.

[littledan]

@AdaRoseCannon Note that postMessage'ing an ArrayBuffer from one Worker to another transfers it, making it still available in only one Worker at a time. In the sending Worker, the ArrayBuffer becomes "detached", with operations on it throwing.

[phoddie]

While this is something of an aside from the security focus of this thread, I very much agree with @allenwb that new features such as SharedArrayBuffer and Atomics benefit from being in a module instead of a global. For our use of JavaScript in embedded situations, it would make it straightforward to include or exclude features. To do that today we are obliged to resort to heuristics when linking scripts to determine what language features are used.