Closed Bug 1566247 Opened 5 years ago Closed 5 years ago

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

Categories

(Core :: General, task)

task
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: shravanrn, Assigned: shravanrn, Mentored)

References

Details

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

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED

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.

Component: ImageLib → Javascript: WebAssembly
Blocks: 1566220
No longer blocks: Wasm-sandboxing
Component: Javascript: WebAssembly → General
You need to log in before you can comment on or make changes to this bug.