How WebAssembly Handles System Calls and File IO

WebAssembly (Wasm) operates in a highly secured, sandboxed environment that restricts direct access to a computer’s hardware, file system, and network. To perform system calls like file input/output (I/O) or network requests, Wasm modules must rely on host-provided interfaces. This article explains how WebAssembly interacts with the outside world through browser-based APIs and the WebAssembly System Interface (WASI) to execute system-level operations safely.

The Sandbox and the Need for a Host

By design, WebAssembly has no built-in capabilities to interact with the operating system. It cannot open a file, read a network socket, or print to a console on its own. This isolation ensures security and portability across different platforms. To perform any of these actions, a Wasm module must import functions from its host environment—whether that host is a web browser or a standalone runtime like Wasmtime or Wasmer.

System Calls in the Browser via JavaScript

In a web browser, the host environment is JavaScript. WebAssembly handles system-like operations by delegating them to JavaScript APIs:

1. Importing Functions: During the compilation and instantiation of a Wasm module, JavaScript passes a set of functions (an import object) to the module. These functions can wrap standard Web APIs like fetch() for network requests or FileReader for file operations.
2. Calling the Host: When the Wasm program needs to fetch data, it calls the imported JavaScript function, passing pointers to its linear memory where the arguments or targets are stored.
3. Returning Data: JavaScript executes the asynchronous web request, writes the response directly back into the WebAssembly module’s shared memory, and notifies the Wasm code that the operation is complete.

Through this “glue code,” Wasm leverages the entire suite of browser capabilities without having direct access to the underlying OS.

System Calls Outside the Browser: WASI

For non-browser environments, using custom JavaScript wrappers is impractical. To solve this, the WebAssembly community developed the WebAssembly System Interface (WASI). WASI standardizes a set of POSIX-like system calls that Wasm modules can use across different runtimes.

Instead of writing custom host functions, developers compile their code (written in languages like Rust, C, or Go) against the WASI standard library. When compiled, the standard file I/O and network operations are translated into WASI system calls, such as:

• path_open to open a file.
• fd_read and fd_write to read from and write to file descriptors.
• sock_recv and sock_send for network socket operations.

The standalone WebAssembly runtime acts as the host, mapping these standardized WASI calls directly to the host operating system’s native system calls.

Capability-Based Security

Even with WASI, WebAssembly maintains strict security through a capability-based security model. A Wasm module cannot simply request access to /etc/passwd or arbitrary IP addresses.

When launching a WASI module, the user or host application must explicitly grant permissions. For example, the runtime can pre-open specific directories and pass those file descriptors to the Wasm module. The module is then physically incapable of accessing any files outside of those pre-approved paths. For networking, runtimes similarly restrict which ports and addresses a module is allowed to bind to or query, ensuring a high level of security.