What is the status of feedback-driven persistent fuzzing on macOS?

[PaulGrandperrin]

Hi, I'm the author of honggfuzz-rs and I'm trying to make the project work on macOS.
My project is using feedback-driven persistent fuzzing and it's working great on Linux, but I got a very hard time making it work on macOS (in a High Sierra VM), so I'm wondering what's the status of this functionality on macOS.

Here is what I did:

• On linux, I was building the project with make clean honggfuzz libhfuzz/libhfuzz.a but it fails on macOS. I had to split the command into make clean and make honggfuzz libhfuzz/libhfuzz.a. I'm a very basic user of Makefiles so I didn't try to understand why this is happening but here is the error log: https://travis-ci.org/rust-fuzz/honggfuzz-rs/jobs/343084274
• Then the linker failed because of undefined symbols to ___sanitizer_cov_trace_const_cmp. I didn't try very hard to understand why, maybe it has something to do with weak links or maybe it's Rust specific, anyway, here is the log: https://travis-ci.org/rust-fuzz/honggfuzz-rs/jobs/343450350
• I disabled sanitizer-coverage-trace-compares
• Then, it compiled fine but setrlimit(NOFILE) failed just after forking to spawn a fuzzing thread. dup2 failed just after and prevented communication between honggfuzz and the child. Here is the log: https://travis-ci.org/rust-fuzz/honggfuzz-rs/jobs/343580375
• I fixed the problem by following the recommendation of the macOS manpage of setrlimit: rlim_cur = min(OPEN_MAX, rlim_max). I can send a PR with the exact fix if you want.
• Then, after one fuzzing iteration, honggfuzz and the child stopped communicating properly. The child was waiting on receiving the file size but honggfuzz was waiting for reaping the child.
  The issue arises from this call: https://github.com/google/honggfuzz/blob/master/subproc.c#L343 because the implementation of arch_reapChild differs in logic between Linux and macOS:
  https://github.com/google/honggfuzz/blob/master/linux/arch.c#L328-L354
  https://github.com/google/honggfuzz/blob/master/mac/arch.c#L367-L398
  On macOS, the code is waiting unconditionally for the death of the child whereas it correctly returns on Linux thanks to the call to subproc_persistentModeRoundDone.
• I tried to comment the call to arch_reapChild and it worked a bit better: it could run for a few hundred/thousand iterations and then hang again without any warning.
• I gave up this path and tried compiling with OS=posix make ....
• There were many compilation errors easily fixable by manually re-enabling Darwin specific #ifdef and keeping the setrlimit patch.
• Now it works but it's very slow, like 100 times slower than Linux (maybe it's because of my VM).

So, in the end, I guess the mac specific code is not ready for this use case but I would like to be sure it's not a problem on my side.

I would be very happy to help to make this work on macOS. I can clean my patches that work with OS=posix and send you a PR if you want.

[robertswiecki]

The persistent fuzzing is not implemented in mac/ - it requires basically logic as in posix/ here -

https://github.com/google/honggfuzz/blob/master/posix/arch.c#L210

I.e. - waiting for signals about data on a persistent socket, or child process exit.

I'm in a process of getting MacOS box, so unless somebody will work on that first, I'll try to fix it next week.

[PaulGrandperrin]

Awesome! So the code is indeed not ready yet but it looks like it's not very far.
I might try to do it tomorrow, is there anything else I might need to know?

[robertswiecki]

Yeah, it shouldn't be hard, assuming that MacOSX provides all necessary functionality (and, sometimes it doesn't as its relationship with POSIX seems complicated:). The directory for mac/ exists aside to posix/ because it contains additional crash analysis code, though it was @felixgr @anestisb and @tl0gic who implemented it, and not me, so I don't know that much about it.

[PaulGrandperrin]

I guess we can now say that it's implemented and working so I'm closing!