You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently it's relatively easy to get the validator (and wasm-smith which actually generates modules like this) to go down a rabbit hole in terms of performance. To do this you can create a hugely-nested module type with expands to lots of recursive checks of subtypes:
Today that module takes quite a long time in validation (30s!).
I'm not entirely sure how to prevent this just yet, but we shouldn't in any case have modules take 30s in validation when they're so small. Whatever fix is applied here needs to be extended to wasm-smith since sometimes generating modules takes 30+ seconds since it's doing subtyping checks internally.
The text was updated successfully, but these errors were encountered:
This commit implements a fix for bytecodealliance#214 where the effective size of the
type of any item in a module (or a module itself) is now required to be
bounded. The goal here is to accept reasonable modules but at the same
time protecting implementations like wasmtime from having to worry about
deeply recursive and nested module types. The general fix here is to
account for the size of all types as we parse them, and at all times the
size is bounded.
Additionally wasm-smith is updated with similar accounting for the size
of types and such to prevent generating modules with massively recursive
types.
Closesbytecodealliance#214
* Validate the effective type size of modules
This commit implements a fix for #214 where the effective size of the
type of any item in a module (or a module itself) is now required to be
bounded. The goal here is to accept reasonable modules but at the same
time protecting implementations like wasmtime from having to worry about
deeply recursive and nested module types. The general fix here is to
account for the size of all types as we parse them, and at all times the
size is bounded.
Additionally wasm-smith is updated with similar accounting for the size
of types and such to prevent generating modules with massively recursive
types.
Closes#214
* Clarify doc comments
Currently it's relatively easy to get the validator (and wasm-smith which actually generates modules like this) to go down a rabbit hole in terms of performance. To do this you can create a hugely-nested module type with expands to lots of recursive checks of subtypes:
Today that module takes quite a long time in validation (30s!).
I'm not entirely sure how to prevent this just yet, but we shouldn't in any case have modules take 30s in validation when they're so small. Whatever fix is applied here needs to be extended to wasm-smith since sometimes generating modules takes 30+ seconds since it's doing subtyping checks internally.
The text was updated successfully, but these errors were encountered: