<div dir="ltr"><div>Greg, </div>This is lots of useful feedback! <div>I'll reply to individual bullets when time permits (mostly after the holidays). </div><div><br></div><div>If you find a bug in Postgres with libFuzzer, please let us know so that we</div><div>can add it to <a href="http://llvm.org/docs/LibFuzzer.html#trophies">http://llvm.org/docs/LibFuzzer.html#trophies</a></div><div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Sep 5, 2015 at 8:40 AM, Greg Stark via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=llvm-dev@lists.llvm.org&cc=&bcc=&su=&body=','_blank');return false;">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On Sat, Sep 5, 2015 at 1:50 PM, Greg Stark <<a href="mailto:stark@mit.edu" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=stark@mit.edu&cc=&bcc=&su=&body=','_blank');return false;">stark@mit.edu</a>> wrote:<br>
> 2) I've caught a bug which causes enormous stack growth. AFL enforces<br>
> strict memory and time limits on the tests which is awfully<br>
> convenient. I can implement those myself in my fuzzer function (and in<br>
> fact in the Postgres context it would be best if I did) but some<br>
> simple AFL-style protection would be appreciated, as it is it takes a<br>
> *looong* time to fail and doesn't leave behind the crashing test. It<br>
> would be nice if Libfuzzer took a page out of the sanitize code's<br>
> tricks and kept an mmapped file where it wrote the current test being<br>
> run. If the file is never synced then it shouldn't cause any syscalls<br>
> or I/O until the program crashes and the file descriptor is closed.<br>
><br>
> My thinking is I need to set an RLIMIT_STACK setting and then install<br>
> a SEGV handler which will longjmp back to the top level and return to<br>
> the fuzzer. That will be risky since it's in theory impossible to<br>
> restore any state the SEGV caused but in practice if it's always<br>
> caused by a stack overflow might be safe. I would also like to have an<br>
> ALRM handler but that requires calling alarm() on every call and I'm<br>
> not sure if the setitimer in Libfuzzer can be disabled or if it'll<br>
> interfere with that. Maybe there's a better approach, I could call<br>
> setitimer and if I see more than n ALRMs during the execution decide<br>
> it's a fault. Again it would be nice if Libfuzzer provided that<br>
> itself.<br>
<br>
<br>
</span>It occurs to me that this is silly as Libfuzzer is currently not<br>
capable of continuing once it finds one crash. There's no way for my<br>
FuzzOne() call to report that the test "failed" but that it's still<br>
prepared to continue fuzzing more inputs. This seems like the<br>
fundamental problem I'm missing.<br></blockquote><div><br></div><div>This is more like a limitation of asan, not libFuzzer. </div><div>By design, asan does not recover from the first crash. </div><div>This feature has been criticized quite a lot, but I am still convinced this is a feature, not a bug.</div><div>IMHO, recovery mode will be misused/abused too often to be useful, besides it adds complexity to the code.  </div><div>(There is a patch under review right now to implement recovery mode for asan, </div><div>but I am not sure if or when this patch will be committed)</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Also, one more thing, currently Libfuzzer does not catch SIGABRT and<br>
treat it as a fatal event. I've added a SIGABRT handler to my own code<br>
and moved StaticDeathCallback to public so I can call it from there.<br>
<div class=""><div class="h5"><br></div></div></blockquote><div>Again, this is asan, not libFuzzer.  </div><div>You need ASAN_OPTIONS=handle_abort=1</div><div>I hope to make it the default soon-ish. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">
--<br>
greg<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=llvm-dev@lists.llvm.org&cc=&bcc=&su=&body=','_blank');return false;">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br></div></div></div>