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.

[lars-t-hansen]

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).

[domenic]

Modules don't help with static analysis of what language features are used, due to dynamic import().

[allenwb]

@domenic A host could require certain built-in modules to only be included using an import statement.

[domenic]

How?

[ljharb]

That sounds very very strange and confusing to me - i would not expect that a static or dynamic import statement, for the same path, could produce different results - and if it’s possible, i think we should change the spec so it’s forbidden.

[allenwb]

A host defined loader interprets a import's module specification and determines its resolution and availability. Why could a loader decide to only allow certain (even all) "built-in" modules to be loaded from static import statements.

The spec. requires that from within module, a given import spec. must always resolve to the same thing. I does need to say that all import specs are allowed to be used in both static or dynamic imports.

Even if dynamic imports of such built-ins are allowed, it would still be reasonable for a host to say that if you use static imports for these built-ins we will be able to better optimize your program.

[hax]

I think built-in modules is good idea, but I don't realize how it can solve the security problem. Do you mean let browsers never support importing SAB module (throw runtime error?) but allow node.js import it?

[allenwb]

@hax At the extreme it allows SAB and friends to remain in the standard and allow hosts like node.js to support them and other hosts like web browsers to reject their use.

But it also provides addition ways to think about controlling use of SAB. For example, a web host might define CORS rules that control which modules are allowed to import the SAB built-in module.

[leobalter]

@allenwb while I agree with you SAB should be a built-in modules, I'd really like to speed the process to define built-in modules in ECMAScript before restricting new features to something that doesn't exist yet.

The fact they are not well supported yet - as @lars-t-hansen said - is also not welcoming to add anything to it.

The matters of static and dynamic import results could be a topic for this theme as well, if not directly in the import() proposal.

I'd like to see this part of discussion taking a direction, maybe in another thread before the next meeting, so we can try to finally decide how built-in modules could be and have them advancing in the stage process.

[allenwb]

@leobalter But whose fault is the foot dragging on built-in modules? It's not a hard problem. I've been pushing for them for years and so has @rwaldron but there has seemed to be very interest within TC39 in making progress on them.

At this point, I would be fine with the web platform saying: hey, let's put SAB into some sort of built-in module whose loading we can control. Maybe that would be enough of a nudge to get TC39 to take some action.

My recommendation to web platform people is don't be blocked by TC39 inaction. Consider the possibility of how some of these problems might addressed by using the concept of built-in modules and if it makes sense run with it.

[domenic]

Yeah, in general I think the specifier namespace (including potentially built-in modules) is best left up to hosts; I'm not a big fan of TC39 coming up with its own set of built-in modules.

We're certainly exploring features that would make sense to expose as built-in modules in the web platform---mostly those that would benefit from lazy-loading of a sort. But, so far, I've yet to see any good arguments in this thread that SAB is such a feature.

[allenwb]

@domenic
What other technique other than built-in modules would be reasonable for TC39 to use to define a growing set of standard libraries that are optional in nature and don't pollute the global name space.

[domenic]

I disagree with the requirement to not "pollute" the global namespace.

[phoddie]

@domenic, dynamic import() can indeed foil static analysis. But, static analysis can determine that only import statements are used. For many uses, certainly the majority of those in embedded, that is sufficient.

[domenic]

Sure, but if you're content with that restricted analysis, then you can just determine that no dynamic global property lookups happen, in the same way.

[allenwb]

I disagree with the requirement to not "pollute" the global namespace.

and hence the deadlock

[TimothyGu]

Can we move the discussion around modules to a different issue?

[jfbastien]

SharedArrayBuffer is already stage 4, I'm not sure there's a deadlock to resolve in this particular race since we've reached quiescence.

[raulsebastianmihaila]

@domenic How is it possible to statically determine that the 'document' property is accessed in the following code (note it doesn't necessarily have to be the 'document' property)?

function f(index, letter) {
  const prop = ['d', 'o', 'b', 'u', 'm', 'e', 'n', 't'];

  prop[index] = letter;

  return eval(prop.join(''));
}

f(2, 'c');

Besides, I actually had a bug in an application with documents (not DOM documents) where a function was supposed to receive a document argument and I forgot to write the parameter in the function definition and therefore I was accessing the global document. Globals have obvious downsides.

[domenic]

@raulsebastianmihaila it is not. But my point is that it is also not possible to determine that the "std:SharedArrayBuffer" module is accessed in the following code:

function f(index, letter) {
  const prop = ['s', 't', 's', ':', 'S', 'h', 'a', 'r', 'e', 'd', 'A', 'r', 'r', 'a', 'y', 'B', 'u', 'f', 'f', 'e', 'r'];

  prop[index] = letter;

  return import(prop.join(''));
}

f(2, 'd');

In both cases, you can use static analysis to find a restricted set of global property accesses/imports. In neither case will you catch all of them. Built-in module vs. global property makes no difference.

[PeteX]

Going back to SharedArrayBuffer (and atomics) for a moment...

I think it was the right decision to disable it as a temporary mitigation for the timing attacks that were disclosed at the start of the year. However, I hope this doesn't lead to people becoming less ambitious for the web.

A reasonable long term goal is that it should be possible to deliver AAA-quality games, VR experiences, and so on, over the web. This will only be possible if shared memory and atomics are included and designed in a way that supports the most demanding applications. This won't be achieved if the spec requires wasm applications to memcpy chunks of data. Non-web versions of these interactive experiences will still be better, because they will be getting other work done while the web version is memcpy'ing things needlessly.

This isn't to say that it's easy designing this sort of thing. It's genuinely difficult to provide a system that can't be exploited, while providing enough low level functionality for a C++ game engine that used to run as a desktop application. If it can be achieved, though, there are many benefits. Web applications are inherently cross-platform. Also, ironically in view of the starting point, the user's privacy and security are much better protected. Users don't have to worry about games with embedded malware (or which just violate their privacy) because the web browser provides a sandbox.

My understanding is that there are mitigations for the currently known timing attacks. Once these mitigations are in place, and people have had a chance to search for other attacks in the same class, please can we have our SharedArrayBuffers back?

[yyc-git]

hope to enable js SharedArrayBuffer! we need it!

I'm currently implementing multi thread webgl engine which heavily dependent on SharedArrayBuffer and OffscreenCanvas!

If SharedArrayBuffer isn't supported, I can use transfer ArrayBuffers but it's too slow!!!

[andremichelle]

Just want to drop a line saying how important SharedArrayBuffer are for audio processing. It is the only option to have fast communication between worker and audio-worklets without having the blocking main-thread in between.

[awby]

It looks like there's a bug in Chromium to track re-enabling SAB: https://bugs.chromium.org/p/chromium/issues/detail?id=821270. So there's hope.

[yyc-git]

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]

Desktop frameworks like electron/nw allow to re-enable it by passing the runtime flag --enable-features=SharedArrayBuffer

[hnagh001]

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]

@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]

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]

@yyc-git where is OffscreenCanvas? I cannot find it in Chrome, neither in Canary

[yyc-git]

@mathiasbynens OffscreenCanvas is enabled default in chrome 68

[maierfelix]

Not for me, I cannot enable the experimental canvas feature flag - seems to be a problem with my machine.

[lars-t-hansen]

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]

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]

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]

@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.

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]

@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]

resolved via tc39/ecma262#1435 / tc39/ecma262#1903