feat: when deserialization of module from filesystem cache fails, remove from cache #138
Conversation
…rialized modules to filesystem into ModuleCache
| /// Wasmer failed to serialize a Module to bytes. | ||
| ModuleSerialize(String), | ||
| /// Wasmer failed to deserialize a Module from bytes. | ||
| ModuleDeserialize(String), |
There was a problem hiding this comment.
Additional error types for clarity
crates/host/src/module.rs
Outdated
| unsafe { Module::deserialize(&self.runtime_engine, serialized_module.clone()) }; | ||
|
|
||
| // If deserialization fails, we assume the file is corrupt, | ||
| // so it is removed from the filesystem cache. |
There was a problem hiding this comment.
Will a module that deserializes always run? With a binary, there are interlinked references and it should break if you chop off the end. Is that true with these WASM binaries?
There was a problem hiding this comment.
Looking into it briefly it looks like a wasm binary is made up of pre-defined "sections". Each section starts with an identifier for the section, and then the size of the contents of that section. The wasm is validated before it is executed, so it would catch that a section is not its expected size and fail to run.
It looks there is validation of the "artifact layout" during deserialization in wasmer -- its not clear to me exactly what this is doing though, or if further validation occurs before execution.
There was a problem hiding this comment.
I see that wasmer exposes a "validate" function on Module -- maybe worth digging in a bit deeper to make sure we are validating wasms if necessary: https://docs.rs/wasmer/latest/wasmer/struct.Module.html#method.validate
Co-authored-by: ThetaSinner <[email protected]>
Co-authored-by: ThetaSinner <[email protected]>
Co-authored-by: Jost <[email protected]>
… both caches after filesystem deserialization failure
Resolves #137
Merging into
feat/rm-serialized-module-cachefor a clean diff.I'm not sure if this is the right approach, so let me know if you think differently.