Skip to content
This repository has been archived by the owner on Mar 22, 2024. It is now read-only.

Support qemu 4.1.0 for non-instrumented binaries (-Q) #43

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

blurbdust
Copy link

This PR is to update the version of qemu used in non-instrumented binaries from qemu 2.10.0 to qemu 4.1.0.

This does break ease of building though as qemu now depends on libcapstone-dev >= 3. I had issues with Debian jessie packages for libcapstone and libcapstone2-dev being too far out of date. I solved this with using the stretch debs for libcapstone3-dev and libcapstone. See Line 148 of the build script for a few comments and the added dependency check.

In terms of performance, before on qemu 2.10.0 on my laptop I was seeing ~12-15 executions per second with fuzzing readelf. With qemu 4.1.0 I am seeing ~40-45 executions per second again with readelf. This probably should be tested more however my initial tests seem good.

I tested building and running on Arch Linux as well as building on a fully up-to-date Debian Jessie.

Let me know if you need anything else from me and thank you for this project!

@jonathanmetzman
Copy link
Contributor

Thanks for the patch.
Two points:

  1. We'll have to install libcapstone-dev on travis in order to land this. I may ask you to do this.
  2. I need to think more about whether we want to introduce dependencies that need to be installed externally. One of the big advantages of AFL is the fact that it is dead simple to install. A dependency like this would take away from that. I'll think about this more.

@andreafioraldi
Copy link
Contributor

andreafioraldi commented Nov 12, 2019

Hi guys, are you sure that QEMU 4 is a good idea? I tested it a bit for AFL++, the performance decrement is huge compared to QEMU 3.
In AFL++, readelf is fuzzed with ~420 exec/s on my laptop ( i5-4200U CPU @ 1.60GHz, AFL++ current git-master, QEMU 3.1.1) but the port to QEMU 4 give me a speed of ~35 exec/sec on readelf. AFL QEMU mode is a lot different from AFL++ so maybe QEMU 4 is good for you, but in my experience there is a problem in caching in QEMU 4 and I can't figure out why.

@andreafioraldi
Copy link
Contributor

I suspect a fix introduced in QEMU 4 to fix an unprobable overflow of the translated instructions in the block. However I'm not sure about it, I suggest you to try QEMU 3 before switching to 4.

@vanhauser-thc
Copy link
Contributor

@andreafioraldi they have a speed increase going from version 2 to 4, so for stock afl it is helpful. In afl++ we are noticing a speed decrease because we have much better optimization they are missing - that version 4 kills, so for us it would be bad to upgrade to 4.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants