SpaceWasm
SpaceWasm is an implementation of the Wasm 1.0 specification meant to interpret Wasm binary on-board spacecraft. It is developed at NASA JPL.
Rationale
-
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.
-
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.
-
Portability: WebAssembly provides well-defined interfaces and sandboxing that make transferring to another platform trivial.
-
Tooling: Standardizing to WebAssembly opens doors into a wide community of rich tooling and research!
Overview
This software comes with two major components:
-
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 is intended to be measured per-Wasm binary using the
spacewasm-checkexecutable on the ground (not yet developed — see the note under Limits for Wasm Module Producers).WebAssembly is validated during the decoding process and does not require another pass of the bytecode.
-
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.
Requirements
The requirements of SpaceWasm are levied from similar work produced by DLR.
See requirements.
SpaceWasm uses the Rust 2024 edition; the minimum supported Rust version is 1.87 (matching rust-version in
Cargo.toml). Older toolchains fail to build with an edition2024 error.
Embedding
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.
Dynamic Allocation
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:
- All allocations occur over a discrete number of fixed size blocks called pages. These pages are distinct from Wasm's linear memory pages.
- Deallocation cannot precede allocation.
- Sub-regions inside pages cannot grow or shrink, sizes should be fixed ahead of time.
- Memory usage must be deterministic.
- 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. These
data-structures contain the bulk of the unsafe Rust semantics; the remainder lives in the performance-critical
operand-stack, linear-memory, and IR access paths (src/stack.rs, src/memory.rs, src/ir_reader.rs), the
ValType conversion in src/types.rs, and the FFI layer (crates/spacewasm_c_api, crates/spacewasi). Bounds on
those raw accesses are established by the up-front verifier; the optional strict-assertions feature re-checks them
at runtime.
Note
These limitations are only enforced on the implementation of the interpreter and not on the Wasm bytecode it is made to interpret.
Wasm linear memory pages are allocated outside of dynamic memory pages.
Streaming
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.
WASI 0.1 Support
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.
Interpreter Limitations
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.
Limits for Wasm Module Producers
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 in the table below (~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.
Note
spacewasm-check has not been developed yet. A similar tool can be found in spacewasm_std.
Here are a couple of limitations that may be relevant to developers of Wasm modules.
| Limit | Value | Notes |
|---|---|---|
| Wasm page size | 64 KiB / 1 B | Custom-Page-Sizes proposal is supported |
| Linear memory pages | 4 GiB | Per the Wasm 1.0 spec. A module declaring more (or a max above this) is rejected. Note that the embedding will definitely limit this but it is dependent on how the interpreter is deployed. |
| IR Code | 8 GiB | Compiled IR, not raw bytecode. This limit is across all modules in the store. The IR / Bytecode ratio is printed in spacewasm_std as the "compilation ratio". It is difficult to estimate this upfront because it varies on the types of instructions used. |
| Function parameters | 255 32-bit words | Per function. |
| Local variables | 65,535 32-bit words | Per function. |
| Import name length | 32 bytes | Applies to each import's module name and field name; a longer name is rejected at decode time. |
| Custom section name | 32 bytes | The name of each custom section (e.g. the name section); a longer name is rejected at decode time. |
Benchmarking
SpaceWasm is tested against the Coremark benchmark to trace performance regression. See coremark for more information.
Testing
Unit & Integration Tests
cargo testThe 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.
Fuzzing
SpaceWasm includes a comprehensive fuzzing infrastructure using libfuzzer and wasm-smith.
# Run fuzzer
make fuzz
# Differentially test the validator against wasmi (SpaceWasm vs a reference)
make fuzz-validate-differential
# Analyze crashes with execution traces
make trace CRASH=fuzz/artifacts/no_traps/crash-xxxFeature Support Matrix
Below is a table of the implemented and planned WebAssembly proposals with links to their tracking issue / implementation pull-request.
| Feature | Status |
|---|---|
| Wasm MVP | All Versions |
| Mutable globals | All Versions |
| Custom page sizes | ≥0.2.0 |
| Bulk memory operations | Planned |
| Sign-extension operators | Planned |
| Non-trapping float-to-int conversions | Planned |
| SIMD | Planned |
| Multi-value | Under Consideration |
| Multiple memories | Under Consideration |
Currently, all other proposals are not implemented, planned or considered.
Credits & Acknowledgments
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.
