-
Notifications
You must be signed in to change notification settings - Fork 45
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support direct-to-FFI #46
Comments
Uhm, interestesting. Still, i'm not sure how to detect a segmentation fault or something like that without crashing QuickFuzz. |
Ah, I didn't think it through that far. |
I think a fork server like AFL can be more interesting. |
If I compile a Haskell program to native where QuickFuzz acts as a library, generating inputs from grammars using megadeth, and calls into a library (libwhatever) via FFI, couldn't I monitor the compiled Haskell application for crashes? Some form of supervision could restart the application on crash. It is ugly because the input that caused the crash would need to be persisted each time before being passed to the system under test, probably overwhelming the other gains. |
Yes, this is indeed possible, but we should be able to recover the crashing input (otherwise, it will be fast, but useless). |
I did some tests last night. While it is certainly possible to add ffi calls to test arbitrary shared libraries, it still requires to know in advance the arguments, so i created a simple example using libpng. You should compile a c program that takes a filename (CString in Hashell) and parse and execute stuff. This feature can be useful, but i think it can be simplified just creating a small c program that parses and executes all the filenames in argv, so we should add a batch mode in QuickFuzz. I can send you the example code of this feature, if you want to implement it. |
Is it worth creating an |
My idea to track the ByteString that caused the fault was to stash it on a RAM disk and have the supervisor pull it off in the case of a crash. |
Spawning an external process adds overhead in fuzzing. In the case where we are passing the value generated from the grammar to a library without fuzzing, it'd be interesting to see if there are performance gains invoking the library directly via Haskell's FFI instead of spawning an external process.
The text was updated successfully, but these errors were encountered: