-
Notifications
You must be signed in to change notification settings - Fork 377
WASIp2 component support for wasmtime #1877
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Reviewer's GuideRefactor the wasmtime handler to dynamically load Wasmtime C API symbols, abstract VM initialization, detect WebAssembly encoding, and route execution to either a module or WASIp2 component runner. File-Level Changes
Assessment against linked issues
Possibly linked issues
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
|
So I wanted to implement the Is this by choice or a bug? |
|
@flouthoc PTAL |
giuseppe
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
some nits, also could you use wasmtime: $DESCRIPTION for your commits instead of [wasmtime], otherwise LGTM
Signed-off-by: Maximilian Hüter <[email protected]>
Signed-off-by: Maximilian Hüter <[email protected]>
Signed-off-by: Maximilian Hüter <[email protected]>
0074108 to
ce8441d
Compare
|
Thanks for taking a look, hope I didn't oversee anything! The only thing keeping this PR as a draft is that I would like to give both WASM modules and components the ability to read & write to the working directory. But the previous implementation did not allow this. Are there any security concerns or can this feature simply be added? |
|
|
||
| wasm_byte_vec_t wasm; | ||
| // Load and parse container entrypoint | ||
| FILE *file = fopen (pathname, "rbe"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is e in rbe here ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This part of the code was just copied. The e seems to be a glibc extension which sets the O_CLOEXEC flag on the descriptor. This flag causes the fd to be automatically closed upon calling one of the exec functions.
A few lines later the fd is actually closed by hand and none the exec functions are visibly being called. As e is not standards compliant maybe it should be removed?
Sources: fopen(3) and open(2) man pages
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As e is not standards compliant maybe it should be removed?
Yes if it's not necessary I think we should remove it, wdyt @giuseppe
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some extra info: Closing the fd manually later does not prevent all issues O_CLOEXEC tries to solve. The glibc man page states that it is a glibc extension so I figured it would not be standards compliant but musl and FreeBSDs libc actually also implement the e in fopen.
Sources: musl and FreeBSDs libc
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can remove it if it is not required, I see similar comment later from review bot #1877 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After reading other parts of the code for quite some time, I think it is safe to say e is not required. This is also encouraged by the fact that right before the fopen we are always in a single threaded context thus the mentioned leak in open(2) is not possible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just found this commit 0f0d5be which adds e to a lot of fopen calls. Also in wasmtime.
Even though I said removing the flag should be fine I am not 100% sure. Thus I would like to add the e flag back
| FROM scratch | ||
| COPY hello.wasm / | ||
| CMD ["/hello.wasm"] | ||
| ENTRYPOINT ["/hello.wasm"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you write it in commit message or here, about why is this change needed ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, sorry forgot to mention it ...
After adding the pass through of argv to the component I wanted to try it out. Upon running podman run mywasm-image:latest arg1 arg2 podman would replace CMD (the wasm binary) with arg1 which of course does not work. Changing to ENTRYPOINT resolves this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks like a breaking change. I think adding this message to commit logs can help us revisit this and fix this if needed.
cc @giuseppe
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Adding this to the commit logs should be possible but I don't really see where this is a breaking change? Without the changes of this PR a wasm module runs into the same problem. IIRC this is also the same behavior a non-wasm container would show.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the message in ce7d656 OK?
…sm-wasi-example In docs/wasm-wasi-example.md the Containerfile had the WebAssembly binary in the `CMD` instruction. But running the container via podman like so `podman run mywasm-image:latest arg1 arg2` does not work as podman instructs crun to run `arg1 arg2` instead of `hello.wasm arg1 arg2` resulting in the error `arg1: command not found`. Using `ENTRYPOINT` in the Containerfile makes the previously mentioned podman command work. Signed-off-by: Maximilian Hüter <[email protected]>
Signed-off-by: Maximilian Hüter <[email protected]>
Signed-off-by: Maximilian Hüter <[email protected]>
Signed-off-by: Maximilian Hüter <[email protected]>
31fd57e to
9a073f6
Compare
Signed-off-by: Maximilian Hüter <[email protected]>
Signed-off-by: Maximilian Hüter <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey there - I've reviewed your changes - here's some feedback:
- Consider extracting the repeated dlsym() lookups into a helper utility that takes an array of symbol names and returns function pointers, reducing duplicate code.
- Relying on matching the literal error string “component passed to module validation” for component detection is brittle; consider using a dedicated component detection API or inspecting the Wasm magic/header instead.
- When a symbol lookup fails, include the specific missing symbol name in the error output to make debugging dynamic loading issues easier.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- Consider extracting the repeated dlsym() lookups into a helper utility that takes an array of symbol names and returns function pointers, reducing duplicate code.
- Relying on matching the literal error string “component passed to module validation” for component detection is brittle; consider using a dedicated component detection API or inspecting the Wasm magic/header instead.
- When a symbol lookup fails, include the specific missing symbol name in the error output to make debugging dynamic loading issues easier.
## Individual Comments
### Comment 1
<location> `src/libcrun/handlers/wasmtime.c:91` </location>
<code_context>
+
+ wasm_byte_vec_t wasm;
+ // Load and parse container entrypoint
+ FILE *file = fopen (pathname, "rbe");
+ if (! file)
+ error (EXIT_FAILURE, 0, "error loading entrypoint");
</code_context>
<issue_to_address>
**issue:** The use of 'rbe' as the fopen mode is non-standard and may cause portability issues.
Use 'rb' for reading binary files unless 'rbe' is required and confirmed to be supported across all target platforms.
</issue_to_address>
### Comment 2
<location> `src/libcrun/handlers/wasmtime.c:107` </location>
<code_context>
+ // If entrypoint contains a webassembly text format
+ // compile it on the fly and convert to equivalent
+ // binary format.
+ if (has_suffix (pathname, "wat") > 0)
+ {
+ wasmtime_error_t *err = wasmtime_wat2wasm ((char *) wasm.data, file_size, &wasm_bytes);
</code_context>
<issue_to_address>
**suggestion (bug_risk):** Suffix check for 'wat' may match unintended filenames.
This check may incorrectly match filenames like 'mywat' or 'format'. Use '.wat' as the suffix to ensure only intended files are processed.
```suggestion
if (has_suffix (pathname, ".wat") > 0)
```
</issue_to_address>
### Comment 3
<location> `src/libcrun/handlers/wasmtime.c:129` </location>
<code_context>
+ wasmtime_error_message (err, &error_message);
+ wasmtime_error_delete (err);
+
+ if (strcmp ((char *) error_message.data, "component passed to module validation") != 0)
+ error (EXIT_FAILURE, 0, "failed to validate module: %.*s", (int) error_message.size, error_message.data);
+
</code_context>
<issue_to_address>
**suggestion (bug_risk):** String comparison for error message is brittle and may break with upstream changes.
Consider using an error code or a more stable identifier instead of matching the error message string, to avoid breakage from upstream changes.
Suggested implementation:
```c
wasmtime_error_message (err, &error_message);
// Use a more robust check for the error type.
// If wasmtime_error_as_exit_status is available, use it.
int exit_status = 0;
bool is_component_error = false;
#ifdef WASMTIME_HAS_ERROR_EXIT_STATUS
if (wasmtime_error_as_exit_status(err, &exit_status)) {
// Check for a specific exit status if known for component error.
if (exit_status == WASMTIME_COMPONENT_VALIDATION_ERROR_CODE) {
is_component_error = true;
}
}
#endif
// Fallback: check for substring in error message.
if (!is_component_error) {
if (memmem(error_message.data, error_message.size, "component passed to module validation", strlen("component passed to module validation")) == NULL)
error (EXIT_FAILURE, 0, "failed to validate module: %.*s", (int) error_message.size, error_message.data);
}
wasmtime_error_delete (err);
```
- You may need to define `WASMTIME_HAS_ERROR_EXIT_STATUS` and `WASMTIME_COMPONENT_VALIDATION_ERROR_CODE` if the wasmtime API provides such error codes. If not, you can remove the conditional and rely on the substring check.
- If you have a helper function for error type checking, use that instead of the inline logic.
- Make sure to include the necessary headers for `memmem` if not already present.
</issue_to_address>
### Comment 4
<location> `src/libcrun/handlers/wasmtime.c:278` </location>
<code_context>
wasi_config_inherit_stdout (wasi_config);
wasi_config_inherit_stderr (wasi_config);
- wasi_config_preopen_dir (wasi_config, ".", ".");
+ wasi_config_preopen_dir (
+ wasi_config,
+ ".",
</code_context>
<issue_to_address>
**🚨 suggestion (security):** Hardcoded permissions for preopened directory may be overly permissive.
Evaluate if both read and write permissions are required, or if access can be restricted to enhance security.
Suggested implementation:
```c
WASMTIME_WASI_DIR_PERMS_READ,
WASMTIME_WASI_FILE_PERMS_READ);
```
If your application requires write access, you can revert to the original permissions. Otherwise, this change will restrict access to read-only, improving security.
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
Signed-off-by: Maximilian Hüter <[email protected]>
Signed-off-by: Maximilian Hüter <[email protected]>
Signed-off-by: Maximilian Hüter <[email protected]>
Signed-off-by: Maximilian Hüter <[email protected]>
|
I marked the PR as a draft again because I don't want to trigger CI all the time. There is also a bigger change in the works which cleans up all of the Edit: Seems like CI still get triggered ... and it's now just one macro. |
4ddd82a to
9b541ea
Compare
Signed-off-by: Maximilian Hüter <[email protected]>
Signed-off-by: Maximilian Hüter <[email protected]>
Signed-off-by: Maximilian Hüter <[email protected]>
d2f793b to
0f89f34
Compare
|
@t4chib4ne the tests are not happy. @giuseppe is that expected? |
I saw that but they failed because of a failed provisioning of the test environment due to an outage. |
|
@flouthoc PTAL |
flouthoc
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
|
@t4chib4ne I think some functions need change, how did you build My build failed with src/libcrun/handlers/wasmtime.c: In function 'libwasmtime_run_component':
src/libcrun/handlers/wasmtime.c:327:3: error: unknown type name 'wasmtime_wasip2_config_t'
327 | wasmtime_wasip2_config_t *(*wasmtime_wasip2_config_new) (void)
| ^~~~~~~~~~~~~~~~~~~~~~~~
src/libcrun/handlers/wasmtime.c:329:49: error: unknown type name 'wasmtime_wasip2_config_t'
329 | void (*wasmtime_wasip2_config_inherit_stdin) (wasmtime_wasip2_config_t *config)
| ^~~~~~~~~~~~~~~~~~~~~~~~
src/libcrun/handlers/wasmtime.c:331:50: error: unknown type name 'wasmtime_wasip2_config_t'
331 | void (*wasmtime_wasip2_config_inherit_stdout) (wasmtime_wasip2_config_t *config)
| ^~~~~~~~~~~~~~~~~~~~~~~~
src/libcrun/handlers/wasmtime.c:333:50: error: unknown type name 'wasmtime_wasip2_config_t'
333 | void (*wasmtime_wasip2_config_inherit_stderr) (wasmtime_wasip2_config_t *config)
| ^~~~~~~~~~~~~~~~~~~~~~~~
src/libcrun/handlers/wasmtime.c:335:39: error: unknown type name 'wasmtime_wasip2_config_t'
335 | void (*wasmtime_wasip2_config_arg) (wasmtime_wasip2_config_t *config, const char *arg, size_t arg_len)
| ^~~~~~~~~~~~~~~~~~~~~~~~
src/libcrun/handlers/wasmtime.c:337:69: error: unknown type name 'wasmtime_wasip2_config_t'
337 | *wasmtime_context_set_wasip2) (wasmtime_context_t *context, wasmtime_wasip2_config_t *config)
| ^~~~~~~~~~~~~~~~~~~~~~~~
src/libcrun/handlers/wasmtime.c:397:3: error: unknown type name 'wasmtime_wasip2_config_t'
397 | wasmtime_wasip2_config_t *wasi_config = wasmtime_wasip2_config_new ();
| ^~~~~~~~~~~~~~~~~~~~~~~~
src/libcrun/handlers/wasmtime.c:402:3: error: implicit declaration of function 'wasmtime_wasip2_config_inherit_stdin'; did you mean 'wasmtime_wasip2_config_new'? [-Wimplicit-function-declaration]
402 | wasmtime_wasip2_config_inherit_stdin (wasi_config);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| wasmtime_wasip2_config_new
src/libcrun/handlers/wasmtime.c:403:3: error: implicit declaration of function 'wasmtime_wasip2_config_inherit_stdout'; did you mean 'wasi_config_inherit_stdout'? [-Wimplicit-function-declaration]
403 | wasmtime_wasip2_config_inherit_stdout (wasi_config);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| wasi_config_inherit_stdout
src/libcrun/handlers/wasmtime.c:404:3: error: implicit declaration of function 'wasmtime_wasip2_config_inherit_stderr'; did you mean 'wasi_config_inherit_stderr'? [-Wimplicit-function-declaration]
404 | wasmtime_wasip2_config_inherit_stderr (wasi_config);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| wasi_config_inherit_stderr
src/libcrun/handlers/wasmtime.c:413:5: error: implicit declaration of function 'wasmtime_wasip2_config_arg'; did you mean 'wasmtime_wasip2_config_new'? [-Wimplicit-function-declaration]
413 | wasmtime_wasip2_config_arg (wasi_config, *arg, strlen (*arg));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
| wasmtime_wasip2_config_new
src/libcrun/handlers/wasmtime.c:415:3: error: implicit declaration of function 'wasmtime_context_set_wasip2'; did you mean 'wasmtime_context_set_wasi'? [-Wimplicit-function-declaration]
415 | wasmtime_context_set_wasip2 (context, wasi_config);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
| wasmtime_context_set_wasi
make[2]: *** [Makefile:2030: src/libcrun/handlers/libcrun_la-wasmtime.lo] Error 1
make[2]: Leaving directory '/home/ar/work/crun'
make[1]: *** [Makefile:2806: all-recursive] Error 1
make[1]: Leaving directory '/home/ar/work/crun'
make: *** [Makefile:1130: all] Error 2 |
|
I wrote an ebuild (Gentoo) and installed it that way. It just downloads a release from the repo you linked, configures
My libwasmtime install looks like this:Edit: Then build crun with: I had to install |
|
Sorry for spamming but I think I found the issue: wasmtime 37 and 38 still ship I will add changes to this PR to use the now more "unified" c-api. If I understand the linked commit message correctly then wasip2 interoperability with Thanks @flouthoc for testing the build! |
Signed-off-by: Maximilian Hüter <[email protected]>
Sure please tag, when you update the PR. |
Signed-off-by: Maximilian Hüter <[email protected]>
Signed-off-by: Maximilian Hüter <[email protected]>
c275139 to
13377c7
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey there - I've reviewed your changes and they look great!
Prompt for AI Agents
Please address the comments from this code review:
## Individual Comments
### Comment 1
<location> `src/libcrun/handlers/wasmtime.c:77` </location>
<code_context>
- || wasmtime_wat2wasm == NULL)
- error (EXIT_FAILURE, 0, "could not find symbol in `libwasmtime.so`");
+
+ if (vm == NULL)
+ vm = malloc (sizeof (struct libwasmtime_vm));
+
</code_context>
<issue_to_address>
**issue (bug_risk):** Potential memory leak if malloc fails in libwasmtime_setup_vm.
Explicitly check if malloc returns NULL and handle the error to prevent undefined behavior from dereferencing vm.
</issue_to_address>
### Comment 2
<location> `src/libcrun/handlers/wasmtime.c:251-252` </location>
<code_context>
+static void *
+libwasmtime_load_symbol (void *cookie, char *const symbol)
+{
+ void *sym = dlsym (cookie, symbol);
+ if (sym == NULL)
+ error (EXIT_FAILURE, 0, "could not find symbol in `libwasmtime.so`: %.*s", (int) strlen (symbol), symbol);
</code_context>
<issue_to_address>
**suggestion:** Error message in libwasmtime_load_symbol may print garbage for symbol name.
Since symbol is expected to be null-terminated, using %s would simplify the error message and avoid issues with non-printable or unexpected characters.
```suggestion
if (sym == NULL)
error (EXIT_FAILURE, 0, "could not find symbol in `libwasmtime.so`: %s", symbol);
```
</issue_to_address>
### Comment 3
<location> `src/libcrun/handlers/wasmtime.c:216` </location>
<code_context>
// compile it on the fly and convert to equivalent
// binary format.
- if (has_suffix (pathname, "wat") > 0)
+ if (has_suffix (pathname, ".wat") > 0)
{
- wasmtime_error_t *err = wasmtime_wat2wasm ((char *) &wasm_bytes, file_size, &wasm);
</code_context>
<issue_to_address>
**suggestion (bug_risk):** Suffix check for .wat may miss uppercase or mixed-case extensions.
The current check will not recognize files with uppercase or mixed-case ".wat" extensions. Use a case-insensitive comparison to ensure all valid WAT files are detected.
</issue_to_address>
### Comment 4
<location> `src/libcrun/handlers/wasmtime.c:203-206` </location>
<code_context>
+ if (fseek (file, 0L, SEEK_END))
+ error (EXIT_FAILURE, 0, "error fully loading entrypoint");
size_t file_size = ftell (file);
+ if (file_size == (size_t) -1L)
+ error (EXIT_FAILURE, 0, "error getting entrypoint size");
wasm_byte_vec_new_uninitialized (&wasm, file_size);
</code_context>
<issue_to_address>
**suggestion:** Casting -1L to size_t may be confusing and non-portable.
Comparing ftell(file) directly to -1 improves clarity and avoids potential portability issues with casting.
```suggestion
long file_size = ftell (file);
if (file_size == -1)
error (EXIT_FAILURE, 0, "error getting entrypoint size");
wasm_byte_vec_new_uninitialized (&wasm, (size_t)file_size);
```
</issue_to_address>
### Comment 5
<location> `src/libcrun/handlers/wasmtime.c:243` </location>
<code_context>
+ else
+ error (EXIT_FAILURE, 0, "unsupported wasm encoding detected");
+
+ libwasmtime_free_vm (cookie, &vm);
+ exit (status);
+}
</code_context>
<issue_to_address>
**issue (bug_risk):** libwasmtime_free_vm does not free vm struct if allocated inside libwasmtime_setup_vm.
To prevent memory leaks, ensure libwasmtime_free_vm also frees the vm struct if it was allocated with malloc in libwasmtime_setup_vm.
</issue_to_address>
### Comment 6
<location> `src/libcrun/handlers/wasmtime.c:57` </location>
<code_context>
+ void (*wasmtime_error_delete) (wasmtime_error_t * error) \
+ = libwasmtime_load_symbol ((cookie), "wasmtime_error_delete");
+
+static void *
+libwasmtime_load_symbol (void *cookie, char *const symbol);
+
</code_context>
<issue_to_address>
**issue (complexity):** Consider building a single API table of Wasmtime symbols at load time and passing it via the cookie to simplify symbol access and reduce repetitive dlsym calls.
Here’s one way to dramatically cut down all the repeated `dlsym(…, …)` calls and make the call‐sites much easier to read. The idea is:
1. On load, build a single “API table” (struct) that holds *all* the Wasmtime symbols you need.
2. Store that in your `cookie` (instead of the raw `dlopen` handle).
3. Everywhere else, just do `api->wasm_engine_new()` etc.
That way you only ever do each `dlsym()` once, and the rest of your code becomes a one‐liner instead of a multi‐line load.
Example:
```c
/* add near top of file */
struct libwasmtime_api {
void *dlh;
wasm_engine_t *(*wasm_engine_new)(void);
void (*wasm_engine_delete)(wasm_engine_t *);
wasmtime_store_t *(*wasmtime_store_new)(wasm_engine_t*, void*, void(*)(void*));
/* … all the rest of your symbols … */
};
static int libwasmtime_load(void **cookie, libcrun_error_t *err) {
struct libwasmtime_api *api = malloc(sizeof(*api));
if (!api) return crun_make_error(err, ENOMEM, "alloc api");
api->dlh = dlopen("libwasmtime.so", RTLD_NOW);
if (!api->dlh)
return crun_make_error(err, 0, "dlopen: %s", dlerror());
#define LOAD(sym) \
do { api->sym = dlsym(api->dlh, #sym); \
if (!api->sym) \
error(EXIT_FAILURE, 0, "symbol %s missing in libwasmtime", #sym); \
} while(0)
LOAD(wasm_engine_new);
LOAD(wasm_engine_delete);
LOAD(wasmtime_store_new);
/* … load the rest here … */
#undef LOAD
*cookie = api;
return 0;
}
```
Then in your helpers you just grab the table:
```c
static struct libwasmtime_vm *
libwasmtime_setup_vm(void *cookie, char *const argv[], struct libwasmtime_vm *vm)
{
struct libwasmtime_api *api = cookie;
vm->engine = api->wasm_engine_new();
if (!vm->engine)
error(EXIT_FAILURE, 0, "could not create engine");
vm->store = api->wasmtime_store_new(vm->engine, NULL, NULL);
if (!vm->store)
error(EXIT_FAILURE, 0, "could not create store");
vm->context = api->wasmtime_store_context(vm->store);
/* … etc … */
return vm;
}
static void
libwasmtime_free_vm(void *cookie, struct libwasmtime_vm *vm)
{
struct libwasmtime_api *api = cookie;
api->wasmtime_store_delete(vm->store);
api->wasm_engine_delete(vm->engine);
}
```
And similarly in `libwasmtime_run_module()` / `run_component()` you replace each `libwasmtime_load_symbol(cookie, "...")` with `api->that_symbol(...)`. This removes *hundreds* of repetitive loader calls, centralizes error‐checking, and makes the “real” logic in each helper much shorter.
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
|
Should be good to review now, @flouthoc I tested against wasmtime 37 and the |
Signed-off-by: Maximilian Hüter <[email protected]>
- rm `malloc` from libwasmtime_setup_vm - check entrypoint extension case insensitive - keep `ftell` return value as `long` Signed-off-by: Maximilian Hüter <[email protected]>
c88c048 to
09197e0
Compare
@t4chib4ne The binary builds fine but when I am testing a simple "hello world" example it fails with I tried example from docs which you have updated. Could you share a small test how you are testing it ? |
I basically use a subset of the docs.
rust code: use std::{
env,
fs::File,
io::{self, Write},
process::exit,
};
fn main() -> std::io::Result<()> {
println!("Hello, world from wasm!");
for arg in env::args() {
println!("Got arg: {}", &arg);
}
for (envkey, envvar) in env::vars() {
println!("Got env: {} = {}", &envkey, &envvar);
}
eprintln!("Will try to create a file in ./ ...");
let mut file = File::create("./hello.txt")?;
file.write_all(b"Hello, world form wasm!")?;
//let exit_code = 0;
//eprintln!("Will now exit with {}", exit_code);
//exit(exit_code);
//Err(io::Error::new(io::ErrorKind::Other, "Oh noes!"))
Ok(())
}The test with wasmtime 37 is done normally and rootless. Against wasmtime 39 I build it in a privileged container and run the I investigated with Will setup a VM with an LSM installed and try reproducing the error. |
|
Sadly I cannot reproduce the issue.
@flouthoc could you please take a look with For me running Running a |
I will look into this today, thanks for sharing your example. |
Adds WASIp2 component support for wasmtime by checking whether the given WebAssembly is a module or a component and then calling the appropriate functions.
The calls are nothing fancy just a very basic setup giving the WebAssembly component full access to the WASIp2 implementation of wasmtime.
Closes #1871
Still a Draft because of:
wasi_config_preopen_dir⇒ calling this function for a WASIp2 config also workswasi:cli/[email protected]#runshould be fine as wasmtime will call the highest version available (e.g.wasi:cli/[email protected]#run)Summary by Sourcery
Enable WASIp2 component support in wasmtime by detecting if the input is a module or component and invoking the appropriate execution path with dynamically loaded Wasmtime APIs and WASIp2 configuration
New Features:
Enhancements:
Documentation:
Summary by Sourcery
Enable WASIp2 component support in the Wasmtime handler by detecting whether the input is a module or component, dynamically loading required Wasmtime API symbols, and dispatching to separate execution paths with appropriate WASI/WASIp2 configuration.
New Features:
Enhancements:
Documentation: