1433425 - disabling WASM doesn't work

Status: RESOLVED INVALID

(Core :: JavaScript Engine: JIT, defect)

Description

[Christoph Anton Mitterer]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0
Build ID: 20180124084836

Steps to reproduce:

WASM, which is an inherent security threat, can allegedly be disabled via:
javascript.options.wasm=false

However, that doesn't seem to work, e.g. http://webassembly.org/demo/ still runs.

Users trusting in that questionable technology being disabled and there systems therefore being secure are mislead => thus "Many users could be harmed by this security problem: it should be kept hidden from the public until it is resolved."

Comment 1

[Al Billings [:abillings - ex-MoCo]]

Putting this in the right component and security group so JS people can see the report.

Comment 2

[Daniel Veditz [:dveditz]]

If you were reporting a vulnerability in WASM--which is on by default--that would be a "many users could be harmed" situation. An inability to turn off a default feature is a concern, but doesn't need to be hidden.

As it happens I believe this report is in error: that demo has an "asm.js" fallback. asm.js is just javascript, a subset that can be optimized nicely, but not WASM. If I load the demo page with WASM disabled the play button is instead a "Play asm.js fallback" button with a red warning "Your browser doesn't support WebAssembly yet. Learn more". If you've loaded the tank demo directly then you probably didn't notice the polyfill kicking in and automatically loading the asm.js version. It's a bit slower, especially the initial load.

Comment 3

[Daniel Veditz [:dveditz]]

A clearer example might be the demo at https://mdn.github.io/webassembly-examples/js-api-examples/compile-streaming.html

It doesn't do much which makes it easier to see without all the polyfill goop. If you open the web console then if WASM is enabled you will see "42" printed out after the .wasm file is loaded. If you've disabled it you'll see  "ReferenceError: WebAssembly is not defined[Learn More]"

Comment 4

[jwms]

how is this benchmark able to run with config entries set to block both webassembly and asm.js?

https://pspdfkit.com/blog/2018/a-real-world-webassembly-benchmark/
direct link https://pspdfkit.com/webassembly-benchmark/

This benchmark is supposed to test webassembly rendering of a pdf.

If I set javascript.options.wasm = false it falls back to asm.js and if I set javascript.options.asmjs = false it still runs.

Developer Tools > Web Console shows that webassembly does respond to the wasm preference however the asmjs pref doesn't disable the test.

Comment 5

[jwms]

My question is can I disable asm.js because the config preference implies, at least to me, that it should disable asm.js

Comment 6

[Benjamin Bouvier [:bbouvier] (inactive)]

It is expected, because asm.js is a subset of JavaScript. The pref javascript.options.asmjs is a switch to control whether we *enable* asm.js optimizations, but since it's only a subset of JavaScript, it can still be interpreted/JITted as JavaScript (this was one big selling point at the time when asm.js was a thing). The performance might just be worse, in this case. So things should be working as usual.

That being said, I just tested the benchmark while disabling wasm (and keeping asm.js enabled), and it seems the (browser generated) message we usually display when asm.js optimizations have kicked in doesn't show up in the console. The "Using Asm.js method" message you're seeing in the console is logged by the benchmark authors, and it seems to be misleading, because it's not running "real" asm.js under the hood.

Comment 7

[jwms]

so javascript.options.asmjs doesn't disable asms.js

Comment 8

[Lars T Hansen [:lth]]

(In reply to jwms from comment #7)
> so javascript.options.asmjs doesn't disable asms.js

Turning that option off disables the specially-optimizing asm.js compiler, and instead the engine will run asm.js content as plain JS; as every asm.js program is also a JS program with the exact same semantics, this is a correct thing to do.

(Since you're noodling around in about:config you should probably keep in mind that the names of the switches do not necessarily clearly imply what those switches do; these switches are in some cases mainly intended for internal and testing use.)