spacewasm

SpaceWasm

SpaceWasm is an implementation of the [Wasm 1.0](https://webassembly.github.io/spec/versions/core/WebAssembly-1.0.pdf) specification meant to interpret Wasm binary on-board spacecraft. It is developed at [NASA JPL](https://www.jpl.nasa.gov). ## Rationale 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! ## Overview This software comes with two major components: 1. Decoder/Validator: Reads the Wasm binary in [chunks](#streaming) 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-check` executable on the ground (not yet developed — see the note under [Limits for Wasm Module Producers](#limits-for-wasm-module-producers)). 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](#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](docs/ir.md). ## Requirements The requirements of SpaceWasm are levied from similar work produced by [DLR](https://github.com/DLR-FT/wasm-interpreter). See [requirements](./docs/REQUIREMENTS.md). 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: 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](https://doc.rust-lang.org/alloc/) 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](#interpreter-limitations) 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`](crates/spacewasi#readme) 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: ```bash # 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`](crates/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](./docs/ir.md#limitations) 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](#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](https://github.com/WebAssembly/custom-page-sizes) 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](crates/spacewasm_std/benches) for more information. ## Testing ### Unit & Integration Tests ```bash 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. ### Fuzzing SpaceWasm includes a comprehensive fuzzing infrastructure using libfuzzer and [wasm-smith](https://github.com/bytecodealliance/wasm-tools/tree/main/crates/wasm-smith). ```bash # 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-xxx ``` ## Feature Support Matrix Below is a table of the implemented and planned WebAssembly proposals with links to their tracking issue / implementation pull-request. | Feature