Add mini CmpLog

[louismerlin]

As suggested in #323, CmpLog could be added to afl.rs to improve effectiveness.

Testing this change on the following example will find the crash immediately instead of after a minute.

I can see no performance drop, some more benchmarking might be needed.

You need to specify the -c 0 option (or -c path/to/your/binary).

fn main() {
    afl::fuzz!(|data: &[u8]| {
        if data.len() != 6 {return}
        if data[0] != b'q' {return}
        if data[1] != b'w' {return}
        if data[2] != b'e' {return}
        if data[3] != b'r' {return}
        if data[4] != b't' {return}
        if data[5] != b'y' {return}
        panic!("BOOM")
    });
}

I also tried adding the following flags but they resulted in compilation errors of the target.

 -C llvm-args=-sanitizer-coverage-trace-geps \
 -C llvm-args=-sanitizer-coverage-trace-loads \
 -C llvm-args=-sanitizer-coverage-trace-stores \

[vanhauser-thc]

-c 0 is the easier way to do that, had forgotten to write that in the issue.
I recommend to add this directly to the cargo run in this PR.

there is a performance loss, about 10% lower execution speed, that could be circumvented by compiling the target twice, once normally and once for minicmplog, and passing the binary of minicmplog via -c minicmplogcompiledtarget, but that just complicates things.

The performance loss in execution speed is overall less that the effectiveness gained by enabling this feature.

[smoelius]

You need to specify the -c 0 option (or -c path/to/your/binary).

What do these options do?

[vanhauser-thc]

You need to specify the -c 0 option (or -c path/to/your/binary).

What do these options do?

Both do the same thing (-c0 is easier) - they tell afl-fuzz that cmplog data is available. Otherwise the data is ignored.

[louismerlin]

I added an example in the examples directory which demonstrates the capabilities of this mini CmpLog.

[vanhauser-thc]

isnt it possible to automatically pass -c 0 to afl-fuzz when doing cargo fuzz? the user will very likely not know to put -c 0 as command line parameter on his own.

[louismerlin]

isnt it possible to automatically pass -c 0 to afl-fuzz when doing cargo fuzz? the user will very likely not know to put -c 0 as command line parameter on his own.

Added in 4a60756

[vanhauser-thc]

LGTM, can be merged in my opinion.

[smoelius]

I'm trying to test this, and I'm getting the following error for some projects:

undefined reference to '__sanitizer_cov_trace_div8'

It appears to have something to do with build scripts.

For example, cargo afl build in the root of this repository gives me that error: https://github.com/paholg/typenum

Does it work for you?

Removing this line makes the problem go away:

afl.rs/src/bin/cargo-afl.rs

Line 377 in e1c2f2e

-C llvm-args=-sanitizer-coverage-trace-divs \

[vanhauser-thc]

I'm trying to test this, and I'm getting the following error for some projects:

undefined reference to '__sanitizer_cov_trace_div8'

It appears to have something to do with build scripts.

For example, cargo afl build in the root of this repository gives me that error: https://github.com/paholg/typenum

Does it work for you?

Removing this line makes the problem go away:

afl.rs/src/bin/cargo-afl.rs

Line 377 in e1c2f2e

-C llvm-args=-sanitizer-coverage-trace-divs \

that is weird as this parameter is already present in ancient llvm 9...
clang-9 -o test-instr -fsanitize-coverage=trace-div test-instr.c

trace-div is not that important of an option, it has more value for a technique called value profiling which afl++ does not use (because better technique exists, but libfuzzer uses that).

[smoelius]

Does your comment imply you were able to reproduce the error, @vanhauser-thc?

EDIT: That is not to insinuate that you must try.

[louismerlin]

I was able to reproduce the bug, I've removed the trace-divs flag. Thanks!

[smoelius]

@louismerlin Thanks very much for this. And, @vanhauser-thc, thank you for the review, and for sharing your expertise.

In the interest of caution, I am going to treat this as a breaking change. There is at least one other thing I wanted to include with the next breaking change (#276). So it will be a few days before I publish this. But I promise to try to push a new release soon.

Thanks again.