wasmtime / issue #10133 Wasmtime c-api questions · git-wasmtime

Stream: git-wasmtime

Topic: wasmtime / issue #10133 Wasmtime c-api questions

Wasmtime GitHub notifications bot (Jan 28 2025 at 13:19):

mihaly-sisak opened issue #10133:

Hello all!
This is the first Rust project I am touching, so maybe I am completely misunderstanding something. I'm trying to build wasmtime-c-api to use for plugins in my simulation/game.

Following this tutorial: https://docs.wasmtime.dev/examples-minimal.html

The command I build with:
export CARGO_PROFILE_RELEASE_OPT_LEVEL=s
export CARGO_PROFILE_RELEASE_PANIC=abort
export CARGO_PROFILE_RELEASE_LTO=true
export CARGO_PROFILE_RELEASE_CODEGEN_UNITS=1
export CARGO_PROFILE_RELEASE_STRIP=debuginfo

cargo build \
    --package wasmtime-c-api \
    --release \
    --no-default-features \
    --features "disable-logging cranelift cache parallel-compilation wasi"
I plan for my users writing .wasm extensions, and loading them directly. If I understood things correctly I need cranelift to be able to do that. I also enabled parallel-compilation and cache to speed thing up and wasi to have a standard text i/o interface.

I have 2 question:
1) Compiling with this command yields the following conf.h
// WASMTIME_FEATURE_LIST
/* #undef WASMTIME_FEATURE_PROFILING */
/* #undef WASMTIME_FEATURE_WAT */
/* #undef WASMTIME_FEATURE_CACHE */
/* #undef WASMTIME_FEATURE_PARALLEL_COMPILATION */
/* #undef WASMTIME_FEATURE_WASI */
/* #undef WASMTIME_FEATURE_LOGGING */
#define WASMTIME_FEATURE_DISABLE_LOGGING
/* #undef WASMTIME_FEATURE_COREDUMP */
/* #undef WASMTIME_FEATURE_ADDR2LINE */
/* #undef WASMTIME_FEATURE_DEMANGLE */
/* #undef WASMTIME_FEATURE_THREADS */
/* #undef WASMTIME_FEATURE_GC */
/* #undef WASMTIME_FEATURE_GC_DRC */
/* #undef WASMTIME_FEATURE_GC_NULL */
/* #undef WASMTIME_FEATURE_ASYNC */
/* #undef WASMTIME_FEATURE_CRANELIFT */
/* #undef WASMTIME_FEATURE_WINCH */
/* #undef WASMTIME_FEATURE_DEBUG_BUILTINS */
// ... if you add a line above this be sure to change the other locations
// marked WASMTIME_FEATURE_LIST
It seem like in spite of me enabling cache, parallel-compilation and cranelift it is still not enabled somehow. What am I missing?

2) Can I cherry-pick wasi-proposals I enable? I want my extensions to have text i/o and access to only a specific folder (I found the preopen directory part) but that's it. I do not want them to be able to access the web/open ports. If I enable feature wasi does that enables wasmtime/wasi-http? Can I enable wasi without any network access?
I am confused about the Rust build process. Are there docs on the features? For example what does wmemcheck do? I want my users safe from potentially malicious extensions, do I need it? Same question with memory-protection-keys.

Wasmtime GitHub notifications bot (Jan 28 2025 at 14:08):

mihaly-sisak commented on issue #10133:

If I use cmake:

cmake -B _build -S . \
    -DWASMTIME_DISABLE_ALL_FEATURES=ON \
    -DWASMTIME_FEATURE_DISABLE_LOGGING=ON \
    -DWASMTIME_FEATURE_CRANELIFT=ON \
    -DWASMTIME_FEATURE_CACHE=ON \
    -DWASMTIME_FEATURE_PARALLEL_COMPILATION=ON \
    -DWASMTIME_FEATURE_WASI=ON \
    -DCMAKE_BUILD_TYPE=Release

cmake --build _build --config Release

Then the conf.h in the _build folder is correct.
But if I install it with cmake --install _build --prefix _install, then the file gets updated:

// WASMTIME_FEATURE_LIST
#define WASMTIME_FEATURE_PROFILING
#define WASMTIME_FEATURE_WAT
#define WASMTIME_FEATURE_CACHE
#define WASMTIME_FEATURE_PARALLEL_COMPILATION
#define WASMTIME_FEATURE_WASI
#define WASMTIME_FEATURE_LOGGING
/* #undef WASMTIME_FEATURE_DISABLE_LOGGING */
#define WASMTIME_FEATURE_COREDUMP
#define WASMTIME_FEATURE_ADDR2LINE
#define WASMTIME_FEATURE_DEMANGLE
#define WASMTIME_FEATURE_THREADS
#define WASMTIME_FEATURE_GC
#define WASMTIME_FEATURE_GC_DRC
#define WASMTIME_FEATURE_GC_NULL
#define WASMTIME_FEATURE_ASYNC
#define WASMTIME_FEATURE_CRANELIFT
#define WASMTIME_FEATURE_WINCH
#define WASMTIME_FEATURE_DEBUG_BUILTINS
// ... if you add a line above this be sure to change the other locations
// marked WASMTIME_FEATURE_LIST

wasmtime_compile_log.txt
In the beginning only features I choose are enabled, but after Built target wasmtime-crate it lists all features as enabled.

I'm not familiar with cargo so maybe I am overlooking something really obvious here.

Wasmtime GitHub notifications bot (Jan 28 2025 at 14:54):

mihaly-sisak edited issue #10133:

Hello all!
This is the first Rust project I am touching, so maybe I am completely misunderstanding something. I'm trying to build wasmtime-c-api to use for plugins in my simulation/game.

Following this tutorial: https://docs.wasmtime.dev/examples-minimal.html

The command I build with:
export CARGO_PROFILE_RELEASE_OPT_LEVEL=s
export CARGO_PROFILE_RELEASE_PANIC=abort
export CARGO_PROFILE_RELEASE_LTO=true
export CARGO_PROFILE_RELEASE_CODEGEN_UNITS=1
export CARGO_PROFILE_RELEASE_STRIP=debuginfo

cargo build \
    --package wasmtime-c-api \
    --release \
    --no-default-features \
    --features "disable-logging cranelift cache parallel-compilation wasi"
I plan for my users writing .wasm extensions, and loading them directly. If I understood things correctly I need cranelift to be able to do that. I also enabled parallel-compilation and cache to speed thing up and wasi to have a standard text i/o interface.

I have 2 question:
1) Compiling with this command yields the following conf.h
// WASMTIME_FEATURE_LIST
/* #undef WASMTIME_FEATURE_PROFILING */
/* #undef WASMTIME_FEATURE_WAT */
/* #undef WASMTIME_FEATURE_CACHE */
/* #undef WASMTIME_FEATURE_PARALLEL_COMPILATION */
/* #undef WASMTIME_FEATURE_WASI */
/* #undef WASMTIME_FEATURE_LOGGING */
#define WASMTIME_FEATURE_DISABLE_LOGGING
/* #undef WASMTIME_FEATURE_COREDUMP */
/* #undef WASMTIME_FEATURE_ADDR2LINE */
/* #undef WASMTIME_FEATURE_DEMANGLE */
/* #undef WASMTIME_FEATURE_THREADS */
/* #undef WASMTIME_FEATURE_GC */
/* #undef WASMTIME_FEATURE_GC_DRC */
/* #undef WASMTIME_FEATURE_GC_NULL */
/* #undef WASMTIME_FEATURE_ASYNC */
/* #undef WASMTIME_FEATURE_CRANELIFT */
/* #undef WASMTIME_FEATURE_WINCH */
/* #undef WASMTIME_FEATURE_DEBUG_BUILTINS */
// ... if you add a line above this be sure to change the other locations
// marked WASMTIME_FEATURE_LIST
It seems like in spite of me enabling cache, parallel-compilation and cranelift it is still not enabled somehow. What am I missing?

2) Can I cherry-pick wasi-proposals I enable? I want my extensions to have text i/o and access to only a specific folder (I found the preopen directory part) but that's it. I do not want them to be able to access the web/open ports. If I enable feature wasi does that enables wasmtime/wasi-http? Can I enable wasi without any network access?
I am confused about the Rust build process. Are there docs on the features? For example what does wmemcheck do? I want my users safe from potentially malicious extensions, do I need it? Same question with memory-protection-keys.

Wasmtime GitHub notifications bot (Jan 28 2025 at 14:54):

mihaly-sisak edited issue #10133:

Hello all!
This is the first Rust project I am touching, so maybe I am completely misunderstanding something. I'm trying to build wasmtime-c-api to use for plugins in my simulation/game.

Following this tutorial: https://docs.wasmtime.dev/examples-minimal.html

The command I build with:
export CARGO_PROFILE_RELEASE_OPT_LEVEL=s
export CARGO_PROFILE_RELEASE_PANIC=abort
export CARGO_PROFILE_RELEASE_LTO=true
export CARGO_PROFILE_RELEASE_CODEGEN_UNITS=1
export CARGO_PROFILE_RELEASE_STRIP=debuginfo

cargo build \
    --package wasmtime-c-api \
    --release \
    --no-default-features \
    --features "disable-logging cranelift cache parallel-compilation wasi"
I plan for my users writing .wasm extensions, and loading them directly. If I understood things correctly I need cranelift to be able to do that. I also enabled parallel-compilation and cache to speed thing up and wasi to have a standard text i/o interface.

I have 2 question:
1) Compiling with this command yields the following conf.h
// WASMTIME_FEATURE_LIST
/* #undef WASMTIME_FEATURE_PROFILING */
/* #undef WASMTIME_FEATURE_WAT */
/* #undef WASMTIME_FEATURE_CACHE */
/* #undef WASMTIME_FEATURE_PARALLEL_COMPILATION */
/* #undef WASMTIME_FEATURE_WASI */
/* #undef WASMTIME_FEATURE_LOGGING */
#define WASMTIME_FEATURE_DISABLE_LOGGING
/* #undef WASMTIME_FEATURE_COREDUMP */
/* #undef WASMTIME_FEATURE_ADDR2LINE */
/* #undef WASMTIME_FEATURE_DEMANGLE */
/* #undef WASMTIME_FEATURE_THREADS */
/* #undef WASMTIME_FEATURE_GC */
/* #undef WASMTIME_FEATURE_GC_DRC */
/* #undef WASMTIME_FEATURE_GC_NULL */
/* #undef WASMTIME_FEATURE_ASYNC */
/* #undef WASMTIME_FEATURE_CRANELIFT */
/* #undef WASMTIME_FEATURE_WINCH */
/* #undef WASMTIME_FEATURE_DEBUG_BUILTINS */
// ... if you add a line above this be sure to change the other locations
// marked WASMTIME_FEATURE_LIST
It seems like in spite of me enabling cache, parallel-compilation, wasi and cranelift it is still not enabled somehow. What am I missing?

2) Can I cherry-pick wasi-proposals I enable? I want my extensions to have text i/o and access to only a specific folder (I found the preopen directory part) but that's it. I do not want them to be able to access the web/open ports. If I enable feature wasi does that enables wasmtime/wasi-http? Can I enable wasi without any network access?
I am confused about the Rust build process. Are there docs on the features? For example what does wmemcheck do? I want my users safe from potentially malicious extensions, do I need it? Same question with memory-protection-keys.

Wasmtime GitHub notifications bot (Jan 28 2025 at 20:39):

alexcrichton commented on issue #10133:

If possible I'd recommend using the cmake-based build for the C API since that's what we test on CI. Otherwise though are you sure you're using the right conf.h? Using the Cargo-based build the conf.h file is squirreled away in the target/* directory so if you've got multiple builds there might be multiple copies. Locally your build command produces the right #defines in conf.h for me.

Can I cherry-pick wasi-proposals I enable? I want my extensions to have text i/o and access to only a specific folder (I found the preopen directory part) but that's it. I do not want them to be able to access the web/open ports. If I enable feature wasi does that enables wasmtime/wasi-http? Can I enable wasi without any network access?

Right now you can't pick-and-choose via the C API. That being said all access to everything is denied by default, so if you don't explicitly allow something then guests won't have access. Furthermore wasi-http and sockets and such are features of WASIp2, or components, which the C API also does not have support for. In that sense your needs should already be met by the C API which only supports WASIp1 and doesn't support networking at all.

I am confused about the Rust build process. Are there docs on the features?

If you're curious about Rust "cargo features" in general you can find documentation here. For wasmtime-specific features you can find documentation either in the online API docs for the Rust wasmtime crate and we also try to document things in Cargo.toml where features are designed as well.

For example what does wmemcheck do?

wmemcheck is a sort of valgrind-for-wasm. There's some very minimal documentation here but the general tl;dr; is you likely don't need it. It's not required for safe execution of code. In general the feature isn't fully complete so it's not recommended for general audiences yet.

I want my users safe from potentially malicious extensions, do I need it?

Wasmtime by default is safe to execute any wasm. You don't need to go out of your way to enable anything to enable safe execution. Access to the host OS is strictly controlled by you, the embedder, and guests have access to nothing you don't give them access to.

The only major things you might need to worry about are resource exhaustion such as consuming too much memory or CPU, Wasmtime doesn't protect against those by default.

Same question with memory-protection-keys.

This is a feature related to Intel's MPK CPU feature. This is only used with the pooling allocator and it's purely a performance optimization. Not needed for safety at all.

Wasmtime GitHub notifications bot (Jan 28 2025 at 21:33):

mihaly-sisak commented on issue #10133:

@alexcrichton you are a godsent both here and my previous issue.

I looked at the root directory toml, but thats for wasmtime-cli, I needed the wasmtime crate in crates/wasmtime. It has great documentation. I was really thrown off by packages having difference between their rust names and directory names. Thank you.

Things get included because default-features = false is missing in a few places (c-api, wasi-io, wasi)

The current config is wasmtime-cranelift = { workspace = true, optional = true, features = ['pulley'] } I set it to wasmtime-cranelift = { workspace = true, optional = true, features = ['host-arch'] } as ~100% of my users are AMD64 windows users.

The current feature set I ended up with is cache parallel-compilation cranelift gc gc-drc disable-logging. Does this sound sane to you? I read the article how contexts are supposed to be ephemeral , one context per server request. In my use case they would be more permanent with internal state, running from simulation start to end. Does this sound feasible?

I read the articles about the fuel based/epoch based approaches to limit CPU usage, really cool stuff.

Wasmtime GitHub notifications bot (Jan 28 2025 at 21:55):

mihaly-sisak edited a comment on issue #10133:

@alexcrichton you are a godsent both here and my previous issue.

I looked at the root directory toml, but thats for wasmtime-cli, I needed the wasmtime crate in crates/wasmtime. It has great documentation. I was really thrown off by packages having difference between their rust names and directory names. Thank you.

Things get included because default-features = false is missing in a few places (c-api, wasi-io, wasi)

The current config is wasmtime-cranelift = { workspace = true, optional = true, features = ['pulley'] } I set it to wasmtime-cranelift = { workspace = true, optional = true, features = ['host-arch'] } as ~100% of my users are AMD64 windows users. Edit: I just realized host-arch is part of the default set.

The current feature set I ended up with is cache parallel-compilation cranelift gc gc-drc disable-logging. Does this sound sane to you? I read the article how contexts are supposed to be ephemeral , one context per server request. In my use case they would be more permanent with internal state, running from simulation start to end. Does this sound feasible?

I read the articles about the fuel based/epoch based approaches to limit CPU usage, really cool stuff.

Wasmtime GitHub notifications bot (Jan 28 2025 at 22:02):

alexcrichton commented on issue #10133:

Ah ok makes sense! For default-features = false I think there might be some hidden rust nuggets perhaps. Most of our dependencies are workspace = true which means they inherit configuration from the root Cargo.toml in the [workspace.dependencies] table. In that table most dependencies should be listed as default-features = false so in theory you shouldn't need to specify it again.

Additionally for the dependency on wasmtime-cranelift you should already support the native host architecture and there's no need to remove the pulley build. That'll shrink the size of Cranelift slightly, however, and if that's important to you mind filing a separate issue for that?

In theory you should be able to use Wasmtime with zero source-level modifications. You're of course welcome to do so, but in terms of normal usage we strive to make it unnecessary so that way you don't have to carry your own patches or anything like that.

The current feature set I ended up with is cache parallel-compilation cranelift gc gc-drc disable-logging. Does this sound sane to you? I read the article how contexts are supposed to be ephemeral , one context per server request. In my use case they would be more permanent with internal state, running from simulation start to end. Does this sound feasible?

Yep that sounds reasonable, and yes a long-running Store<T> should work just fine too.

Wasmtime GitHub notifications bot (Jan 28 2025 at 22:21):

mihaly-sisak closed issue #10133:

Hello all!
This is the first Rust project I am touching, so maybe I am completely misunderstanding something. I'm trying to build wasmtime-c-api to use for plugins in my simulation/game.

Following this tutorial: https://docs.wasmtime.dev/examples-minimal.html

The command I build with:
export CARGO_PROFILE_RELEASE_OPT_LEVEL=s
export CARGO_PROFILE_RELEASE_PANIC=abort
export CARGO_PROFILE_RELEASE_LTO=true
export CARGO_PROFILE_RELEASE_CODEGEN_UNITS=1
export CARGO_PROFILE_RELEASE_STRIP=debuginfo

cargo build \
    --package wasmtime-c-api \
    --release \
    --no-default-features \
    --features "disable-logging cranelift cache parallel-compilation wasi"
I plan for my users writing .wasm extensions, and loading them directly. If I understood things correctly I need cranelift to be able to do that. I also enabled parallel-compilation and cache to speed thing up and wasi to have a standard text i/o interface.

I have 2 question:
1) Compiling with this command yields the following conf.h
// WASMTIME_FEATURE_LIST
/* #undef WASMTIME_FEATURE_PROFILING */
/* #undef WASMTIME_FEATURE_WAT */
/* #undef WASMTIME_FEATURE_CACHE */
/* #undef WASMTIME_FEATURE_PARALLEL_COMPILATION */
/* #undef WASMTIME_FEATURE_WASI */
/* #undef WASMTIME_FEATURE_LOGGING */
#define WASMTIME_FEATURE_DISABLE_LOGGING
/* #undef WASMTIME_FEATURE_COREDUMP */
/* #undef WASMTIME_FEATURE_ADDR2LINE */
/* #undef WASMTIME_FEATURE_DEMANGLE */
/* #undef WASMTIME_FEATURE_THREADS */
/* #undef WASMTIME_FEATURE_GC */
/* #undef WASMTIME_FEATURE_GC_DRC */
/* #undef WASMTIME_FEATURE_GC_NULL */
/* #undef WASMTIME_FEATURE_ASYNC */
/* #undef WASMTIME_FEATURE_CRANELIFT */
/* #undef WASMTIME_FEATURE_WINCH */
/* #undef WASMTIME_FEATURE_DEBUG_BUILTINS */
// ... if you add a line above this be sure to change the other locations
// marked WASMTIME_FEATURE_LIST
It seems like in spite of me enabling cache, parallel-compilation, wasi and cranelift it is still not enabled somehow. What am I missing?

2) Can I cherry-pick wasi-proposals I enable? I want my extensions to have text i/o and access to only a specific folder (I found the preopen directory part) but that's it. I do not want them to be able to access the web/open ports. If I enable feature wasi does that enables wasmtime/wasi-http? Can I enable wasi without any network access?
I am confused about the Rust build process. Are there docs on the features? For example what does wmemcheck do? I want my users safe from potentially malicious extensions, do I need it? Same question with memory-protection-keys.

Wasmtime GitHub notifications bot (Jan 28 2025 at 22:21):

mihaly-sisak commented on issue #10133:

Thank you for the quick answers. Removing pulley shrank the binary size only by 0.9M so I think it is not really important. Me adding the default-features = false was I think me running cargo from a ton of places, not understanding you are supposed to be in the root dir.
I just re-ran everything and it just works. I think what threw me off is me not being in the root dir.
Thank you for the answers!

Wasmtime GitHub notifications bot (Jan 28 2025 at 22:22):

mihaly-sisak edited a comment on issue #10133:

Thank you for the quick answers. Removing pulley shrank the binary size only by 0.9M so I think it is not really important. Me adding the default-features = false was I think me running cargo from a ton of places, not understanding you are supposed to be in the root dir.
I just re-ran everything without modifications and it just works. I think what threw me off is me not being in the root dir.
Thank you for the answers!

Last updated: Feb 28 2025 at 03:10 UTC