LibAFL QEMU Mode

[bitterbit]

Hi @domenukk and @andreafioraldi and all the AFLplusplus gang 🎊

I saw the "Proposed projects" issue and the qemu-libafl-bridge project and was curious to how you were planning to implement the QEMU integration. Currently most implementations I know use QEMU as a black box communicating with it over pipes and shared memory, but the code in qemu-libafl-bridge looked more like an integrated implementation where the fuzzer (LibAFL) might do step by step instrumentation. I would love to help implement a QEMU mode and was interested to how you were thinking to implement this

P.S.
this is my first time using Discussions on GitHub so I hope this is the right place for this discussion

[domenukk]

Yes, there is (usually) no need to interact with an emulator via IPC.
The old-skool AFL approach, with the main fuzzer thread blocking until the emulator requests the next testcase, then generating a testcase, then shifting execution back to the emulator, adds overhad and needs more kernel interactions.
Instead, we can just call into the emulator, run some code, generate the next testcase, in a loop - single threaded and minimal to no kernel interaction.

[bitterbit]

Sounds awesome 💪 :)
I am using qemu+afl in persistent mode and with htop it looks like there is some noticeable wasted time spent waiting so, it makes total sense to me (but I am not sure I'm measuring it correctly)

Just from curiosity, why not use unicorn?
Is there a noticeable performance issue? or is it just not wanting to implement the linker (and syscalls) for linux?

[s1341]

I think that we should aim to have both unicorn and qemu modes...

[domenukk]

Unicorn has a different use case: loading a blob at location xyz in memory, then run it. Somtimes that's convenient, most of the times it isn't
As you suggest, neither loading is "solved" nor do syscalls work. On top, it always uses softmmu, which is pretty slow. It doesn't have any sort of coprocessors, and it's based on a very old version of qemu.
I only use it for some mild parser fuzzing in obscure targets.
For anything normal, you want user-mode.

[domenukk]

WRT performance debugging, use perf top, there you also see the time your target spends in the kernel.
The actual waiting time is not wasted, as during that time it actually runs the target. We just want to get rid of expensive context switches

[bitterbit]

Good stuff to know, thanks :)
And about the QEMU vs Unicorn makes total sense

[andreafioraldi]

The other advantage that I have in mind is to expose some hooks from QEMU to Rust and implement all that we need in Rust.
For instance, at translation time we can map a pair of addresses representing an edge (a, b) to an unique integer (for collision free coverage), use it for the fuzzer instrumentation and store the mapping into an hashtable in State. In this way, when the fuzzer is restarted (e.g. after a crash) the new instance can reuse the previous mapping

[bitterbit]

Yes that would be neat

[andreafioraldi]

If you want to contribute, the first step is to patch QEMU to be a library or to include a static Rust library (that will include libafl) in the final QEMU binary. Then you can code a simple program that sets some breakpoints using the API that I coded and run the target.

[bitterbit]

Sounds like a solid plan. I am up to it but it might take me time until I find enough time to work on this, looks like a very nice project to do :)

[langston-barrett]

Update: There is now a QEMU/LibAFL integration that uses QEMU as a library and supports various hooks.