[llvm-dev] Some feedback on Libfuzzer

[Greg Stark via llvm-dev]

On Sat, Sep 5, 2015 at 1:50 PM, Greg Stark <stark at mit.edu> wrote:
> 2) I've caught a bug which causes enormous stack growth. AFL enforces
> strict memory and time limits on the tests which is awfully
> convenient. I can implement those myself in my fuzzer function (and in
> fact in the Postgres context it would be best if I did) but some
> simple AFL-style protection would be appreciated, as it is it takes a
> *looong* time to fail and doesn't leave behind the crashing test. It
> would be nice if Libfuzzer took a page out of the sanitize code's
> tricks and kept an mmapped file where it wrote the current test being
> run. If the file is never synced then it shouldn't cause any syscalls
> or I/O until the program crashes and the file descriptor is closed.
>
> My thinking is I need to set an RLIMIT_STACK setting and then install
> a SEGV handler which will longjmp back to the top level and return to
> the fuzzer. That will be risky since it's in theory impossible to
> restore any state the SEGV caused but in practice if it's always
> caused by a stack overflow might be safe. I would also like to have an
> ALRM handler but that requires calling alarm() on every call and I'm
> not sure if the setitimer in Libfuzzer can be disabled or if it'll
> interfere with that. Maybe there's a better approach, I could call
> setitimer and if I see more than n ALRMs during the execution decide
> it's a fault. Again it would be nice if Libfuzzer provided that
> itself.


It occurs to me that this is silly as Libfuzzer is currently not
capable of continuing once it finds one crash. There's no way for my
FuzzOne() call to report that the test "failed" but that it's still
prepared to continue fuzzing more inputs. This seems like the
fundamental problem I'm missing.

Also, one more thing, currently Libfuzzer does not catch SIGABRT and
treat it as a fatal event. I've added a SIGABRT handler to my own code
and moved StaticDeathCallback to public so I can call it from there.

-- 
greg