Kernel Module for running WebAssembly #38
Comments
|
https://github.com/nebulet/nebulet is a kernel using cranelift to run wasm applications as user space. |
|
@bjorn3, nice! The question is: how done is nebulet at the moment? |
|
https://lsneff.me/the-end-of-the-beginning.html I don't know how up to date this is. (cc @lachlansneff) |
|
@bjorn3, seems to be the summary of the Summer of Code. It's good to hear that it got full WebAssembly support, but the limiting factor is actually APIs support, that will allow it to run arbitrary programs. Also, I have just noticed, that nebulet is aiming to be a microkernel if its own, which makes it a no-go for now, even though it might be a solid platform for what I have envisioned in the future. In that case Cervus seems to be a very interesting project and people say it is going to get an update in the next few months, which sounds great, considering it looks pretty dead right now (an interpreter behind executing wasm haven't been updated for nearly a year now). |
|
@skyne98 It's an interesting idea. If your primary goal is performance and reducing system call overhead and you don't need the portability and browser engine compatibility overhead of WebAssembly, another option is to build a runtime using the MinSFI sandboxing technique, described here. That uses a trusted stack and sandboxed address space like WebAssembly does, but with otherwise native code. If you do want the portability properties, then on the WebAssembly side, one of the big challenges right now is to design APIs. We need a common set of APIs to allow WebAssembly engines to be compatible with each other, as there are quite a lot out there. Once we have some platform APIs in place, it'll be interesting then to see how different implementation techniques, including kernel-space implementations, compare. |
|
@sunfishcode, yes, unfortunately portability is in consideration. Also, I may be totally wrong, but isn't it enough for a syscall(...) function to be the only available api for wasm code? In my head, this will allow us to compile different libc's (like musl, glibc) and programs / libraries, that rely on them, as well as syscalls too. However, I am no low-level programming educated person. I think that things like memory mapping can become an issue? |
|
I suppose it depends on how portable you need this to be. Syscalls aren't always portable between operating systems. Designing an abstraction that can be reliably portable between popular operating systems is what I'm referring to as "a common set of APIs" :-). |
|
@sunfishcode, at the moment I am thinking about linux only :D |
|
Lachlan Sneff, the author of nebulet, is currently taking a break from the project, and is uncertain how long he will continue working on WASM. After mentioning WASI in the gitter, he did respond saying that he'd likely adopt WASI should development of nebulet continue, but it might not be in the near future. |
|
@boomshroom, unfortunately, as far as I understand, Nebulet aims to be a fully-fledged microkernel, whereas in this thread I am looking for a rust implementation of a linux kernel module for running WebAssembly on the lowest possible level with the highest possible levels of performance. This kind of module system seems to be implemented by projects like Cervus and WasmJit, however, as I mentioned before, Cervus is the only one written in Rust and as for now seems to be abondoned. However, thank you for your information! |
* Initial checkin.
* Update to rust-lang libc.
* Add a .gitignore file.
* Factor out functions for cleaning up files and directories.
* Fix a typo in a comment.
* Print a "Success!" message if all tests passed.
* Factor out code for creating directories.
* Add wrappers around WASI functions.
These wrappers handle converting from &str to pointer+length and handle
unsafe.
* More refactoring.
* Refactor a fd_close helper.
* Move utility functions into a separate file.
* cargo update
* Add a basic test for random_get.
* Test that directories aren't resizable.
* Test clearing __WASI_RIGHT_PATH_FILESTAT_SET_SIZE.
Ensure that clearing __WASI_RIGHT_PATH_FILESTAT_SET_SIZE succeeds before
testing file truncation.
* cargo update
* Modularise tests for easier use with wasi-common crate
* Add a Code of Conduct and CONTRIBUTING.md.
* Fix typo
* Add testcase for fd_allocate
* Add positive test for fd_renumber
* Assert bufused in readlink_no_buffer testcase
* Add positive readlink testcase
* Add testcase for fd_seek and fd_tell
* Add fd_p{read, write} test
* Add README
* Add cases with trailing slashes to interesting_paths
* Split nofollow_errors testcase into two
* nofollow_errors now operators on symlinks to existing resources
* dangling_symlink covers danling symlinks tests
* Factor out a `create_file` helper function.
* Switch from the error crate to `std::io::Error::last_os_error()`.
* Use `create_file` in the readlink test too.
* Add a test for fd_filestat_set_*
* Minor refactoring
Add missing cleanup_file calls to file_pread_pwrite and
file_seek_tell.
* Add testcase for unbuffered fd_write; fixes #11
* Add testcase for path_rename
* Use the wasi crate.
Switch from depending on libc to depending on the new wasi crate to provide
the low-level WASI interfaces.
See also rust-lang/libc#1461.
* Add a test for path_filestat_*
* Add a test for fd_readdir
* Use expect instead of unwrap
* Add a check for ino.
* Fix the build
* Don't assume a specific order of dirents
* Better test
* Test cookie value
* Fix file types
* Fix the test
* Fix the test
* Fix the test
* Cleanup
* Minor formatting tidying in README.md.
* Fix miscellaneous clippy warnings.
* Rename the crate to wasi-misc-tests.
* Update to wasi 0.7.0.
This switches from using the libc wasi bindings to using the wasi
crate's bindings. This eliminates a git dependency on libc, updates
to the new-style bindings which use Result where possible, and treats
functions that operate on raw file descriptors as unsafe.
* Add various tests for trailing-slash behavior.
* Sync new testcases with latest upstream
* Fix path_filestat testcase
* Add smoke test for fd_advise
This test is a true smoke test as it only tests whether issuing
an advise call to the host's kernel doesn't yield an error. The
consequence of issuing such a syscall is not tested.
* Check if CLOCK_MONOTONIC is actually monotonic
* Refactor the inequality assertions for more debuggable errors.
* Bump libc from 0.2.62 to 0.2.65
Bumps [libc](https://github.com/rust-lang/libc) from 0.2.62 to 0.2.65.
- [Release notes](https://github.com/rust-lang/libc/releases)
- [Commits](rust-lang/libc@0.2.62...0.2.65)
Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
* Fix compilation error
* Enable Actions and add rust.yml (#35)
* Enable Actions and add rust.yml
This commit enables Github Actions and adds corresponding configuration in rust.yml file.
* Update rust.yml
* Fix formatting
* Add empty .rustfmt.toml config file
* Add badge to README
* Update README
* Clean up Github Actions and README
* Add test case for `poll_oneoff` syscall (#38)
* Add test case for `poll_oneoff` syscall
This commit adds a test case for `poll_oneoff` syscall. In particular,
it builds on the excellent test use case provided by @dunnock in their
repo [poll_oneoff_tests] (thanks!), and tests:
* simple timeout
* stdin read with timeout
* fd read and fd write polls
[poll_oneoff_tests]: https://github.com/dunnock/poll_oneoff_tests
* Apply suggestions and negative test for bad fd
Co-authored-by: Maxim Vorobjov <maxim.vorobjov@gmail.com>
* Add smoke test for STDOUT/ERR readwrite poll
* Add comment on stdin/out/err
* Add a test for `*at`-style functions returning `ENOTDIR` when `dirfd` is not a dir.
* Remove misc_testsuite submodule
* Add "publish=false" to Cargo.toml; remove LICENSE
Add more thorough safety documentation to types
|
Should this be kept open or closed? I don't think it is really in scope of wasmtime. |
|
I think we can close this, as I don't think anyone's actively working on this right now. It's an interesting topic, and something Wasmtime may revisit in the future, but we can open a new issue when the time comes. |
* Run nightly only if NIGHTLY_TOOLCHAIN is defined * Minor fixes in docs.
…ed. (bytecodealliance#38) This fixes the crates/test-programs/wasi-tests/src/bin/stdio.rs test in the Wasmtime testsuite.
* usage doc init * fixes
Hello there,
I would like to propose a feature, that, in my opinion, has great potential for making native WebAssembly modules more popular and useful. The idea is executing WebAssembly modules in ring 0, allowing it to communicate via usual function calls, instead of system calls.
WebAssembly standard itself provides a "guarantee", that the given code will be safe to run in the kernel environment, therefore eliminating the need to execute it in "user-space".
How hard will such an implementation will be in your more professional opinion?
On of the projects implementing the idea: WasmJit
The results of using such a method look very promising, boasting execution times smaller than the execution times of native libraries themselves!
The text was updated successfully, but these errors were encountered: