[llvm-dev] Using Libfuzzer on a library - linking the library to the fuzz target

[Shikhar Singh via llvm-dev]

Hi Mitch,

Thank you for the response.

1. You don't need to build the library with `-fsanitize-coverage=...`,
using `-fsanitize=fuzzer-no-link,address` should be sufficient.  -
Acknowledged
2. (although you can actually build object files/shared libraries with
-fsanitize=fuzzer, and the libFuzzer main won't be linked, if this makes
your build process easier). -  with just the *fuzzer *flag, it looks for
the LLVMFuzzerTestOneInput.
3. I've run a quick grep and can't find anything that would match
"apifunc() resp=0x7ff38f83ac20 uninitialized, fixing it." in libFuzzer (or
compiler-rt). What version of compiler-rt/llvm/clang are you trying this
with? -  This was an oversight on my part, it was a log dump from the
library and somehow I mistook it be from libfuzzer. (I am using Clang 9
btw).
4. Have you tried visualising the coverage
<https://github.com/google/fuzzing/blob/master/tutorial/libFuzzerTutorial.md#visualizing-coverage>
that
the fuzz target is generating? It may give you an insight as to why your
desired function under test isn't being hit. - Yes, I am using lcov for
coverage and do see the relevant methods being exercised.

I am wondering if there is a reason I am not seeing the function in
the NEW_FUNC[x/xxx]: log lines.
To iterate my steps -

First I build the library with fuzzer-no-link,address flags. I *don't*
compile the fuzz_target (the file containing the LLVMFuzzerTestOneInput
function) with the library.
Then I build the fuzz target and link it with the library.

*clang++ -g -O1 -fsanitize=fuzzer,address  -Iinclude -Ibuild/include .....
fuzztarget.c -Lbuild/lib -llib1 -llib2*
and then finally *./a.out -detect_leaks=0 corpus/*

I appreciate your help with this.

On Tue, Nov 12, 2019 at 11:38 AM Mitch Phillips <mitchp at google.com> wrote:

> Hi Shikhar,
>
> You don't need to build the library with `-fsanitize-coverage=...`, using
> `-fsanitize=fuzzer-no-link,address` should be sufficient. Without being
> able to inspect, it seems like you're building the library/fuzz target in a
> sane manner (although you can actually build object files/shared libraries
> with -fsanitize=fuzzer, and the libFuzzer main won't be linked, if this
> makes your build process easier).
>
> I've run a quick grep and can't find anything that would match "apifunc()
> resp=0x7ff38f83ac20 uninitialized, fixing it." in libFuzzer (or
> compiler-rt). What version of compiler-rt/llvm/clang are you trying this
> with?
>
> Have you tried visualising the coverage
> <https://github.com/google/fuzzing/blob/master/tutorial/libFuzzerTutorial.md#visualizing-coverage>
> that the fuzz target is generating? It may give you an insight as to why
> your desired function under test isn't being hit.
>
> - Mitch
>
> On Tue, Nov 12, 2019 at 9:16 AM Shikhar Singh via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> I am working of using libfuzzer and asan to test out a third-party
>> library.
>> As demonstrated in the tutorial, I wrote a fuzz target to fuzz a specific
>> function in the library. The fuzz target is then linked to the library and
>> compiles clean and I do see some tests generated by the fuzzer. However, I
>> have some questions regarding the "right" way to go about doing this. I
>> have doubts that the fuzzer taking coverage feedback from the
>> fuzztarget and not the library functions (not sure though). Suppose the
>> function in the library being tested is called - *apifunc()*. The
>> libfuzzer log has a line which says - *apifunc() resp=0x7ff38f83ac20
>> uninitialized, fixing it*. I am not sure what this means. Also, I can
>> see that the apifunc is called and it runs but it does not show up in the
>>  *NEW_FUNC[x/xxx]: *log lines in the libfuzzer output.
>>
>> To enable fuzzing. First I build the library with the following libfuzzer
>> flags.
>>
>> *-fsanitize=fuzzer-no-link,address -fsanitize-coverage=edge,indirect-calls*
>> I also had to make a blacklist to avoid some buffer overflow and use
>> after free error during this build.
>>
>> After this, I link the fuzz target with the library and use the following
>> libfuzzer options.
>> *-fsanitize=fuzzer,address*
>>
>> I am looking for some guidance and feedback if this is the right way to
>> go about fuzzing the library and the meaning of *uninitialized fixing
>> it *line in the log.
>> --
>> Live long and Prosper,
>>
>> Shikhar Singh
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>

-- 
Live long and Prosper,

Shikhar Singh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191112/8b3153b2/attachment-0001.html>