Investigate wasm for linkability/fingerprintability/disk avoidance issues
In order to avoid the asm.js disaster we should investigate whether wasm complies with our design requirements. It got [in Firefox 52] but [in ESR 52].
Activity
status-firefox-esr52: disabledhttps://bugzilla.mozilla.org/show_bug.cgi?id=1342060#c23 But, please, don't postpone such tasks to the next esr.Trac:
Keywords: ff52-esr deleted, N/A addedReplying to cypherpunks:
status-firefox-esr52: disabledhttps://bugzilla.mozilla.org/show_bug.cgi?id=1342060#c23 But, please, don't postpone such tasks to the next esr.Indeed disabled in esr52. pref
javascript.options.wasmMore details (beyond the comment): https://bugzilla.mozilla.org/show_bug.cgi?id=1342440 https://hg.mozilla.org/releases/mozilla-esr52/rev/e07850f191a0
Changing the description so that others don't need to read comments to know about this.
Trac:
Description: In order to avoid the asm.js disaster we should investigate whether wasm complies with our design requirements. It got enabled in Firefox 52 (and presumably in ESR 52 as well): https://bugzilla.mozilla.org/show_bug.cgi?id=1342060.to
In order to avoid the asm.js disaster we should investigate whether wasm complies with our design requirements. It got [in Firefox 52] but [in ESR 52].
Let's disable it for now until we are confident we can enable it and let it govern by the security slider. See:
bug_21549(https://gitweb.torproject.org/user/gk/tor-browser.git/commit/?h=bug_21549&id=19ad2e4d07a06e529920f082eb7d5fdd87e380d4) in my publictor-browserrepository.Trac:
Keywords: TorBrowserTeam201808 deleted, TorBrowserTeam201808R added
Status: new to needs_review
Cc: dmr to dmr, mcs, brade
Is this enough after tiering was enabled? https://bugzilla.mozilla.org/show_bug.cgi?id=1277562
Trac:
Username: reportUrlRelevant to HTTPS Everywhere, which would like to rewrite portions of the code in WASM for better performance: https://github.com/EFForg/https-everywhere/issues/17143.
-
Replying to legind:
Relevant to HTTPS Everywhere, which would like to rewrite portions of the code in WASM for better performance: https://github.com/EFForg/https-everywhere/issues/17143.
I think we could bypass the investigation for HTTPS Everywhere (and extensions in general) at least by assuming it belongs to privileged code (which it does) and that the linkability etc. concerns only applies to content (which I think is not unreasonable). The idea then could be to implement a switch to being able to disable WASM and similar things (ASM.js comes to mind) for content only while leaving chrome like code untouched.
Or maybe the chrome/content separation already exists and WebExtensions are just not properly added to the chrome bucket?
-
Replying to legind:
@gk I'm concerned that extensions are a single-click install in most cases, and privileging them in general will open identifiable characteristics to possibly irresponsible third parties. Can we whitelist WASM by extension ID?
Maybe. However, the current policy is that users are responsible themselves for possible fallout if they are installing other extensions into their Tor Browser. This is not recommended for all sorts of reasons.
Webextensions got already "privileged" by allowing JavaScript to run in general if it is disabled in the browser (you might remember https://bugzilla.mozilla.org/show_bug.cgi?id=1329731). I think it is more straightforward to follow the reasoning dveditz outlined in https://bugzilla.mozilla.org/show_bug.cgi?id=1329731#c7 arguing that disabling WASM for extensions (while allowing it for the remaining parts of the privileged browser) is not the right solution.
FWIW: that Mozilla bug might be a good start for investigating how to enable WASM for extensions only but not content (by checking the principal accordingly).
-
Oh, and one additional point: we might want to have some WebExtensions exceptions on the higher levels of the security slider for things like JIT (see: #23719 (moved)) which is kind of related.
Update: in https://github.com/EFForg/https-everywhere/pull/18093, HTTPS Everywhere includes WASM optimizations. So Tor Browser would see an OOTB performance increase and memory overhead decrease by enabling WASM in extension-land.
-
We have #23719 (moved) for the slider related things and this bug for the general enabling. Talking to Luke I think we are in good shape (surprise!) and nothing stood out. One thing that remains to test is whether New Identity is actually blowing away WASM related cache in case someone used Tor Browser outside of Private Browsing Mode (there are no WASM cache entries written to disk in that mode).
Trac:
Keywords: ff60-esr, TorBrowserTeam201809 deleted, TorBrowserTeam201907, ff68-esr added Okay, I started from the beginning, and then worked backwards :)
This was tedious because most of the initial patches were simply refactoring asmjs compiler code such that the code could be shared with wasm. Reading these patches was helpful except the code has significantly changed since four years ago (and wasm has mostly replaced asmjs in the codebase now). As an example, the compiler cached asmjs code until earlier this year. I'm taking a different approach now, but I'll post this anyway. The next comments will be based on the current implementation.
https://bugzilla.mozilla.org/show_bug.cgi?id=1188259
- Meta ticket of implementing wasm https://bugzilla.mozilla.org/show_bug.cgi?id=1224389
- Odin: refactor in preparation for WebAssembly decoder
Commits:
- f7c5ebaa664b0dc07836fe06d3609e239ba7e71a - okay
- Mostly refactoring
- 4ef42db6e3cad192ccefaacc823aab012a57c6e5 - okay
- Mostly code simplification
- 28f2c8f11d211e30e1f0fb77902c9ba4d2a7d1c5 -
- Check JS::AsmJSCache_QuotaExceeded, LookupAsmJSModuleInCache
- https://bugzilla.mozilla.org/show_bug.cgi?id=1516697 - Remove the implementation of the asm.js caching mechanism.
- masm.loadAsmJSHeapRegisterFromGlobalData is isolated? https://bugzilla.mozilla.org/show_bug.cgi?id=1232205
- Check JS::AsmJSCache_QuotaExceeded, LookupAsmJSModuleInCache
- f7c5ebaa664b0dc07836fe06d3609e239ba7e71a - okay
- wasm:Baseline JIT
Commits:
- 9e9fafcd38f7e3ec3db1d4508bf4230a2d4b3678 - okay
- 8938a215ec16a20f9fa4f4156d9bd611e8fa8562 - okay
- 5f37b8277391842f5e56c211c3ca4acd86237d72 - okay
- 8ec23c07dd09da1e46bf17f05ecad83f8aa12e4e - okay
- 9af7246a474bb824f39562b68e5f7fae0921a8d9 - okay
- All refactoring and JIT impl, no caching
- 136c1d78af1bf603c4bcd2fc2488d3c3f9661569 - okay
- Adds mechanism for running baseline wasm tests
- 65b0869d9e684d486c1ac4cf90c60bf3dfc22c82 - okay
- Adds test directive
- 2a5c7f48c92c2163b9f69ebc9f287c7ae8db7c7c -
- Baseline JIT impl.
- Pushes code onto masm stack? Is this masm stack isolated?
- ffiCall? WasmTableCallPtrReg?
- bd9aa07076b543051bcfbd8937c32a9ad2bec883 - okay
- Add pref and jsshell runtime arg
The WebAssembly API consists of:
- The WebAssembly Object:
- The WebAssembly.Global Object:
- The WebAssembly.Module Object:
- The WebAssembly.Instance Object:
- The WebAssembly.Memory Object:
- The WebAssembly.Table Object:
- The WebAssembly.CompileError Object:
- The WebAssembly.LinkError Object:
- The WebAssembly.RuntimeError Object:
These are exported and implemented: WebAssembly.compile() WebAssembly.compileStreaming() WebAssembly.instantiate() WebAssembly.instantiateStreaming() WebAssembly.validate() WebAssembly.Global WebAssembly.Memory WebAssembly.Module WebAssembly.Instance WebAssembly.Table
-
WebAssembly.compileis for ahead-of-time compiling a WASM module. It takes in a buffer of WASM and returns a Promise of aWebAssembly.Module. -
WebAssembly.compileStreamingis similar tocompile()except it takes in a Response object or Promise for a wasm module (compared with a buffer containing the module). -
WebAssembly.instantiatehas two prototypes.- The first takes in a buffer of WASM and returns a Promise of a tuple: (
WebAssembly.Module,WebAssembly.Instance). TheModuleis the compiled WASM, and theInstanceis an instantiation of thatModule. - The second takes in an existing
WebAssembly.Module(already compiled WASM) and returns anInstance.
- The first takes in a buffer of WASM and returns a Promise of a tuple: (
-
WebAssembly.instantiateStreamingtakes in a a Response object or Promise (likecompileStreaming) and returns a Promise of a tuple: (WebAssembly.Module,WebAssembly.Instance) likeinstantiate(). -
WebAssembly.validate()takes in a buffer of WASM binary code and returns a boolean true if the buffer contained valid wasm, and false otherwise. -
WebAssembly.Globalis an object containing a WASM "global" variable. MultipleGlobalinstances may be passed intoWebAssembly.instantiate(), but these globals are only accessible by WASM if they are explicitly "imported" by the WASM Module. -
WebAssembly.Instanceis an instance of aModuleinitialized withGlobaland/orMemoryinstances. -
WebAssembly.Memory().bufferis an ArrayBuffer representing the "heap" memory available in the WASM module. This is readable and writable by both JavaScript and WASM. From WASM, pointers are represented by an index of the Memory ArrayBuffer. -
WebAssembly.Tableis an "array-like" structure storing function-references. In the future, Tables may store more than only function-references. Tables allow calling arbitrary functions from WASM (after the WASM module assigns a function-reference at an index in the table). It seems like this provides a level of abstraction compared with exporting a function from WASM into JavaScript, because function-references can be added/deleted/modified in the Table at run-time.
I don't see any significant fingerprinting or linkability issues in the wasm implementation. I don't see any caching across principals. There is a minor fingerprinting risk due to timing leaks (how quickly the wasm byte code is returned as a Module), and how quickly a wasm function is executed. There is the additional risk of malicious byte code exploiting a compiler bug. However, these seem no worse than the existing javascript attack surface - wasm simply adds more options.
I have two branches - one for tor-browser (deleting the override) and the other for torbutton (adding as a pref controlled by the security slider).
Both branches are named
bug21549_00.https://github.com/sysrqb/torbutton/
Trac:
Status: new to needs_review
Keywords: TorBrowserTeam201910 deleted, TorBrowserTeam201910R added-
Replying to sysrqb:
I have two branches - one for tor-browser (deleting the override) and the other for torbutton (adding as a pref controlled by the security slider).
Both branches are named
bug21549_00.Looks good. Merged to
master(Torbutton) as commit 324e8fd7f73c7f97f8174713c6a112ec75669e56 andtor-browser-68.2.0-9.5-1(tor-browser) as commit 80134f6a3d2026ff95943e806cb424bf9eff2c2f.Nice review work!
Trac:
Status: needs_review to closed
Resolution: N/A to fixed mentioned in issue #26407 (moved)
mentioned in issue #34055 (moved)
