wasm-c-api callbacks need instance specific void* user p... · general

Callbacks sometimes need access to memory. Memory is instance specific.
Hence callbacks need to be able to securely identify the instance they are called from.

wasm_trap_t* my_callback(const wasm_val_t args[], wasm_val_t results[], void *user)

... which is assigned using (proposed) WASM_API_EXTERN void wasmtime_instance_userdata(const wasm_instance_t*, void *user);

Then I can cast my void pointer to that instance's wasm_memory_t pointer or a more complex struct depending on needs of the embedder.

Peter Huene (May 05 2020 at 17:57):

Hi Steve. The WebAssembly C API has wasm_func_new_with_env which accepts a void* for such purposes.

Peter Huene (May 05 2020 at 17:58):

Peter Huene (May 05 2020 at 17:59):

As that data is attached to the host function, not the instance. Wasmtime has extensions to the C-API to get the "caller", which can be used to access the memory.

Peter Huene (May 05 2020 at 18:01):

wasmtime_func_new and wasmtime_func_new_with_env use callbacks with a "caller", which you can call wasmtime_caller_export_get to get an export of.

Steve Williams (May 05 2020 at 18:30):

Thanks, Peter. Looked that up, it'll do for starters, but wasmtime_caller_export_get performs a string look up against potentially a huge export list, every call. So it'll work but its not performant. With respect, I prefer my approach.

& you're right, wasm_func_new_with_env isn't instance specific, so it's almost useful, but not quite :)

Steve Williams (May 05 2020 at 18:33):

If the wasmtime method can be morphed as suggested, anything that currently needs to perform an export lookup inside the callback can do so, by passing the export struct as its parameter, so my suggestion is backwards compatible with anything using current approach.

Please consider morphing as suggested as performance is an important consideration.

Steve Williams (May 06 2020 at 07:04):

This then needs pushing into the wasm-c-api spec as quickly as possible for the same reason there is such a thing. A consistent effective API. Without a reliable, secure, performant means of identifying the calling instance in callbacks, the API is ineffective beyond trivial examples (single instance invocations).

Steve Williams (May 06 2020 at 07:17):

minor: the project needs rebranding if you want it to reach its full potential. there's nothing "web" about this assembly format/system. web is primary use case & driver for secure assembly, but its not the only one.

blender 3d art package would do well to move from python to secure assembly for example.

Steve Williams (May 07 2020 at 08:30):

Think my workaround is to use wasm_func_new_with_env with one instance per store for the time being.

wasm-c-api currently lacks a means of determining the instance it was invoked from. · Issue #140 · WebAssembly/wasm-c-api

Callbacks sometimes need access to memory. Memory is instance specific. Hence callbacks need to be able to securely identify the instance they are called from. Proposed solution: Please extended C-...

Steve Williams (May 07 2020 at 11:17):

sigh. this is trivial. I'll just do it at some point. its not a security issue as Andreas states. We're trusted side.