<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 1, 2017 at 9:19 AM, Michael Kruse <span dir="ltr"><<a href="mailto:llvmdev@meinersbur.de" target="_blank">llvmdev@meinersbur.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">2017-02-01 18:07 GMT+01:00 Kostya Serebryany <<a href="mailto:kcc@google.com">kcc@google.com</a>>:<br>
> Yes, I used to run clang-fuzzer and clang-format-fuzzer on this bot, but not<br>
> any more.<br>
> The reason is simple -- the bot was always red (well, orange) and the bugs<br>
> were never fixed.<br>
><br>
> Currently we run clang-fuzzer (but not clang-format-fuzzer) on our internal<br>
> fuzzing infra<br>
> and Richard has fixed at least one bug found this way.<br>
> <a href="http://llvm.org/viewvc/llvm-project?view=revision&revision=291030" rel="noreferrer" target="_blank">http://llvm.org/viewvc/llvm-<wbr>project?view=revision&<wbr>revision=291030</a><br>
><br>
> My llvm fuzzing bot was pretty naive and simple.<br>
> If we want proper continuous fuzzing for parts of LLVM we either need to<br>
> build a separate "real" continuous fuzzing process,<br>
> or use an existing one. Luckily, there is one :)<br>
> As a pilot I've recently added the cxa_demangler_fuzzer to OSS-Fuzz:<br>
> <a href="https://github.com/google/oss-fuzz/tree/master/projects/llvm_libcxxabi" rel="noreferrer" target="_blank">https://github.com/google/oss-<wbr>fuzz/tree/master/projects/<wbr>llvm_libcxxabi</a><br>
> It even found one bug which Mehdi already fixed!<br>
> <a href="http://llvm.org/viewvc/llvm-project?view=revision&revision=293330" rel="noreferrer" target="_blank">http://llvm.org/viewvc/llvm-<wbr>project?view=revision&<wbr>revision=293330</a><br>
> The bug report itself will become public in ~4 days:<br>
> <a href="https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=370" rel="noreferrer" target="_blank">https://bugs.chromium.org/p/<wbr>oss-fuzz/issues/detail?id=370</a><br>
<br>
</span>Thanks for the explanation.<br>
<span class=""><br>
<br>
<br>
>> > Another (obvious?) fuzzing candidate would be the LLVM's bitcode<br>
>> > reader. I ran afl-fuzz on it and it found lots of failed assertions<br>
>> > within seconds. Isn't fuzzing done on a regular basis as [1] suggests<br>
>> > should be done? Should I report the crashes found by it?<br>
>><br>
>> The bitcode reader is known to not be robust against malformed inputs.<br>
><br>
><br>
> Yes, I afraid the bitcode reader (as some other parts of LLVM) are not<br>
> robust enough to withstand fuzzing. :(<br>
> Note that if we want to use libFuzzer (which is an in-process fuzzer) the<br>
> target should not assert/abort/exit on any input (if it's not a bug).<br>
<br>
</span>Is there any incentive to change that? </blockquote><div><br></div><div>Not that I know of.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">A google Summer of Code project maybe?<br></blockquote><div><br></div><div>Maybe. </div><div>The bottleneck is not bug finding, but bug fixing, which sometimes may require large changes. </div><div>And doing code review for such changes might be more work than just making them. </div><div><br></div><div>--kcc  </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>
Michael<br>
</font></span></blockquote></div><br></div></div>