4 ms·

One question that really bugs me the the sandbox security model. I'm sure the model protects us from memory and IO hazards. But, what about CPU-time sharing pro

One question that really bugs me the the sandbox security model. I'm sure the model protects us from memory and IO hazards. But, what about CPU-time sharing protection? I have yet to know if WebAss (or any abstract machine out there) could provide protection from a rouge module, running at 100% CPU in an infinite loop. I'm sure a true virtual machine could limit such thing. Edit: spelling

pphysch 4y ago
What's the difference between <script>WebAssembly.instantiateStreaming(fetch("cpu_waster.wasm")...</script> and <script>while (true){};</script> ?
- kevingadd 4y ago
  The former is asynchronous.
  - pphysch 4y ago
    It's still gonna waste a whole CPU (at least)
flohofwoe 4y ago
It's the same as running a Javascript infinite loop. The browser will kill the tab if a WASM module doesn't yield back to the browser's event loop after a few seconds.
deathanatos 4y ago
Yes, they can. You instrument the module/byte code/JIT'd code to consume a virtual "gas", and when it's consumed, execution returns to the host. E.g., in wasmtime: https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.consume_fuel https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#... (I presume the browsers implement something similar, but I've not tested it to see.)
- kevingadd 4y ago
  No browser I'm aware of implements that under normal circumstances. If you run with the debugger open they do tend to insert a lot of instrumentation to enable pausing/breakpoints/etc but that comes at a massive performance hit - in some cases 'debugger open' WASM is slower than JS.
  - deathanatos 4y ago
    Interesting. I figured they would, given that "normal" JS will happily get aborted if it uses 100%. ("This site is slowing your machine down", etc.)
    - kevingadd 4y ago
      My guess is that the performance overhead of inserting it into wasm was judged unacceptable. It's a little odd to me, I was surprised when I discovered I couldn't realistically pause a tab running wasm benchmarks - often when I try to close the chrome tab it just hangs. The runtime I work on (.NET) inserts safepoints at back branches in some cases specifically to enable pausing for GC. It wouldn't surprise me if using WASM GC would cause the runtime to start inserting safepoints as well.
jayd16 4y ago
Can you perhaps rephrase your question? It seems like you're asking if the language will handle scheduling priority of a library? Isn't this the job of the browser/OS? Isn't this already handled in most browsers where each tab is its own process?
- mrbonner 4y ago
  I still stand by my question, though. If I consider WebAss is a VM, which I think in some extend, it already is given that it let the process owner control/limit memory and IO sandbox. But, my understanding is that a true VM also needs to provide CPU sandbox, right? To answer another question in this thread related to JS "while (true) {}", most browser would already warn about the script CPU time and allow us to terminate/stop the long running script. I could say the same for a true VM that would limit the number of CPUs to use or even execution time out. Even with the JVM, where there is no mechanism to limit the execution of the entire process, I can run JVM plugins/modules in a separate thread and set execution time limit in that contained thread.
nerpderp82 4y ago
It isn't built in but you could mitigate this by rewriting the wasm module to only execute for a certain number of iterations and then return to the outer context. This isn't currently handled in Js either. For Wasm engines that run outside of the brower, some do have the notion of cycle counting. Wasm is a true virtual machine.

pphysch 4y ago

What's the difference between <script>WebAssembly.instantiateStreaming(fetch("cpu_waster.wasm")...</script> and <script>while (true){};</script> ?

kevingadd 4y ago
The former is asynchronous.
- pphysch 4y ago
  It's still gonna waste a whole CPU (at least)

flohofwoe 4y ago

It's the same as running a Javascript infinite loop. The browser will kill the tab if a WASM module doesn't yield back to the browser's event loop after a few seconds.

deathanatos 4y ago

Yes, they can. You instrument the module/byte code/JIT'd code to consume a virtual "gas", and when it's consumed, execution returns to the host. E.g., in wasmtime: https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.consume_fuel https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#... (I presume the browsers implement something similar, but I've not tested it to see.)

kevingadd 4y ago
No browser I'm aware of implements that under normal circumstances. If you run with the debugger open they do tend to insert a lot of instrumentation to enable pausing/breakpoints/etc but that comes at a massive performance hit - in some cases 'debugger open' WASM is slower than JS.
- deathanatos 4y ago
  Interesting. I figured they would, given that "normal" JS will happily get aborted if it uses 100%. ("This site is slowing your machine down", etc.)
  - kevingadd 4y ago
    My guess is that the performance overhead of inserting it into wasm was judged unacceptable. It's a little odd to me, I was surprised when I discovered I couldn't realistically pause a tab running wasm benchmarks - often when I try to close the chrome tab it just hangs. The runtime I work on (.NET) inserts safepoints at back branches in some cases specifically to enable pausing for GC. It wouldn't surprise me if using WASM GC would cause the runtime to start inserting safepoints as well.

jayd16 4y ago

Can you perhaps rephrase your question? It seems like you're asking if the language will handle scheduling priority of a library? Isn't this the job of the browser/OS? Isn't this already handled in most browsers where each tab is its own process?

mrbonner 4y ago
I still stand by my question, though. If I consider WebAss is a VM, which I think in some extend, it already is given that it let the process owner control/limit memory and IO sandbox. But, my understanding is that a true VM also needs to provide CPU sandbox, right? To answer another question in this thread related to JS "while (true) {}", most browser would already warn about the script CPU time and allow us to terminate/stop the long running script. I could say the same for a true VM that would limit the number of CPUs to use or even execution time out. Even with the JVM, where there is no mechanism to limit the execution of the entire process, I can run JVM plugins/modules in a separate thread and set execution time limit in that contained thread.

nerpderp82 4y ago

It isn't built in but you could mitigate this by rewriting the wasm module to only execute for a certain number of iterations and then return to the outer context. This isn't currently handled in Js either. For Wasm engines that run outside of the brower, some do have the notion of cycle counting. Wasm is a true virtual machine.