Bring back Module::deserialize (#2858)
* Bring back `Module::deserialize` I thought I was being clever suggesting that `Module::deserialize` was removed from #2791 by funneling all module constructors into `Module::new`. As our studious fuzzers have found, though, this means that `Module::new` is not safe currently to pass arbitrary user-defined input into. Now one might pretty reasonable expect to be able to do that, however, being a WebAssembly engine and all. This PR as a result separates the `deserialize` part of `Module::new` back into `Module::deserialize`. This means that binary blobs created with `Module::serialize` and `Engine::precompile_module` will need to be passed to `Module::deserialize` to "rehydrate" them back into a `Module`. This restores the property that it should be safe to pass arbitrary input to `Module::new` since it's always expected to be a wasm module. This also means that fuzzing will no longer attempt to fuzz `Module::deserialize` which isn't something we want to do anyway. * Fix an example * Mark `Module::deserialize` as `unsafe`
This commit is contained in:
@@ -126,7 +126,8 @@ mod test {
|
||||
command.execute()?;
|
||||
|
||||
let engine = Engine::default();
|
||||
let module = Module::from_file(&engine, output_path)?;
|
||||
let contents = std::fs::read(output_path)?;
|
||||
let module = unsafe { Module::deserialize(&engine, contents)? };
|
||||
let store = Store::new(&engine);
|
||||
let instance = Instance::new(&store, &module, &[])?;
|
||||
let f = instance.get_typed_func::<i32, i32>("f")?;
|
||||
|
||||
Reference in New Issue
Block a user