You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
SharedArrayBuffer and timing attacks (Meltdown and Spectre) #3
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.
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.
Reacted by Daniel Lehenbauer
Reacted by Dannii Willis, Kaelan Cooter, YYC, Felix Maier, kev zettler, André Michelle, rf00, Robbie Speed, Hannan Ali, John Weisz and 24 more
Until the committee reaches consensus (my opinion is removal is premature), please refrain from taking away from this thread any definite future of SABs.
Reacted by JF Bastien, Rick Waldron and Kaelan Cooter
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
Reacted by Daniel Ehrenberg, Sergey Rubanov, J. S. Choi, JF Bastien and Byron Mejia
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 @jfbastienmentions 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.
Reacted by Sergey Rubanov, J. S. Choi, Anthony Bowker, Luke Wagner, cdetrio, Dannii Willis, James McMullan, YYC, Kaelan Cooter, Josiah Savary and 9 more
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.
Reacted by Anthony Bowker, HE Shi-Jun, Kyle Simpson, PeteX, YYC, Chris Novello, belowm, kev zettler, Wis, Guillermo Grau Panea and 10 more
@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. :(
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.
@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.
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.
The possibility of using a module came up (well, Allen raised it :) during the design of SAB. FWIW, it wasn't explored further because modules were not baked yet (not well supported; inadequate loader semantics).
We can use chrome 67 dev version for run and test multi thread webgl with sharedArraybuffer and offscreenCanvas (need enable).
Thanks Chrome, it's really powerful.
I need to use OffscreenCanvas for WebGL also but when I enable the flag on Firefox and use it in my javascript, the browser is crashed. My Firefox version is 46 which supports based on browser compatibility in https://developer.mozilla.org/en-US/docs/Web/API/OffscreenCanvas
Could anybody use OffscreenCanvas on any version of Firefox or Chrome without crash? @yyc-git
@hnagh001 Firefox is crash, but you can use chrome dev version(my run environment is mac->chrome 68.0.3409.2 dev 64bit)(you need enable chrome://flags->"Experimental enabled SharedArrayBuffer support in JavaScript")
I have found that the mac-> Chrome Beta 67(67.0.3396.40) can correctly support sharedArrayBuffer and offscreencanvas !!!(need enable chrome://flags->"Experimental enabled SharedArrayBuffer support in JavaScript")
Does Firefox have a public plan for re-enabling SharedArrayBuffer (after sufficient security measures are in place)? Is there a tracking bug for re-enabling?
I do not believe that we have any public plan re re-enabling SAB though of course we are discussing it.
There is a tracking bug that I use to record SAB-reenablement blockers here. It is possible that there are additional work items that are not yet blocking that bug. It is possible that that bug is blocking work items that do not need to be completed in their entirety for it to be possible to re-enable SAB. Actually re-enabling SAB is a management/product decision, not solely a technical one. Please do not take technical completeness as a promise of anything.
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.
This point of view is ludicrously naive and short-sighted, I'm afraid there is simply no other way to put it.
Anything more than the 10000th todo-app toy may have a perfectly valid reason to do parallel computing, either due to a need of working with massive data-sets, or due to a sheer real-time performance requirement.
And no, a JSON with a few thousand entries is not massive data. A 20 GB Float32Array is massive data. I'd like to see the person (and machine) that does parallel computation on that without SharedArrayBuffer.
Reacted by Jeff VanDyke, Thom, Mark Moissette, Nathan Rugg, Micha Schwab, Robert Koch, Joe Pea and Adrian Soucup
Reacted by Scott Lott, Ashok Mandal, Robert Koch and Adrian Soucup
@JohnWeisz I agree that this perspective on SABs is short-sighted.
But more to the point, it's not just that there are real valid use cases for SABs (such as web workers, node child processes, etc), but that there are plenty of cases where people have full-stack JS apps that need SABs.
It seems horribly convoluted for an app to have to be partially rewritten in some other non-JS language just so that part can target WASM and thus get access to SABs. I simply cannot consider as reasonable any argument for why WASM SABs are OK and safe for the web, but JS SABs are not.
Reacted by John Weisz, Bnaya Peretz, Christi Kaes, HE Shi-Jun, Mark Moissette, Anthony Bowker, vroad, Nathan Rugg, Micha Schwab, Ashok Mandal and 9 more
Activity
mathiasbynens commentedon Jan 6, 2018
Is non-wasm
SharedArrayBufferstill useful? +@erightserights commentedon Jan 6, 2018
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 commentedon Jan 6, 2018
Are you planning to remove SAB in JS entirely (apart for WebAssembly)?
It's still useful for sharing data across JS workers.
mathiasbynens commentedon Jan 6, 2018
tc39/ecma262#1060
getify commentedon Jan 6, 2018
Does this mean that essentially atomics is dead?
syg commentedon Jan 7, 2018
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 commentedon Jan 7, 2018
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 commentedon Jan 7, 2018
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 commentedon Feb 3, 2018
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 commentedon Feb 7, 2018
@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 commentedon Feb 7, 2018
@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 commentedon Feb 7, 2018
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
importto 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 commentedon Feb 7, 2018
@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 commentedon Feb 7, 2018
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
SharedArrayBufferandAtomicsbenefit 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.lars-t-hansen commentedon Feb 7, 2018
The possibility of using a module came up (well, Allen raised it :) during the design of SAB. FWIW, it wasn't explored further because modules were not baked yet (not well supported; inadequate loader semantics).
23 remaining items
yyc-git commentedon Apr 23, 2018
We can use chrome 67 dev version for run and test multi thread webgl with sharedArraybuffer and offscreenCanvas (need enable).
Thanks Chrome, it's really powerful.
maierfelix commentedon Apr 30, 2018
Desktop frameworks like electron/nw allow to re-enable it by passing the runtime flag
--enable-features=SharedArrayBufferhnagh001 commentedon May 1, 2018
I need to use OffscreenCanvas for WebGL also but when I enable the flag on Firefox and use it in my javascript, the browser is crashed. My Firefox version is 46 which supports based on browser compatibility in https://developer.mozilla.org/en-US/docs/Web/API/OffscreenCanvas
Could anybody use OffscreenCanvas on any version of Firefox or Chrome without crash?
@yyc-git
yyc-git commentedon May 2, 2018
@hnagh001 Firefox is crash, but you can use chrome dev version(my run environment is mac->chrome 68.0.3409.2 dev 64bit)(you need enable chrome://flags->"Experimental enabled SharedArrayBuffer support in JavaScript")
yyc-git commentedon May 12, 2018
I have found that the mac-> Chrome Beta 67(67.0.3396.40) can correctly support sharedArrayBuffer and offscreencanvas !!!(need enable chrome://flags->"Experimental enabled SharedArrayBuffer support in JavaScript")
maierfelix commentedon Jun 17, 2018
@yyc-git where is OffscreenCanvas? I cannot find it in Chrome, neither in Canary
yyc-git commentedon Jun 17, 2018
@mathiasbynens OffscreenCanvas is enabled default in chrome 68
maierfelix commentedon Jun 17, 2018
Not for me, I cannot enable the experimental canvas feature flag - seems to be a problem with my machine.
lars-t-hansen commentedon Jul 27, 2018
I don't think the information about Firefox is correct. The current default pref setting is 'off', https://hg.mozilla.org/releases/mozilla-release/file/tip/modules/libpref/init/all.js#l1437, and though we wish to be able to reenable it eventually we have not done so on any branch as of now.
awby commentedon Jul 27, 2018
Does Firefox have a public plan for re-enabling SharedArrayBuffer (after sufficient security measures are in place)? Is there a tracking bug for re-enabling?
lars-t-hansen commentedon Jul 30, 2018
I do not believe that we have any public plan re re-enabling SAB though of course we are discussing it.
There is a tracking bug that I use to record SAB-reenablement blockers here. It is possible that there are additional work items that are not yet blocking that bug. It is possible that that bug is blocking work items that do not need to be completed in their entirety for it to be possible to re-enable SAB. Actually re-enabling SAB is a management/product decision, not solely a technical one. Please do not take technical completeness as a promise of anything.
JohnWeisz commentedon Aug 3, 2018
@erights
This point of view is ludicrously naive and short-sighted, I'm afraid there is simply no other way to put it.
Anything more than the 10000th todo-app toy may have a perfectly valid reason to do parallel computing, either due to a need of working with massive data-sets, or due to a sheer real-time performance requirement.
And no, a JSON with a few thousand entries is not massive data. A 20 GB Float32Array is massive data. I'd like to see the person (and machine) that does parallel computation on that without
SharedArrayBuffer.getify commentedon Aug 3, 2018
@JohnWeisz I agree that this perspective on SABs is short-sighted.
But more to the point, it's not just that there are real valid use cases for SABs (such as web workers, node child processes, etc), but that there are plenty of cases where people have full-stack JS apps that need SABs.
It seems horribly convoluted for an app to have to be partially rewritten in some other non-JS language just so that part can target WASM and thus get access to SABs. I simply cannot consider as reasonable any argument for why WASM SABs are OK and safe for the web, but JS SABs are not.
ctcpip commentedon Feb 27, 2024
resolved via tc39/ecma262#1435 / tc39/ecma262#1903