<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 5, 2015 at 4:10 PM, Sami Liedes <span dir="ltr"><<a href="mailto:sami.liedes@iki.fi" target="_blank">sami.liedes@iki.fi</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Jan 05, 2015 at 11:11:06AM -0700, John Regehr wrote:<br>
> Sami, this is very cool.  Here are a few suggestions/comments/requests:<br>
<br>
</span>Thanks!<br>
<span class=""><br>
> Are you adding these into the LLVM bugzilla?<br>
<br>
</span>I added many in December:<br>
<a href="http://llvm.org/bugs/buglist.cgi?quicksearch=fuzz&list_id=65362" target="_blank">http://llvm.org/bugs/buglist.cgi?quicksearch=fuzz&list_id=65362</a><br>
<br>
But no, I have not added all.<br>
<span class=""><br>
> A lot of your crashers are syntactically invalid, but it often is the case<br>
> that crashes on valid code are more interesting than crashes on invalid<br>
> code.  Can you separate out the ones for which you have a valid test case?<br>
> These might just be the ones that GCC can compile.<br>
<br>
</span>I suspect that not very many cases produced are going to be valid<br>
code, or at least at this stage parser bugs are clearly prevalent.<br>
Maybe it will be possible to reach deeper bugs once the parser is more<br>
robust, I don't know. Recent releases of afl-fuzz even include some<br>
kind of support for extra dictionaries, i.e. making the fuzzer insert<br>
whole tokens like "template" or "typename", which presumably might<br>
increase its chances of producing something that looks like more<br>
legitimate code.<br>
<br>
Basically the fuzzer treats the source code just like any binary, and<br>
the results generally are a mess of text and binary garbage. I'm<br>
actually surprised that it manages to find any crashes that after<br>
reducing do not contain binary. I think the more interesting crashing<br>
cases are mostly produced by randomly combining (crossover) different<br>
clang test cases and cases discovered by fuzzing and combining that<br>
trigger new execution paths. I think if GCC accepted those it would be<br>
mostly by chance, unless it's a lot more tolerant towards binary<br>
garbage than Clang.<br>
<br>
After reducing the cases often look somewhat more sensible, but<br>
truncated, since with incremental parsing the smallest crashing input<br>
is often going to end in the middle of some block. GCC clearly would<br>
not compile those either.<br>
<br>
In the very least I believe it's safe to say the fuzzer is heavily<br>
biased towards finding parser bugs as long as they are relatively<br>
common. Whether it can go deeper than that is to be seen.<br>
<span class=""><br>
> Your mail mentions C-Reduce crashing.  Please report bugs to us when this<br>
> happens.<br>
<br>
</span>I dumped those cases where creduce has failed, together with the<br>
dumb-reduced cases causing the same crash on Clang (some since then<br>
fixed, I think) and the assertion failures they caused. I used CReduce<br>
with llvm 3.5. With CReduce using clang, I don't find it that<br>
surprising that it fails on some of the inputs that also cause Clang<br>
to crash.<br>
<br>
    <a href="http://sli.dy.fi/~sliedes/creduce-failures.tar.gz" target="_blank">http://sli.dy.fi/~sliedes/creduce-failures.tar.gz</a><br>
<span class=""><br>
> If you have time, it would be helpful to add Csmith into the mix here.  I<br>
> would be very interested to learn how Csmith and AFL work together.<br>
<br>
</span>A bit hard to see how they would work together. IIUC Csmith tries hard<br>
to produce code that is also a semantically valid C program; afl-fuzz<br>
tries to mangle the input to maximize code coverage in the compiler<br>
and knows nothing about code correctness. Anyway, I believe there's<br>
still likely to be a lot of bugs to be found starting from the clang<br>
test cases; together they contain large amounts of quite different,<br>
even exotic constructs. I've only started to run afl-fuzz; it doesn't<br>
get far through its work queue (I think less than 1%, and the queue<br>
obviously grows) until it hits its limit of 5000 crashing cases found<br>
- though it still takes a few days to get that far; running clang that<br>
many times is resource intensive. Obviously that's the low-hanging,<br>
rather easy-to-find fruit.<br>
<span class=""><br>
> You should definitely turn on LLVM optimizations when doing this testing,<br>
> unless there's some specific reason why that isn't a good idea.<br>
<br>
</span>I think it will be a good idea once it no longer hits that many parser<br>
bugs. The drawback is that with -O0 I can do something like 300<br>
executions/second on a 4-core machine, and with that speed I guess it<br>
would already take at least months to go through afl-fuzz's queue<br>
starting from the clang test suite.<br></blockquote><div><br></div><div>I'm wondering how much we can improve on that 300 executions/second. My guess is that a lot of time is constant-overhead startup code. A back of the envelope calculation:</div><div><br></div><div>300 executions/second * 300 bytes/source file (small files) ~ 100 000 bytes/second.</div><div>4 cores * 3 giga instructions/second ~ 10 000 000 000 instructions/second.</div><div><br></div><div>So that's about 1 million instructions per byte, which seems excessive.</div><div><br></div><div>The first thing that comes to mind to hack around that would be write a quick tool that uses clang as a library and have afl-fuzz just send it IPC messages asking it to parse files; the server then forks off a child to parse, avoiding all the startup overhead and option parsing and stuff inside clang.</div><div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
        Sami<br>
</font></span><br>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div><br></div></div>