2 releases

Uses old Rust 2015

0.0.2 Mar 6, 2018
0.0.1 Jan 16, 2018

#162 in Emulators

Apache-2.0/MIT

10MB
174K SLoC

WebAssembly 71K SLoC // 0.0% comments C++ 68K SLoC // 0.2% comments Python 20K SLoC // 0.3% comments JavaScript 9K SLoC // 0.1% comments Rust 2.5K SLoC // 0.1% comments Visual Studio Project 2K SLoC C 420 SLoC // 0.0% comments Automake 385 SLoC // 0.2% comments M4 255 SLoC // 0.4% comments Shell 248 SLoC // 0.4% comments Visual Studio Solution 154 SLoC VB6 150 SLoC Xcode Config 33 SLoC // 0.7% comments Forge Config 2 SLoC

Contains (obscure autoconf code, 7KB) configure.ac, (obscure autoconf code, 3KB) configure.ac

nanowasm

A small standalone WebAssembly interpreter in Rust. Currently not really usable, yet.

Goals

This is a hobby project, not intended to be a professional-grade tool. But if it gets to that point, great! I think a small, lightweight interpreter would be really useful for things like embedding, running unit tests on generated wasm code, as an extension system, etc.

The road map is, more or less in order:

  • Implement all of wasm32 1.0 core correctly, passing standard tests and fuzzing
  • Make it easy to run as a standalone interpreter, or embedded in other programs
  • Make it easy to extend with custom modules written in Rust
  • Make it easy to run Rust code built with no_std for the wasm32-unknown-unknown target, and provide a basic console API
  • Make it possible to set hard execution limits on memory and CPU consumed (somehow) and easily sandbox it to forbid access to random resources (like files)
  • Make it reasonably fast?
  • Nice debugging tools?
  • JIT? Either using LLVM, cretonne, or writing my own; I kind of want to write my own for the experience.
  • Load custom modules from DLL's written in Rust or C???

Non-goals

  • Don't intend to run correctly on big-endian platforms, since where byte layout matters to wasm (in memory's) wasm specifies little-endian. Since I kinda want to make it a JIT then it will be platform-specific anyway.
  • Don't intend to never use unsafe; if we can make a significant performance win with unsafe code, we should. Properly-validated WebAssembly code should be safe itself. Naturally, not using unsafe would be best.

Building programs

It's useful to fetch and build wabt, which contains useful low-level tools like an assembler.

sudo apt install clang cmake
git clone --recursive https://github.com/icefoxen/nanowasm
# Or if you've already checked out nanowasm, cd into it and run:
# git submodule update --init --recursive
cd nanowasm/spec/wabt
make -j$(nproc)

The assembler is wat2wasm, so use that.

cd test_programs
wat2wasm inc.wast

This should create a inc.wasm program which is what you can actually load and run:

cargo run -- test_programs/inc.wasm

Safety

This should aim for the goal that if a wasm module is invalid, it will return a Result::Err on trying to load or validate it, or construct a program from it. Then actually executing the code should not need to return a Result because it has already been verified correct; things that are incorrect are bugs in the interpreter or verifier and should result in a panic (should we use assert! or debug_assert! here? Depends on the situation; assert! can sometimes lead to the compiler making smarter code, for example eliding bounds checks after one).

One place where this is not possible to statically verify is if you set resource bounds and the program exceeds them. Need to think about this. There may be other places; the wasm test suite should (hopefully) cover these.

Similar projects

Licence

Apache/MIT

Dependencies

~21MB
~368K SLoC