I think we should (either in a third logic branch or maybe replacing both branches but configuring the max sizes appropriately) add a mode where we call the configured mutate-this-raw-data hook which we can make call libfuzzer's internal mutators directly when we are fuzzing.

https://docs.rs/libfuzzer-sys/latest/libfuzzer_sys/fn.fuzzer_mutate.html

To make sure I understand, you're imagining this saw raw_mutate_func-style hook being configured in WasmMutate? Something like an optional closure where, if present, is called here?

Yeah I think ideally we would write our own, default raw_mutate_func implementation and then just always call raw_mutate_func here, instead of maintaining N different code paths that do shrinking vs not shrinking etc. As long as raw_mutate_func abides by the size constraints passed to it, we shouldn't need separate branches for adding vs deleting vs editing.

How would that work though with the seed? We wouldn't pass in the seed or the Unstructured so what would the consumer used as the basis for mutating the input data?

Also if you're imagining that this is always an option should the CLI be the only one that implements this? By default would this mutator be disabled unless the callback were configured?

(sorry I'm not really sure how you're envisioning this working)

Hm yeah we should probably pass a seed into this callback.

We generally aren't using Unstructured here, not sure what you're getting at here.

In practice, we will hook raw_mutate_func up to https://docs.rs/libfuzzer-sys/latest/libfuzzer_sys/fn.fuzzer_mutate.html

If the raw_mutate_func is not configured, then we should use a default, internal implementation of the raw_mutate_func callback, similar to what you've done here but not hard-coded to be only for data segments.

impl WasmMutate {
    fn get_raw_mutate_func(&self) -> &dyn Fn(&mut Vec<u8>, ...) {
        self.raw_mutate_func.as_ref().unwrap_or(&default_raw_mutate_func)
    }
}

fn default_raw_mutate_func(
    data: &mut Vec<u8>, 
    // probably need to enrichen the `raw_mutate_func` signature with
    // a seed and info about whether we are only shrinking...
) {
    // ... the stuff you are doing for data segments right now ...
}

// ...

// Inside the data segment mutator.
(config.raw_mutate_func())(&mut my_data_segment);

Does that make sense?

Also if you're imagining that this is always an option should the CLI be the only one that implements this? By default would this mutator be disabled unless the callback were configured?

I would say the other way around: the CLI shouldn't expose this functionality because what different kinds of implementations can it have? We're probably not going to pipe out to another program to mutate these little bits of data, so there isn't really much to configure other than maybe the source of entropy. Not really useful here.

However, when using wasm-mutate as a library inside a fuzz target, we definitely want to hook this up to https://docs.rs/libfuzzer-sys/latest/libfuzzer_sys/fn.fuzzer_mutate.html so that we can let libfuzzer use its dictionary and all of its builtin mutation schemes when mutating these data segments or export names or what have you.

Sorry I was mixing up sources of randomness and got confused with Unstructured vs just a plain old Rng here.

Also thanks for explaining! I've pushed up something which I think roughly does what you're thinking, but I think it'd be good to double-check as well.

I think we need to pass a max_size parameter through to the raw mutation function. (a) libfuzzer_sys::fuzzer_mutate requires such a parameter, and (b) it lets us set max_size == data.len() - 1 when we are configured to only do size-reducing mutations. When we aren't shrinking, then we can either pass a max_size of data.capacity() or data.len() * 2 or something like that.

Makes sense! I threaded this through from the configuration of the pass itself, since the renaming of exports was already being configured with a maximum size.