Kernel Module for running WebAssembly

[skyne98]

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!

[bjorn3]

https://github.com/nebulet/nebulet is a kernel using cranelift to run wasm applications as user space.

[skyne98]

@bjorn3, nice! The question is: how done is nebulet at the moment?

[bjorn3]

https://lsneff.me/the-end-of-the-beginning.html I don't know how up to date this is. (cc @lachlansneff)

[skyne98]

@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).

[sunfishcode]

@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.

[skyne98]

@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?

[sunfishcode]

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" :-).

[skyne98]

@sunfishcode, at the moment I am thinking about linux only :D

[boomshroom]

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.

[skyne98]

@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!

[bjorn3]

Should this be kept open or closed? I don't think it is really in scope of wasmtime.

[sunfishcode]

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.