port virtual machine from NaCl to WebAssembly aka Wasm

[illwieckz]

May be useful: https://bytecodealliance.org/articles/announcing-the-bytecode-alliance

Wasm runtime list: https://github.com/appcypher/awesome-wasm-runtimes

See also:

• Wasm hardware support (including 32-bit like Windows i686 and Linux armhf) #757

[illwieckz]

There is also a list of Wasm runtimes there: https://gitlab.com/xonotic/xonotic/issues/244#sandboxing

[illwieckz]

@Kangz do you have any opinion on existing Wasm runtimes?

[illwieckz]

Dropping NaCl would also help us to drop the external deps download.

[DolceTriade]

It would change the external_deps download. The external_deps download downloads the NaCl toolchain and some common NaCl libraries. This would be instead changed to the wasm toolchain and the same libraries, but wasm...

[illwieckz]

I secretly hope we would be able one day to get rid of an SDK download at build time, to rely on system tools or git submodules instead.

To me that external_deps download is part of the NaCl issue.

[DolceTriade]

I mean, you can repackage the SDK as a submodule instead. I prefer having the build system "magically" ensure you have all the requisite dependencies.

[illwieckz]

I would prefer a submodule than what we currently do as I agree with people being concerned by random download done at CMake time. That said, it's better to invest time in Wasm and get rid of NaCl in the process than making NaCl a submodule.

Does using NaCl as a submodule would help Unvanquished to run outside of i386/amd64 or it's not only a limitation of our toolchain but a limitation of NaCl itself?

Nocrogiting: wasm works by way of LLVM, it would probably be more worthwhile to use that in the compile stack and leave wasm out of it. Same goes for rust-to-native I believe.

[Kangz]

After seeing @illwieckz's talk at MiniDebConf I'd be interested in taking this on to avoid relying on deprecated technologies (and eventually forking PNaCl). I haven't done an extensive comparison of runtimes but wasmer and wasmtime both seem fairly mature. I think an important selling point of wasmtime is that it supports debugging the webassembly module which will be quite useful to developers of games using Daemon.

One big difference between WASM and PNaCl will be that the gamelogic won't be in a separate process anymore but in a sandbox inside the engine's process. It's a bit of a security regression but there doesn't seem to be portable sandboxing libraries we can use (Chromium's source code doesn't count and it is very complex). For PNaCl we had to make most syscalls asynchronous, maybe being in process will allow moving back to synchronous calls for performance in some cases?

Another thing is that I don't know how well the WASM runtimes support spawning threads from inside WASM, not that our gamelogic does it at the moment, but it might be useful in the future.

[Kangz]

I also forgot to tag @Amanieu, WDYT about using wasmtime instead of PNaCl in particular security wise?