Stream: git-wasmtime

Topic: wasmtime / issue #11178 Core WebAssembly libcalls are not...

Wasmtime GitHub notifications bot (Jul 03 2025 at 20:52):

alexcrichton opened issue #11178:

This is an issue describing a longstanding design issue within Wasmtime. There are no known actual issues with this, but this is something I believe nevertheless should be fixed over time.

The basic problem is that libcalls for core WebAssembly all look like:

fn the_libcall(
    store: &mut dyn VMStore,
    instance: Pin<&mut Instance>,
    // ... other parmas
) -> TheLibcallResult {
    // ...
}

where on the surface this is fine but the issue is that store is a mutable pointer which contains instance. That means that it's possible for Wasmtime, via safe code, to acquire a second Pin<&mut Instance> at the same time, pointing to the same instance. Thus these libcall definitions are not sound (it's possible to write safe code that leads to UB). The libcalls should all be practically safe for Wasmtime's purposes today, but it would be best for these libcalls to be sound, not just practically safe.

The general idea of how to solve this would be to match what component libcalls are doing:

fn the_libcall(
    store: &mut dyn VMStore,
    instance: Instance,
    // ... other parmas
) -> TheLibcallResult {
    // ...
}

Here Instance would notably be crate::Instance, not crate::runtime::vm::Instance. That means that the instance is effectively an index within the store which can be used to project out Pin<&mut Instance> but in doing so borrows the store and prevents other access to it. This is expected to have a minor performance hit in libcalls due to the fact that accessing Pin<&mut Instance> is a checked access when given just an Instance, but the cost of this is expected to be negligible given the cost of entering the libcall in the first place.

Wasmtime GitHub notifications bot (Jul 03 2025 at 20:52):

alexcrichton added the wasmtime:unsafe-code label to Issue #11178.

Wasmtime GitHub notifications bot (Aug 21 2025 at 22:30):

alexcrichton closed issue #11178:

This is an issue describing a longstanding design issue within Wasmtime. There are no known actual issues with this, but this is something I believe nevertheless should be fixed over time.

The basic problem is that libcalls for core WebAssembly all look like:

fn the_libcall(
    store: &mut dyn VMStore,
    instance: Pin<&mut Instance>,
    // ... other parmas
) -> TheLibcallResult {
    // ...
}

where on the surface this is fine but the issue is that store is a mutable pointer which contains instance. That means that it's possible for Wasmtime, via safe code, to acquire a second Pin<&mut Instance> at the same time, pointing to the same instance. Thus these libcall definitions are not sound (it's possible to write safe code that leads to UB). The libcalls should all be practically safe for Wasmtime's purposes today, but it would be best for these libcalls to be sound, not just practically safe.

The general idea of how to solve this would be to match what component libcalls are doing:

fn the_libcall(
    store: &mut dyn VMStore,
    instance: Instance,
    // ... other parmas
) -> TheLibcallResult {
    // ...
}

Here Instance would notably be crate::Instance, not crate::runtime::vm::Instance. That means that the instance is effectively an index within the store which can be used to project out Pin<&mut Instance> but in doing so borrows the store and prevents other access to it. This is expected to have a minor performance hit in libcalls due to the fact that accessing Pin<&mut Instance> is a checked access when given just an Instance, but the cost of this is expected to be negligible given the cost of entering the libcall in the first place.

Last updated: Dec 06 2025 at 07:03 UTC