wasm-smith: generate a Module with specific imports and exports?

[matklad]

I want to generate a wasm module which I can run in a particular environment. That is, I want to specify the set of imports and exports, instead of them being arbitrary.

Context: I want to throw random wasm at the near blockchain, to make sure that our wasm runtime and host functions do not break. I think this should allow me to catch issues a-la wasmerio/wasmer#2329. In that case, an indirect call to an imported function broke things at runtime, and that feels simple enough to be uncovered by a fuzzer.

Is such functionality reasonable/desirable? If it is, I would appreciate mentoring instructions. I think, API-wise, we want to add something like fn imports(&self) -> Option<&[Import]> to the Config trait, but I am not familiar with wasm-tools enough to understand what would be the best definition for such an Import type.

[fitzgen]

Yeah, I think adding something like

/// Return the available set of imports.
///
/// By default, returns `None` which means that any arbitrary import can be generated.
///
/// To only allow imports from a specific set, override this to return a vec of
/// `(module name, field name, entity type)` describing each available import.
fn available_imports(&self) -> Option<Vec<(String, Option<String>, EntityType)>> {
    None
}

to the Config trait would make sense.

This will require:

• making EntityType and everything it contains pub
• tweaking Module::arbitrary_imports so that:
  • we check to see if available_imports returned Some
    • if not, then we continue with the existing method
    • if so, then we pass those available imports to a new arbitrary_imports_from_available_imports method or something. This should use arbitrary_loop and build up a Vec of choice functions in a similar way that arbitrary_imports does, except instead of returning an arbitrary EntityType, it will return the full import name(s) and entity type. Note that you'll want to partition the available imports by type, just like arbitrary_imports does, so that you can satisfy the constraints on the max functions/tables/etc that the config might have. One other thing to make sure to handle is the "type size" limits. You should be able to pretty much copy this snippet into this new method.

Is that enough to get you going?

[matklad]

Yep, definitelly! I assume vec! is a typo?

[fitzgen]

Ah, yes. Fixed with an edit!

[nasgold]

Hi - I'm trying to work through the same change in order to test the WASI syscalls in different runtimes that implement the WASI specification. I'm very new to Rust, however, and so having a few issues creating the arbitrary_imports_from_available_imports method.

Are you implying that choices in the new method should become the following?

let mut choices: Vec<
    fn(&mut Unstructured, &mut ConfiguredModule<C>)
-> Result<(String, EntityType)>

Thanks in advance for any help!