Running a replaceable Wasm module inside a host application raises a practical question: what stops that module from accessing the rest of the system? Sandboxing limits what the module can reach. It receives input through direct arguments or its own memory buffer; access beyond the sandbox depends on what the host runtime permits. section 10.1
A Wasm module relies on the virtual machine for access to hardware and services. Each module manages its own memory rather than another module’s memory. This makes the VM’s design important: the host must handle the data it reads from and writes to a module. section 10.6
Passing data through module memory requires a deliberate sequence:
- Allocate space inside the module and obtain its memory location. section 10.6
- Have the host write input there, call the exported function, then read the result from module memory. section 10.6
A search module inside a host
A Rust host configures a WASI-enabled VM, registers a Wasm search module, and obtains its memory and allocation function. The module exports a search function that reads an input string from memory and returns a result through memory. The search runs behind the module boundary, but the host still has to manage that boundary correctly. section 10.6
Listing 10.33 [paper_search|book_search]/src/main.rs: Allocating function
use std::os::raw::{c_void, c_int};
use std::mem;
#[no_mangle]
pub extern fn allocate(size: usize) -> *mut c_void {
let mut buffer = Vec::with_capacity(size); #1
let pointer = buffer.as_mut_ptr(); #2
mem::forget(buffer); #3
pointer as *mut c_void #4
}
The exported Rust allocation function shows how a module supplies a pointer to memory the host can use for input. section 10.6
