mirror of
https://github.com/fluencelabs/parity-wasm
synced 2025-05-28 15:11:36 +00:00
53d7c8ef3a
Spec: https://github.com/WebAssembly/design/blob/master/BinaryEncoding.md#name-section Issue: https://github.com/paritytech/parity-wasm#129 This is a basic implementation of *.wasm name sections, including serialization and deserialization. As per the discussion with @NikVolf on #129, we implement a custom `IndexMap` type. Before merging this, we should consider the following issues: - [ ] SECURITY: The custom `IndexMap` structure is exposed to a denial of service attack. This can be easily prevented; see below for discussion. - [ ] We probably want top-level `mod.module_name_section()`, `mod.function_name_section()` and `mod.local_name_section()` APIs to make it easy to access the relevant sections. Only one of each section is allowed, so this would make semantic sense. - [ ] We need a real-world *.wasm file with a module and local name sections. - [ ] It looks like name sections will normally be left unparsed. But we should probably go ahead and hook them up to the fuzzer manually. - [ ] We currently require all entries in an `IndexMap` to be in ascending order, as required by the standard. We could relax this check if we needed to handle non-compliant files. Security and `IndexMap`: It's possible to create a local name section containing three entries, for the indices `u32::MAX-2`, `u32::MAX-1` and `u32::MAX`, each of which contains an entry for a local variable with index `u32::MAX`. This will consume an utterly ridiculous amount of RAM. There are three possible fixes, all of which are relatively easy: 1. Switch from `IndexMap<T>` to `BTreeMap<u32, T>`. 2. Keep the index `IndexMap<T>` API, but reimplement it using a private `BTreeMap<u32, T>`. This allows us to replace the implementation later without breaking the API. 3. Keep `IndexMap<T>`, but refuse to deserialize maps containing too many gaps. This would require a slightly different `Deserialize` API, particular to deal with `IndexMap<IndexMap<String>>`.
parity-wasm
Rust WebAssembly format serializing/deserializing
along with experimental interpreter
extern crate parity_wasm;
let module = parity_wasm::deserialize_file("./res/cases/v1/hello.wasm");
assert_eq!(module.code_section().is_some());
let code_section = module.code_section().unwrap(); // Part of the module with functions code
println!("Function count in wasm file: {}", code_section.bodies().len());
Wabt Test suite
Interpreter and decoder supports full wabt testsuite (https://github.com/WebAssembly/testsuite), To run testsuite:
- make sure you have all prerequisites to build
wabt(since parity-wasm builds it internally usingcmake, see https://github.com/WebAssembly/wabt) - checkout with submodules (
git submodule update --init --recursive) - run
cargo test --release --manifest-path=spec/Cargo.toml
Decoder can be fuzzed with cargo-fuzz using wasm-opt (https://github.com/WebAssembly/binaryen):
- make sure you have all prerequisites to build
binaryenandcargo-fuzz(cmakeand a C++11 toolchain) - checkout with submodules (
git submodule update --init --recursive) - install
cargo fuzzsubcommand withcargo install cargo-fuzz - set rustup to use a nightly toolchain, because
cargo fuzzuses a rust compiler plugin:rustup override set nightly - run
cargo fuzz run deserialize
License
parity-wasm is primarily distributed under the terms of both the MIT
license and the Apache License (Version 2.0), at your choice.
See LICENSE-APACHE, and LICENSE-MIT for details.