SpaceWasm is an implementation of the Wasm 1.0 specification meant to interpret Wasm binary on-board spacecraft. It is developed at NASA JPL.

1. Sequencing: High-level spacecraft activities are typically encoded outside of the embedded flight-software in a command sequence. These activities can include anything from driving the Mars rover and operating its arm, to checking temperature ranges are nominal. Historically, the form and capability of sequences has varied from mission to mission, resulting in assorted/fragmented implementations. SpaceWasm implements an industry standard, providing consolidation.

2. Sandboxing: The cost and time of flight-software development is high due to its constrained requirements and scope. Validating a new flight-software capability often involves validating interactions with the entire system. This extends the V&V timeline and increases competition for testbed resources, which makes it hard to get new autonomy software into flight. WebAssembly gives the opportunity for untrusted or low-trust executables to make their way on-board in a way that flight-software can restrict access and compute time as well as monitor health and safety.

3. Portability: WebAssembly provides well-defined interfaces and sandboxing that make transferring to another platform trivial.

4. Tooling: Standardizing to WebAssembly opens doors into a wide community of rich tooling and research!

This software comes with two major components:

1. Decoder/Validator:

   Reads the Wasm binary in chunks and decodes it to an executable form. The decoder will use a fixed amount of memory and can be measured per-Wasm binary using the spacewasm-check executable on the ground.

   WebAssembly is validated during the decoding process and does not require another pass of the bytecode.

2. Interpreter:

   A Wasm interpreter that can operate on linear memory and interface with hooks from the embedding.

SpaceWasm does not execute direct WebAssembly bytecode. Wasm bytecode is meant to be small and structured in a way to validate easily. These properties however make it slow to execute in-place. During the decoding process of Wasm instructions, SpaceWasm converts bytecode into another intermediate representation (IR) which includes properties better suited for interpretation. Read more about the IR in the specification.

The requirements of SpaceWasm are levied from similar work produced by DLR.

See requirements.

Embedding the interpreter refers to instantiating it and providing implementations for the functions that are imported into the module. Typically, the set of functions imported by the module are fixed and should be specified at compile time both for the Wasm module and the embedder.

SpaceWasm has a unique dynamic memory allocation model. All of its design choices stem from requirements levied by common flight-software standards. Dynamic allocation follows the following rules:

1. All allocations occur over a discrete number of fixed size blocks called pages. These pages are distinct from Wasm's linear memory pages.
2. Deallocation cannot precede allocation.
3. Sub-regions inside pages cannot grow or shrink, sizes should be fixed ahead of time.
4. Memory usage must be deterministic.
5. Any allocation failures must not result in panic.

The standard Rust allocation does not meet these constraints even with custom allocators. To that end, SpaceWasm provides its own data structures that guarantee these properties. You will find these data-structures contain the only usage of unsafe Rust semantics.

Wasm linear memory pages are allocated outside of dynamic memory pages.

Peak memory usage is often an important constraint on small systems found on spacecraft. Many Wasm interpreters require the Wasm binary to be given in one linear blob to the interpreter. This is typically fine for systems where the same regions of memory may be reused for different purposes. Flight software on spacecraft generally assign fixed portions of memory for certain purposes. Therefore, requiring the entire Wasm binary to fit into a single chunk of memory is not feasible.

SpaceWasm is highly optimized to reduce peak memory usage and not require deallocation after allocation required for streaming. To this end, there are certain constraints imposed on the WebAssembly specification.

SpaceWasm supports decoding and compiling Wasm binary in a single pass via a streaming mechanism. Chunks of the Wasm binary may be provided to the interpreter as they are read/requested from the filesystem. The stream must provide chunks synchronously.

The spacewasi crate provides a binary which can run arbitrary WASM modules that adhere to the WASI 0.1 (wasip1) spec in a sandboxed environment. Command line flags are available to mount host directories and environment variables:

# compile example from crates/spacewasi/tests/wasm/
$ clang --target=wasm32-wasip1 -mcpu=mvp hello_universe.c -o hello_universe.wasm

# convert module to MVP compatible file
$ crates/spacewasi/scripts/wasm2mvp.sh hello_universe.wasm

$ spacewasi hello_universe.wasm
hello universe!

For more information about this command and basic WASI compilation, see spacewasi/README.md.

This Wasm interpreter imposes additional constraints beyond the WebAssembly 1.0 specification to support resource-constrained spacecraft environments.

See our IR SPEC for the full list of limitations.

These constraints enable deterministic memory usage and efficient execution in resource-constrained environments while maintaining compatibility with most standard WebAssembly modules.

Because SpaceWasm compiles bytecode into a fixed-width IR that is typically larger than the original bytecode, the practical ceiling on raw module size is bounded by the IR code-page limit above (~8 GiB of IR). This is far larger than any module expected on flight hardware; the binding constraint in practice is the peak memory configured for the streaming decoder, which is measured per-module on the ground with spacewasm-check.

Here are a couple of limitations that may be relevant to developers of Wasm modules.

SpaceWasm is tested against the Coremark benchmark to trace performance regression. See coremark for more information.

cargo test

The unit tests check for regressions on the unsafe container abstractions provided by SpaceWasm due to unique alloc usage. There are also simple unit tests that cover all Wasm instructions without needing full WAST execution.

The integration tests are spectests from the Wasm 1.0 MVP suite which was curated in https://github.com/WasmEdge/wasmedge-spectest. These tests validate the integrity of the Wasm interpreter against the specification.

SpaceWasm includes a comprehensive fuzzing infrastructure using libfuzzer and wasm-smith.

# Run fuzzer
make fuzz

# Analyze crashes with execution traces
make trace CRASH=fuzz/artifacts/no_traps/crash-xxx

Below is a table of the implemented and planned WebAssembly proposals with links to their tracking issue / implementation pull-request.

Currently, all other proposals are not implemented, planned or considered.

Portions of this project are adapted from the open-source projects:

• rust-lang/rust, which is dual-licensed under MIT OR Apache License 2.0.
• DLR-FT/wasm-interpreter, which is licensed under the Apache License 2.0.
• Wasmtime, which is licensed under the Apache License 2.0 with LLVM-exception.
• WABT, which is licensed under the Apache License 2.0.
• wasmedge-spectest, which is licensed under MIT.
• WebAssembly Testsuite, which is licensed under the Apache License 2.0.
• Coremark, which is licensed under the COREMARK ACCEPTABLE USE AGREEMENT.
• Wasm Coremark, which provides no upstream license file; the wrapped CoreMark payload is governed by the COREMARK ACCEPTABLE USE AGREEMENT.