Per-allocation memory safety on Core Wasm: host imports, com · wasmtime

We are designing a language compiler targeting Core WebAssembly, initially embedded in a JavaScript/TypeScript host.

Secret bytes must temporarily enter guest memory for computation. Keeping all bytes exclusively in a host-side capability table would change our requirement.

We propose a private host module that supplies a secret-read import, tracks allocation identity and lifetime separately from numeric addresses, controls publication to a named consumer, and performs cleanup. The application would not receive raw instance, memory or export handles.

We understand that these host checks do not automatically constrain direct guest loads/stores within linear memory. We also distinguish logical cleanup from guaranteed physical erasure or side-channel protection.

What existing, maintainable approach would you recommend for enforcing per-allocation bounds and lifetime for this guest-byte requirement on an unmodified Core Wasm engine—compiler instrumentation with validation, compartmentalization, or another mechanism—and where would an MSWasm-style runtime extension become necessary?

We would particularly appreciate implementation references that state their trust assumptions and enforcement limits.

Chris Fallin (Sep 27 2026 at 20:10):

@PHILLIP BOOTH can you detail your security requirements / threat model a little bit more?

Your description of a separate module that manages secrets sounds like a reasonable way to insert a layer at which you can enforce invariants, prevent double-frees/use-after-frees, etc. In essence this is an ad-hoc implementation of "handles" from the component model, which are also managed outside the guest.

You seem also to be implying that you want memory safety within a module though, with your mention of MSWasm. A scheme like that is in essence moving enforcement from dynamic checks at a narrow interface (inter-module/inter-component ABI) to static checks proving a property across all raw loads and stores. You get more efficiency by doing that but at the cost of a larger TCB and more complexity.

In summary: it'd help to know a bit more detail about what problem exactly you're trying to solve. Which code is untrusted, which code is trusted, what performance characteristics do you want, etc?

PHILLIP BOOTH (Sep 28 2026 at 21:51):

Our immediate threat model is a hostile or mistaken caller supplying protected-object references, including stale or replayed requests. We trust the host’s authentication, grant enforcement and protected-data provider, subject to their own review; we do not claim protection against arbitrary malicious code already executing in that host process. We also do not equate logical cleanup with guaranteed physical erasure or side-channel resistance.

We are separating two designs. For the first protected operation, we can keep plaintext under a host-owned operation and not put it in Wasm at all. Host-managed handles and checks at that boundary seem appropriate there.

The original, harder requirement is different: plaintext temporarily enters a Core Wasm guest for computation. We want per-allocation bounds and lifetime enforcement even if guest code is buggy. We agree that hiding the instance from the application and checking host imports cannot constrain the guest’s own raw loads and stores. We would include a compiler and validator in the trusted computing base if that is the practical route, but would not treat an arbitrary unvalidated guest binary as safe.

We have no fixed latency target yet. Bounded copies and per-operation checks are acceptable while establishing the security property; we would measure before optimizing. Given those assumptions, is compiler-inserted checking plus validation on an unmodified Core Wasm engine a maintainable approach for the guest-byte case? Or is there an existing mechanism or implementation you would recommend—and which threat would it actually cover?

Chris Fallin (Sep 28 2026 at 21:57):

It seems to me that, if you assume a buggy guest and you also put protected data inside the guest, your choices are either

But for the latter you still have to analyze the guest's logic somehow to show that it's using the plaintext in some appropriate way. I suspect you run into Rice's Theorem here: you either have to admit a subset of all valid (safe, non-tainted, ...) programs, or you have to admit any memory-safe program and some of those may still have logical leaks of the data.

I guess the "in the spirit of Wasm" answer would be to continue to use the instance boundary as the isolation boundary, so: keep the plaintext out of the untrusted guest, always; give the guest operations it can request that are performed on its behalf by some other (trusted) computation layer wrapped around the plaintext.

PHILLIP BOOTH (Sep 28 2026 at 23:43):

Thanks, Chris. This map shows the boundary we now intend for the first protected operation; it is an architecture sketch, not a claim that the product already implements it.

Untrusted guest -- opaque operation request --> Trusted host
                                                |
                         host-derived caller identity + grant check
                         protected provider -> host-owned secret bytes
                         approved computation -> output policy
                         cleanup/accounting -> permitted result only
Untrusted guest <-- permitted result or refusal --

The guest receives neither plaintext nor a raw memory handle. The host must constrain both the requested operation and what its result may disclose; repeated calls must not become an extraction oracle.

We will treat the original “plaintext inside a buggy Core Wasm guest” requirement separately. Host import checks cannot constrain that guest’s raw loads and stores. Until we have a stronger, validated mechanism, we would treat its outputs as tainted and discard the instance rather than claim per-allocation secrecy.

Is that a fair application of the instance boundary you recommend? Are there Wasmtime host-call or component examples you would point us to for the host-owned operation?

Chris Fallin (Sep 28 2026 at 23:47):

(as an aside: I'm getting a little bit of LLM vibes from "It is an architecture sketch, not a claim that the product already implements it." Make sure you're conforming to our AI policy and writing all messages here on Zulip by hand; apologies if false positive)

PHILLIP BOOTH (Sep 29 2026 at 18:16):

Fair point. I used AI to help phrase that message and should have checked the Zulip policy first—sorry. I see now that I was largely restating your suggestion. Thanks for taking the time; I’ll try it against our use case and come back only if I find a specific gap. Thank you ever so much for your help.

Stream: wasmtime