WALI: WebAssembly Linux Interface

• WebAssembly Linux Interface (WALI) is a virtualization layer that maps the Linux syscall ABI to Wasm, enabling near-native performance and full POSIX support.
• It employs a multi-layer design that routes syscall calls through an extended Wasm engine with efficient bounds checking and low startup latency.
• WALI ensures secure sandboxing with granular capability control and effective signal handling, allowing legacy applications to run unmodified within Wasm sandboxes.

The WebAssembly Linux Interface (WALI) is a thin virtualization layer that exposes the Linux userspace syscall ABI directly as a first-class host interface for WebAssembly (Wasm) modules. This enables Wasm environments to achieve near-native performance and full POSIX compatibility while maintaining strong sandboxing guarantees through Wasm’s architecture. WALI virtualizes the bottom layer of userspace, permitting unmodified legacy applications to execute within Wasm sandboxes and allowing higher-level capability-based APIs, such as WASI, to be layered on top. Its implementation requires approximately 2,000 lines of C to extend a Wasm engine, yielding efficient syscall handling, low memory footprint, and minimal startup latency. The approach permits granular capability control, sandboxing, and efficient signal handling, serving as a universal interface between Wasm modules and the Linux kernel (Ramesh et al., 2023).

1. Architecture and Layering

WALI is architected as a multi-layer system that binds Wasm modules to Linux syscalls through an extended Wasm engine. User code written in languages such as C, C++, Rust, or Go is compiled into Wasm bytecode, encapsulated as ELF or Wasm modules. The Wasm engine—augmented by WALI—hosts a table of name-bound functions (e.g., _wali_open, _wali_read) mapped to native Linux syscalls. Critical engine components include a memory-to-native-address translator, signal management infrastructure, and safepoint insertion for signal delivery. The lowest layer, the Linux kernel, is accessed via its native syscall interface, with all kernel interactions funneled through the WALI interface.

This structure leverages the stability and universality of the Linux syscall ABI, obviating the need for reimplementing POSIX and enabling ISA portability. WebAssembly itself enforces in-process sandboxing and control-flow integrity (CFI) via unforgeable stack and linear memory, as well as compile-time indirect call tables. Consequently, raw syscall exposure does not compromise the safety guarantees native to Wasm.

2. System Call Mapping and Abstractions

WALI introduces a name-bound, virtual syscall API independent of ABI numbers. On engine startup, a mapping table $$M: \mathrm{Snames} \rightarrow (\text{ABI\_number}, \text{signature})$$ is established for the target architecture (e.g., x86_64). Wasm modules, whether importing functions from "wasi_snapshot_preview1" or "wali", invoke virtual syscalls that are mapped to host-native calls.

Each syscall is managed through a well-defined sequence:

1. Bounds-checking of pointer arguments against Wasm memory.
2. Translation to the equivalent host-native address.
3. Invocation of the native syscall using the computed address and arguments.
4. Return of the syscall result or a trap on error or access violation.

A representative subset of the syscall mapping, categorized by operation, is presented below:

Category	Virtual Name	Engine Overhead
File I/O	read, write, open	≈150–190 ns
File attrs	fstat, stat, lstat	≈120–180 ns
Memory	mmap, mremap, munmap	≈250–500 ns
Threads	clone, fork, exec	≈500 μs
Signals	rt_sigaction, rt_sigprocmask	≈110–700 ns

Complex struct arguments (e.g., stat buffers) are copied in and out using engine-defined layouts. Deprecated syscalls, such as brk, are mapped to no-ops, while memory management calls are unified. Signal delivery is virtualized; the engine maintains a separate sigmask and sigqueue per sandbox domain, with signals delivered at carefully-placed safepoints (function entries or loop headers).

3. Capability Model and Security

The foundational security abstraction in WALI is the sandbox domain $D_m$ for module $m$, defined as $D_m = (M_m, \mathrm{Cap}_m, \mathrm{Tid}_m)$:

• $M_m$: the isolated Wasm linear memory for $m$.
• $\mathrm{Cap}_m \subseteq \mathrm{Snames}$: the set of syscalls permitted for $m$.
• $\mathrm{Tid}_m$: thread-group IDs for $m$’s executions.

Capabilities are descriptors bound to table export entries, restricting modules to invoke only those syscalls explicitly granted. The enforcement property is:

$$\forall m\,.\;\forall s\in \mathrm{Snames}:\;\mathrm{invoke\_syscall}(m,s) \implies s\in \mathrm{Cap}_m.$$

This design enables least-privilege sandboxing by configuring minimal $\mathrm{Cap}_m$ sets. WALI preserves CFI: Wasm linear memory is non-addressable and non-executable, and indirect calls are checked at runtime. WALI’s host functions neither modify Wasm code nor memory except through specified syscalls. Arbitrary code execution at the kernel boundary is prevented by syscall filtering and address isolation. Remote code execution (RCE) is mitigated, as syscalls only accept numeric and pointer arguments subject to bounds checking.

WALI establishes a minimal trusted computing base (TCB), with approximately 2 KLOC of C constituting the sole code touching the syscall interface. All higher-level policy enforcement—filesystem, network capabilities—is implemented in user-space (e.g., WASI), not enforced by WALI directly.

4. Implementation Mechanisms

In its reference implementation atop the WebAssembly Micro Runtime (WAMR), WALI added approximately 2,000 lines of C binding around 137 common syscalls. The engine was extended to route "wasi_*" or "wali_*" imports to C stubs implementing address translation and struct marshaling. Regions created via memory mapping and signal registrations are actively tracked.

Typical code path:

• Wasm module invokes wali_read(fd, buf_ptr, len).
• Engine translates buf_ptr to host address (native_ptr = wasm_mem + buf_ptr).
• Engine invokes native SYS_read.
• Result is returned to Wasm as an integer.

Signal handling is realized as follows:

• Module registers handler $h$ for signal $sig$ via wali_rt_sigaction.
• Engine registers native handler, which enqueues $sig$ in the domain’s pending queue.
• At safepoints (loop headers), engine inspects the pending queue. If $sig$ is not masked, the handler $h$ is activated in Wasm via wasm_call(h, sig).

5. WASI Compatibility and Layering

WASI (WebAssembly System Interface) is implemented in the WALI system as a Wasm module (not in the engine), importing only WALI syscalls. High-level WASI calls (e.g., wasi_path_open) are translated to lower-level WALI syscalls (open, fstat, fchmod).

The benefits are:

• A unified stable syscall interface in the engine, facilitating portability.
• A small, stable TCB, since new WASI features do not augment engine complexity.
• All engines supporting WALI can execute WASI layers unmodified.

WALI offers complete Linux compatibility and legacy support, with the trade-off of Linux-only portability. WASI enables cross-OS portability with fine-grained capability management but has evolving semantics and incomplete POSIX coverage. Layering WASI atop WALI simultaneously achieves completeness and cross-platform reuse on WALI-capable hosts.

6. Performance Characteristics

Empirical evaluation was conducted using an 11th Gen Intel Core i7-1185G7 (underclocked to 1.2 GHz) and WAMR with AOT Wasm compilation. Benchmarks encompassed both microbenchmarks (top-30 Linux syscalls) and macrobenchmarks (bash, lua, sqlite, paho-mqtt).

Key metrics observed:

• Typical syscall overhead: 100–200 ns.
• mmap/mremap calls: ~500 ns (stateful tracking).
• clone(): ~500 μs, dominated by Wasm instance creation overhead.
• Signal registration: ~700 ns.

Signal safepoint polling at each individual bytecode instruction incurred 100–200% slowdown, but polling at function entry or loop headers kept overhead below 10%.

Memory footprint comparisons:

• Native: ~5–10 MB
• WALI (Wasm + engine): ~8 MB
• Docker container base: ~30 MB
• QEMU (KVM off): ~12 MB (KVM), ~100 MB (emulation)

Execution times relative to native processes:

• Docker: ≈1.05× native
• WALI (WAMR): 2.3× native (AOT Wasm code bottleneck)
• QEMU (KVM): 1.2–1.5× native; emulation mode much slower

Startup latencies:

• Docker container: ~500 ms
• WALI: ~10 ms
• For short-lived tasks (<50 ms total duration), WALI outperformed containers.

Bottlenecks included clone() overhead, address-space translation, and signal delivery. Optimizations such as lazy memory/COW and fast-clone in Wasmtime can reduce clone() latency to ~5 μs. The syscall path already supports zero-copy buffers and efficient bounds checks; signal delivery overhead can be minimized by restricting safepoint polling to loop headers or explicit callback points.

7. Context and Significance

WALI establishes direct Linux syscall virtualization as a minimal, performant, and secure mechanism for executing Wasm modules with POSIX compatibility. Its succinct engine augmentation (~2 KLOC C) balances performance, memory usage, and startup latency, placing it between traditional containers and full-system emulators in virtualization trade-offs. The design enables effortless reuse of existing software, rapid ecosystem expansion, and robust layering of capability systems (e.g., WASI) atop a stable syscall substrate. WALI demonstrates an effective pathway for bringing lightweight Linux virtualization to WebAssembly, with implications for efficiency, legacy support, and secure application deployment in Wasm-based environments (Ramesh et al., 2023).