1566247 - Evaluate wasmtime + cranelift (wasi target) to produce a compiled wasm library

Status: RESOLVED FIXED

(Core :: General, task)

Description

[Shravan Narayan]

Create the runtime to use a C library compiled with clang (to produce WASM) + wasmtime/cranelift (to produce assembly) in Firefox Code

Comment 1

[Shravan Narayan]

After some experiments, it seems there may be some limitations with the current architecture in wasmtime of WASI as a separate module.

To use an application compiled with cranelift + wasmtime-wasi, we need to run it with WASI (which provides a bunch of the system level hooks exposed to the WASM module). However, right now it looks the coordination between the compiled WASM application and the WASI module is done by the JIT's runtime (included in the wasmtime-jit package).

For instance, take the "__path_open" function provided by wasmtime-wasi. When this function is invoked by the compiled WASM module, wasmtime-jit runtime for setting up the WASM module's VMContext to permit this cross module call.

I think requiring a runtime like wasmtime-jit to permit this cross module invocations between the WASM application and the WASI module is reasonable for a JIT style environment where this is the norm.

However, for library sandboxing, we want to compile the library as a WASM application completely ahead of time and want it to be self sufficient without requiring a complicated runtime to execute it. There are probably ways to hack around this limitation, but these hacks may be too brittle for production.

We also checked the situation in Lucet. From our experiments, it seems that they do not organize WASI as a separate module and allow to generation of a compiled WASM module that is linked with WASI.