Intra-module Sandboxing: Zero-Cost Isolation for Statically Linked WebAssembly Modules

[ttraenkler]

In response to Does the Component Model Require Extra Copying? by @lukewagner, I'd like to share an idea that could be called intra-module sandboxing — a possible point in the design space between shared-nothing and shared-everything, aimed at eliminating the runtime cost of cross-module boundaries in general: bulk memory copies, Canonical ABI lift/lower overhead, hot-spot function call penalties, and duplicated runtime library code — while preserving interface-enforced isolation as a statically checkable property.

Idea

After merging two modules (à la wasm-merge), each module retains its own state and still communicates only through declared imports/exports. Instead of paying the cost of cross-module boundaries at runtime, functions exported by module A have all their indexed state — memories, tables, globals, tags — statically embedded as Wasm immediates after the merge, making them candidates for full inlining by a post-merge optimizer or JIT. Linear memory with multi-memory enabled is one concrete instance of this: module A exports accessor functions that, after the merge, have A's memory index statically embedded as a Wasm immediate:

;; A owns a UTF-8 string in its linear memory (index 1 after merge)
;; B calls this without ever receiving a copy of the buffer
(func (export "string_byte") (param $base i32) (param $i i32) (result i32)
  (i32.load8_u (i32.add (local.get $base) (local.get $i)))
)

Module B calls string_byte without ever holding a raw pointer into A's memory. If the accessor is inlined by a post-merge optimizer (e.g. Binaryen) or the JIT, it reduces to a single i32.load8_u — the sandbox boundary is enforced at the pre-merge interface level and completely erased by inlining. No bulk copy, no lift/lower ABI glue, no call overhead. The same applies to any hot-spot function call across the boundary regardless of the types involved: after merge and inlining, the Canonical ABI overhead disappears entirely.

Intra-module sandboxing could be a third linking mode alongside shared-nothing and shared-everything, supported by composition toolchains like wac or jco — chosen at link time depending on the trust and performance requirements of a given module pair.

(A related but distinct direction is allowing direct bounded memory region access across module boundaries enforced by static analysis — essentially borrow and move semantics for linear memory regions at the binary level, complementing what resource own and resource borrow already do at the WIT level. This is a bit related to #568 but needs no new instructions.)

Sharing Trusted Libraries Across Sandboxed Modules

For a trusted runtime library like wasi-libc, the current options are unsatisfying:

• Shared-nothing: each module gets its own copy of libc — safe, but N copies means N times the binary size and no code sharing
• Shared-everything: one copy of libc shared across all modules — no duplication, but full access to each other's memory, eliminating isolation entirely
• Intra-module sandboxing with N copies: each sandboxed module could bundle its own libc and merge it — still N copies, but isolation is preserved. No improvement over shared-nothing on code size.

The better path is to parameterize libc over memory index and have the toolchain generate a thin adapter wrapper per call site with the index hardwired, so a single shared copy of libc can operate on any caller's memory partition without duplication and without sacrificing isolation:

(func $memcpy_generic (param $mem i32) (param $dst i32) (param $src i32) (param $len i32)
  ;; uses $mem as dynamic index
)

;; Generated adapter — trivially small, inlines at the call site
(func $memcpy_mem1 (param $dst i32) (param $src i32) (param $len i32)
  (call $memcpy_generic (i32.const 1) (local.get $dst) (local.get $src) (local.get $len))
)

After inlining and constant propagation, i32.const 1 flows into $memcpy_generic and the dynamic dispatch is eliminated — recovering a static immediate without duplicating the function body. Code size stays flat regardless of how many modules share the library.

Importantly, this does not require changes to library source code or compilers. A binary post-processing tool could scan any existing compiled Wasm library — including wasi-libc shipped as a plain .wasm file — identify exported functions that access linear memory, and automatically emit parameterized variants alongside the originals. This makes the adapter wrapper approach applicable to the existing compiled library ecosystem without modifications upstream.

Shipping Pre-Merge Modules and Provenance

The Component Model already has a well-defined notion of embedding multiple core modules as nested modules inside a single component binary. If pre-merge modules are shipped this way, the component format itself encodes which module is which — the runtime can read the structure, perform the merge itself, and has full provenance knowledge without any custom section or cryptographic binding. This is the clean path: runtime-owned linking via the component nested module format eliminates the provenance problem entirely, since the runtime never needs to trust an external record of index ownership.

This is not without precedent at the toolchain level. Clang already produces Wasm object files (.o) that embed multiple core modules with symbol and relocation metadata, encoding module boundaries in a structured container that the linker reads and resolves. The component nested module format is a natural evolution of the same idea at the component level — a structured multi-module container that the runtime can link, validate, and merge with full provenance knowledge.

The harder provenance case only arises for flat binaries produced by offline tools like wasm-merge outside the component ecosystem since the runtime cannot validate security boundaries are kept after the merge. This would shift the trust boundary to the point of merge since the result can be tampered with - possible today without runtime support but this validation should go in the component linker and ultimately the runtime when they gain component support.

Other Global State

The same principle extends to all indexed namespaces in Wasm, since all use static integer immediates. After the merge, assign disjoint index ranges per originating module and verify that each function only references indices from its own range — except through explicitly exported/imported accessor functions:

• Tables: cross-module table.get, table.set, or call_indirect against another module's table index is statically detectable
• Globals: a validator can confirm no instruction in B references a global index belonging to A
• Tags: the same partition applies to throw and catch instructions

Wasm GC is the harder case. GC allocations land on a shared opaque heap with no index immediate to partition on. One possible direction: validate that B does not instantiate types from A's type section directly, only receiving them as opaque references through A's exports. Whether that is sufficient — and how it interacts with structural type equivalence — is an open question.

Open Questions

1. Tooling: Should wac, jco, or wit-bindgen expose intra-module sandboxing as a first-class linking mode alongside shared-nothing and shared-everything, generating and verifying accessor patterns and adapter wrappers automatically? Or is this better handled as a dedicated binary post-processing step?
2. Dynamic memory index instructions: Would a memory.load/memory.store variant accepting a runtime memory index be worth pursuing as a Wasm proposal, to make the adapter wrapper pattern expressible without toolchain-specific conventions?

cc @lukewagner @fitzgen @alexcrichton @kripken @tlively — pointers to prior discussion and obvious holes very welcome.

[lukewagner]

Thanks for filing and all the consideration @ttraenkler. I can't say I have a mental model of what the semantics of this intermediate "Intra-module sandboxing with N copies" kind of linking would be, so maybe I'll start with a basic question: would there be any proposed changes or additions to the Component Model, or could this be implemented purely as a toolchain convention in terms of the existing features of Core WebAssembly and the Component Model? If 'yes', that'd be attractive and I'd encourage you to build a prototype to show us how it works in terms of some example code.

[tschneidereit]

If I'm not missing something, the parts of what you're describing that don't introduce new semantics sound a lot like what meld already does. (The parts around sharing memory regions would have to have answers for other linking/composition modes to be viable, so I'm not focusing on those.)

Additionally, the described cross-component inlining can be done by the runtime without this transformation, and is indeed a big part of the motivation for the inlining support Cranelift and Wasmtime gained a short while ago

For wasi-libc, an even better approach might be to compile it to a shar3d library, which can b3 deduplicated across components, while still supporting inlining of hot code paths. That way, a single binary for (any specific version of) it needs to be deployed and loaded into memory, except for the inlined functions.

It's for exactly the provenance reasons you describe that I think this combination of approaches might ultimately be better, while effectively being largely what you describe here.

[ttraenkler]

Thanks @lukewagner! To answer directly: no spec changes are required. This can be done today purely as a toolchain convention on top of existing Core WebAssembly and Component Model features.

I have generated a prototype here using a Rust port of wasm-merge based on wasmparser and wasm-encoder that can merge core but also component modules and could serve as a POC for something that could land upstream in wasm-tools to serve wac and jco as a standalone merge tool.

(Note: my knowledge of the toolchain internals is limited so some of the details below may be imprecise — corrections welcome.)

1. Multi-memory — already shipping
2. wasm-merge — already merges modules and re-indexes memories, tables, globals and tags into disjoint ranges
3. wasm-opt inlining pass — capable of inlining the accessor functions as an explicit post-merge step via wasm-opt --inlining, recovering direct loads at zero call overhead
4. Component Model nested modules — already provide a structured container encoding module provenance for runtime-owned linking

The mechanics already work in toolchains like Binaryen's wasm-merge today — modules are merged and indices are re-indexed into disjoint ranges. What is missing is the security framing: wasm-merge does not currently treat these boundaries as enforced sandbox boundaries, only as a linking convention.

The key question is whether this pattern can hold up as a verifiable security boundary. If so, it could be a more secure default for shared-everything static linking of core modules within a component — reducing the supply chain attack surface and raising the default isolation level from shared-everything to shared-interfaces for modules that do not need access to each other's internals.

Here is a minimal example showing the full pipeline. Module A owns a UTF-8 string and exports a byte accessor. Module B reads from it:

Module A (before merge):

(module
  (memory (export "mem") 1)
  (data (i32.const 0) "hello")
  (func (export "string_byte") (param $i i32) (result i32)
    (i32.load8_u (local.get $i))
  )
)

Module B (before merge):

(module
  (import "a" "string_byte" (func $string_byte (param i32) (result i32)))
  (func (export "read_first") (result i32)
    (call $string_byte (i32.const 0))
  )
)

After wasm-merge with multi-memory — A's memory is assigned index 1, the import is resolved, and string_byte now has A's memory index statically embedded:

(module
  (memory $mem_b 1)   ;; B's memory — index 0
  (memory $mem_a 1)   ;; A's memory — index 1
  (data (i32.const 0) "hello")
  (func $string_byte (param $i i32) (result i32)
    (i32.load8_u memory 1 (local.get $i))  ;; index 1 is a static immediate
  )
  (func (export "read_first") (result i32)
    (call $string_byte (i32.const 0))
  )
)

After wasm-opt --inlining — the call is completely erased:

(func (export "read_first") (result i32)
  (i32.load8_u memory 1 (i32.const 0))  ;; direct load, no call, no copy
)

The full pipeline on the command line:

# Step 1: merge with multi-memory enabled
wasm-merge a.wasm a b.wasm b --enable-multi-memory -o merged.wasm

# Step 2: inline accessor functions
wasm-opt --inlining merged.wasm -o optimized.wasm

# Optional: lower to single memory for older runtimes (loses the sandbox boundary)
# wasm-opt --multi-memory-lowering optimized.wasm -o lowered.wasm

B never held a pointer into A's memory. The isolation guarantee existed at the pre-merge interface level and was erased by inlining — identical output to shared-everything, with interface-enforced isolation at the source level. Alternatively, the same result can be achieved at runtime without an offline merge step via Wasmtime's new inliner, which targets exactly this case of cross-module calls within a component — though it is currently off by default and does not yet enforce the sandbox boundary.

---

Note: wasm-merge operates on raw core Wasm modules and does not support the Component Model binary format. wasm-tools component link, which does operate on the component format, currently uses a single shared linear memory following the shared-everything dynamic linking convention — it does not yet support multi-memory. Since per-module memory partitioning via multi-memory is a prerequisite for the sandbox boundary to exist, a sandbox-aware linking mode would require adding multi-memory support to the component linking pipeline. The component format remains the right long-term distribution path for provenance reasons.

---

As a Component Model nested module (with toolchain support):

The same relationship expressed as a component, where the runtime owns the merge and has full provenance knowledge:

(component
  (core module $a
    (memory (export "mem") 1)
    (data (i32.const 0) "hello")
    (func (export "string_byte") (param i32) (result i32)
      (i32.load8_u (local.get 0))
    )
  )
  (core module $b
    (import "a" "string_byte" (func (param i32) (result i32)))
    (func (export "read_first") (result i32)
      (call 0 (i32.const 0))
    )
  )
  (core instance $ia (instantiate $a))
  (core instance $ib (instantiate $b
    (with "a" (instance $ia))
  ))
)

In this form the component binary encodes module provenance directly — the runtime knows which functions and memories originate from $a and which from $b without any custom section or cryptographic binding. A sandbox-aware toolchain could use this format as the distribution path: ship modules as nested core modules within a component, verify the sandbox boundary structurally at link time, then apply the multi-memory merge and wasm-opt --inlining pipeline as an optimization step. No new Component Model primitives are required — only a new multi-memory-based linking convention on top of what already exists.

---

(P.S: To clarify, the "intra-module sandboxing with N copies" point was only to illustrate an idea how to deduplicate library code in the special case where many modules in a compilation unit need the same library like libc — not a core part of the proposal. As @tschneidereit pointed out this might not actually be a problem for runtimes like wasmtime in the future since they could simply instantiate a shared module multiple times and only duplicate the inlined calls if I understand correctly.)

[ttraenkler]

Supply chain attacks have become increasingly popular without a good solution (see NPM) and in the age of AI this will only accelerate. Having a good strategy for isolation not only between components but also for isolating dependencies that require isolation with less overhead would be a strong argument for Wasm.

If I'm not missing something, the parts of what you're describing that don't introduce new semantics sound a lot like what meld already does. (The parts around sharing memory regions would have to have answers for other linking/composition modes to be viable, so I'm not focusing on those.)

@tschneidereit: Thanks for the pointer to @avrabe's work on meld.

The approach aligns well with what I am describing — meld already implements component fusion securely, with the Canonical ABI trampolines handling copying, ownership, and lifetime cleanly for structured data.

Where the proposals differ is in how structured data crosses the boundary. Meld copies data via cabi_realloc + memory.copy — safe and correct, but pays the copy cost. This proposal currently only passes scalar values through accessor functions, which sidesteps the problem with single loads and stores. When a string or array needs to be passed, the toolchain would need to generate secure index-bounded per-element accessor functions, which for dense sequential access may not always be faster than a single bulk memory.copy.

An entirely optional future optimization could pass a resource with typed accessor methods defined in WIT — for example a string-view resource with get-byte and length methods. This maps naturally onto the existing resource borrow<T> and resource own<T> types in the Component Model:

• Read-only borrow via borrow<string-view>: the callee calls accessor methods on the resource, which are implemented by the caller and have access only to the caller's memory. The toolchain can automatically inject bounds checks because it generates both sides — the resource layout in the caller and the accessor bindings in the callee — from the same WIT contract. By convention the resource handle is a pointer to a length-prefixed buffer: the first 4 bytes are the length, followed by that many bytes of data. Because the toolchain wrote both sides it knows this layout and injects the length load and bounds check automatically into every generated accessor. For fixed-size regions bounds are fully static; for variable-length regions like strings, dynamic bounds checks are required per access. Automatic bounds check injection works reliably when both modules are compiled by a WIT-aware toolchain that controls the resource layout — languages like Rust (&[T]), C++ (std::span, std::vector), or any language whose standard collections carry length alongside the pointer. For raw C code with pointer arrays (int* a) where the length is tracked separately or not at all, the programmer must explicitly wrap the pointer and length together — for example as a struct { int* ptr; size_t len; } — before the toolchain can inject bounds checks automatically. This means it works best with languages that carry length information as part of the type, and requires explicit wrapping for raw C pointer code. Caller retains ownership throughout.

• Move via own<string-view>: the callee gets full read-write access for the duration of the call. In synchronous code the ownership transfer is enforced by the call boundary itself — the caller cannot execute while the callee holds the resource. Ownership reverts on return.

In both cases the lifetime is the function call, enforced structurally by synchronous execution with no runtime reference counting or GC needed.

This approach is essentially a polyfill for the mappableref type proposed in #568 — the (base, len) scalar pair is a polyfill for the native reference, the accessor function with injected bounds checks is a polyfill for the runtime's automatic enforcement, and the multi-memory index partitioning is a polyfill for the memory isolation mappableref would provide natively. After wasm-opt --inlining the polyfill has zero overhead in the common case. The interface at the WIT level — resource borrow<T> or a future memory-region type — stays the same throughout, and the toolchain can switch the lowering strategy from the polyfill to the native mappableref implementation transparently once runtimes support it. This means the proposal is not in tension with #568 but rather provides a path to ship the semantics today while the native primitive matures.

Additionally, the described cross-component inlining can be done by the runtime without this transformation, and is indeed a big part of the motivation for the [inlining support](https://bytecodealliance.org/articles/inliner) Cranelift and Wasmtime gained a short while ago

Yes, I am looking forward to this being enabled by default and broader runtime support, until then this would be a useful polyfill.

For wasi-libc, an even better approach might be to compile it to a shared library, which can be deduplicated across components, while still supporting inlining of hot code paths. That way, a single binary for (any specific version of) it needs to be deployed and loaded into memory, except for the inlined functions.

This would be ideal, looking forward to it. Until runtimes catch up, a polyfilling strategy like proven wildly successful in the case of ES5 can unlock real world use cases and also inform the standardization process.

[lukewagner]

I see, thanks for explaining. So it sounds like your goal is to use multiple memories and to enforce a strong security boundary, and the goal is not to allow, e.g., module A or B to share a single linear memory or hold raw pointers into each others' distinct linear memories, which makes sense.

If that is the case, I think your example with read_first points in the direction of lazy lowering. In particular, if read_first's goal is to enforce a security boundary, read_first can't simply take a raw i32 pointer and indiscriminately load from it (because then B can read anywhere in A's memory, which would be roughly equivalent to B importing A's linear memory). Instead, module B needs to be given some form of (i32) handle that indexes into a table outside of B's control that contains the real (trusted) pointer into A's memory. read_first also needs to worry about lifetime so that A can free/reuse the memory in the future and not have to keep it allocated forever "just in case". And when you put (1) handles to values with (2) lifetimes enforced by call scoping rules, that's basically lazy lowering. And then the nice thing about this approach is that we don't need to introduce a new form of linking; it's just WIT and component linking as usual with a new-and-improved ABI.

[ttraenkler]

Thanks @lukewagner, good point — as also clarified in the discussion with @tschneidereit, the raw i32 index in string_byte needs bounds checking to enforce the security boundary, either statically for fixed-size regions or via a runtime trap for variable-length ones — e.g. via a memory region resource handle that carries the length and from which the toolchain can inject bounds checks automatically.

The lazy lowering / resource handle approach adds an additional table lookup indirection compared to a bounds-checked accessor, but after optimization both should converge to equivalent code — and in both cases B cannot read outside the declared region because the accessor traps on any out-of-bounds access.

Both approaches ultimately need a bounds check — the table approach adds pointer opacity on top of it, meaning B cannot even reason about the underlying address space, which is stronger security. In the statically verifiable case — fixed-size regions, constant indices, post-merge inlining — both approaches converge: the optimizer can eliminate both the bounds check and the table lookup entirely, leaving a single direct load with zero overhead. For variable-length regions the only runtime cost in both cases is the bounds check against the length — one comparison per access — which is the same regardless of whether a table or a direct accessor is used.

As you say, no new linking mode is needed at the component composition level. What does need to be defined is a parameter and return type sharing mode — how ownership, read- or write-only access, and bounded region passing are expressed in WIT and enforced by the toolchain, whether via resource handles with lazy lowering or bounds-checked accessors with an agreed layout convention.

Most common cross-module function signatures map directly onto these patterns without any extra work. Note that not all languages have explicit notation for ownership transfer — in C, void uppercase(char* buf, size_t len) looks identical whether the callee owns the buffer permanently, for the duration of the call, or not at all. Languages that do have explicit ownership notation map naturally:

Read-only borrow:

// C — const pointer signals read-only intent (by convention)
size_t count_vowels(const char* s, size_t len);

// C++ — string_view is a non-owning read-only view (by type)
size_t count_vowels(std::string_view s);

// Rust — &str enforced by borrow checker (enforced)
fn count_vowels(s: &str) -> usize;

// TypeScript — branded type signals intent (by type)
function countVowels(s: Borrow<Uint8Array>): number;

Call-scoped mutable borrow:

// C — no notation, annotated via preprocessor macro (by convention)
void uppercase(WASM_BORROW_MUT(char* buf, size_t len));

// C++ — span is a non-owning mutable view (by type)
[[wasm::borrow_mut]] void uppercase(std::span<char> buf);

// Rust — &mut enforced by borrow checker, ownership returns automatically (enforced)
fn uppercase(s: &mut str);

// TypeScript — branded type signals intent (by type)
function uppercase(buf: BorrowMut<Uint8Array>): void;

Call-scoped move:

// C — no notation, annotated via preprocessor macro (by convention)
void process(WASM_MOVE(uint8_t* buf, size_t len));

// C++ — && signals explicit move, result returned (by type)
[[wasm::move]] std::vector<uint8_t> process(std::vector<uint8_t>&& buf);

// Rust — Vec passed by value and returned, caller gets ownership back (enforced)
fn process(buf: Vec<u8>) -> Vec<u8>;

// TypeScript — branded type signals intent (by type)
function process(buf: Move<Uint8Array>): Uint8Array;

Permanent move:

// C — no notation, annotated via preprocessor macro (by convention)
void send_packet(WASM_MOVE_PERMANENT(uint8_t* buf, size_t len));

// C++ — && signals explicit move, no return (by type)
[[wasm::move_permanent]] void send_packet(std::vector<uint8_t>&& buf);

// Rust — Vec consumed, compile error if used after call (enforced)
fn send_packet(buf: Vec<u8>);

// TypeScript — branded type signals intent, value detached after call (by type)
function sendPacket(buf: MovePermanent<Uint8Array>): void;

In all cases the toolchain reads the ownership annotation — whether a native language construct, a C++ attribute, a C preprocessor macro, or a TypeScript branded type — and generates the corresponding WIT bindings and bounds-checked accessor implementations automatically. For C where the language has no ownership primitives, the macro annotation is the explicit opt-in that makes the intent machine-readable.

As the examples above show, read-only and call-scoped move semantics already provide shared-nothing equivalent security — the callee cannot access anything outside the declared region, and at any point in time only one side holds access. The only case that deliberately relaxes this guarantee is read-write shared access, which requires either mutual exclusion or an intentional shared-mutable design such as a ring buffer — and in synchronous single-threaded Wasm the call boundary enforces mutual exclusion naturally.

More broadly, this means that component-style shared-nothing linking could become the default inside a component as well — not just between components. Today core modules inside a component share everything by convention. With multi-memory and accessor functions as the default linking strategy, isolation would be the default and shared access would be the explicit opt-in, raising the baseline security of statically linked Wasm without requiring any changes to the Component Model itself.

[ttraenkler]

One more thought: this approach could also address a pain point for Component Model adoption in runtimes that do not have the resources to implement it natively in the near future — embedded interpreters, lightweight edge runtimes, or V8 in the browser — and help solve the chicken-and-egg problem where implementers wait for user adoption and users wait for runtime support - a problem transpilers solved for ES5 to resolve this deadlock.

By producing a flat core Wasm binary that runs on any runtime with multi-memory support today, developers can ship componentised code with shared-nothing style isolation without waiting for the full Component Model stack to land everywhere. It also reduces toolchain complexity and runtime overhead, which are common objections to Component Model adoption — the output is just a standard optimised core Wasm module with no new runtime machinery required.

The upgrade path is clean: as runtimes gain native Component Model support, the toolchain switches from offline merge to native linking without any changes to the application code or WIT interfaces. Practically, this would fit naturally in wasm-tools as a new optimization pipeline step — merge, inject bounds checks, inline — and propagate automatically to wac and jco since both depend on the wasm-tools crate family — a single implementation that the whole toolchain ecosystem inherits.

That said, this needs to be properly vetted for security flaws and edge cases before being promoted as a pattern — the ideas here are promising but the details around bounds checking, ownership enforcement, and provenance all need careful scrutiny before this could be recommended as a default strategy.

[lukewagner]

On the topic of easing component-model runtime implementation: check out recent and ongoing discussion on bytecodealliance/rfcs#46 which sounds rather like what you're suggesting in terms of smashing (most) of a component together into a core wasm module that can run on a core wasm engine implementing the right core function imports.