f12b4c467c
* Add resource limiting to the Wasmtime API. This commit adds a `ResourceLimiter` trait to the Wasmtime API. When used in conjunction with `Store::new_with_limiter`, this can be used to monitor and prevent WebAssembly code from growing linear memories and tables. This is particularly useful when hosts need to take into account host resource usage to determine if WebAssembly code can consume more resources. A simple `StaticResourceLimiter` is also included with these changes that will simply limit the size of linear memories or tables for all instances created in the store based on static values. * Code review feedback. * Implemented `StoreLimits` and `StoreLimitsBuilder`. * Moved `max_instances`, `max_memories`, `max_tables` out of `Config` and into `StoreLimits`. * Moved storage of the limiter in the runtime into `Memory` and `Table`. * Made `InstanceAllocationRequest` use a reference to the limiter. * Updated docs. * Made `ResourceLimiterProxy` generic to remove a level of indirection. * Fixed the limiter not being used for `wasmtime::Memory` and `wasmtime::Table`. * Code review feedback and bug fix. * `Memory::new` now returns `Result<Self>` so that an error can be returned if the initial requested memory exceeds any limits placed on the store. * Changed an `Arc` to `Rc` as the `Arc` wasn't necessary. * Removed `Store` from the `ResourceLimiter` callbacks. Custom resource limiter implementations are free to capture any context they want, so no need to unnecessarily store a weak reference to `Store` from the proxy type. * Fixed a bug in the pooling instance allocator where an instance would be leaked from the pool. Previously, this would only have happened if the OS was unable to make the necessary linear memory available for the instance. With these changes, however, the instance might not be created due to limits placed on the store. We now properly deallocate the instance on error. * Added more tests, including one that covers the fix mentioned above. * Code review feedback. * Add another memory to `test_pooling_allocator_initial_limits_exceeded` to ensure a partially created instance is successfully deallocated. * Update some doc comments for better documentation of `Store` and `ResourceLimiter`.
45 lines
1.4 KiB
Rust
45 lines
1.4 KiB
Rust
//! Fuzzing infrastructure for Wasmtime.
|
|
|
|
#![deny(missing_docs, missing_debug_implementations)]
|
|
|
|
pub mod generators;
|
|
pub mod oracles;
|
|
|
|
/// One time start up initialization for fuzzing:
|
|
///
|
|
/// * Enables `env_logger`.
|
|
///
|
|
/// * Restricts `rayon` to a single thread in its thread pool, for more
|
|
/// deterministic executions.
|
|
///
|
|
/// If a fuzz target is taking raw input bytes from the fuzzer, it is fine to
|
|
/// call this function in the fuzz target's oracle or in the fuzz target
|
|
/// itself. However, if the fuzz target takes an `Arbitrary` type, and the
|
|
/// `Arbitrary` implementation is not derived and does interesting things, then
|
|
/// the `Arbitrary` implementation should call this function, since it runs
|
|
/// before the fuzz target itself.
|
|
pub(crate) fn init_fuzzing() {
|
|
static INIT: std::sync::Once = std::sync::Once::new();
|
|
|
|
INIT.call_once(|| {
|
|
let _ = env_logger::try_init();
|
|
|
|
let _ = rayon::ThreadPoolBuilder::new()
|
|
.num_threads(1)
|
|
.build_global();
|
|
})
|
|
}
|
|
|
|
/// Create default fuzzing config with given strategy
|
|
pub fn fuzz_default_config(strategy: wasmtime::Strategy) -> anyhow::Result<wasmtime::Config> {
|
|
init_fuzzing();
|
|
let mut config = wasmtime::Config::new();
|
|
config
|
|
.cranelift_nan_canonicalization(true)
|
|
.wasm_bulk_memory(true)
|
|
.wasm_reference_types(true)
|
|
.wasm_module_linking(true)
|
|
.strategy(strategy)?;
|
|
Ok(config)
|
|
}
|