Fuzzing has turned up that module linking can create large amounts of
tables and memories in addition to instances. For example if N instances
are allowed and M tables are allowed per-instance, then currently
wasmtime allows MxN tables (which is quite a lot). This is causing some
wasm-smith-generated modules to exceed resource limits while fuzzing!
This commits adds corresponding `max_tables` and `max_memories`
functions to sit alongside the `max_instances` configuration.
Additionally fuzzing now by default configures all of these to a
somewhat low value to avoid too much resource usage while fuzzing.
We already cover module linking with the `instantiate-swarm` target and
otherwise enabling module linking is preventing otherwise-valid modules
from being compiled because of the breaking change in the module linking
proposal with respect to imports.
Previously wasmtime would handle any signal originating from wasm JIT
code. This would, however, handle bugs in JIT code as-if they were wasm
traps. Instead this commit switches signal handling to specifically
check for whether the precise program counter is expected to be a trap.
This way if a program counter traps and it's not expected to trap the
signal isn't handled and the process is aborted (presumably leading to
further debugging of whomever happens to work on the JIT at that time).
With `Module::{serialize,deserialize}` it should be possible to share
wasmtime modules across machines or CPUs. Serialization, however, embeds
a hash of all configuration values, including cranelift compilation
settings. By default wasmtime's selection of the native ISA would enable
ISA flags according to CPU features available on the host, but the same
CPU features may not be available across two machines.
This commit adds a `Config::cranelift_clear_cpu_flags` method which
allows clearing the target-specific ISA flags that are automatically
inferred by default for the native CPU. Options can then be
incrementally built back up as-desired with teh `cranelift_other_flag`
method.
change reopen_with_fdflags(&self, fdflags) -> Result<Box<dyn WasiFile>>
to set_fdflags(&mut self, fdflags) -> Result<()>.
this makes way more sense than my prior hare-brained schemes.
This commit introduces two new methods on `Memory` that enable
reading and writing memory contents without requiring `unsafe`.
The methods return a new `MemoryError` if the memory access
fails.
