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

Tue Nov 12 13:17:14 PST 2019

Hmm, thanks for the info. I can't think of a good reason why this is
happening top of mind - is it possible you can minify to a testcase?

On Tue, Nov 12, 2019 at 11:27 AM Shikhar Singh <shikhar.singh8990 at gmail.com>
wrote:

> 1.  __sanitizer_symbolize_pc is present
> 2. Symbolizer support is missing (either llvm-symbolizer is not in your
> path or in ASAN_OPTIONS=symoblizer_path, the internal symbolizer fails, or
> something else goes wrong)  - verified and re-ran this.
>
> Do you see any outputs of NEW_FUNC[]? Is just the apifunc() line missing?
> - I do see other functions and its just the apifunc that is missing along
> with any subsequent functions called by apifunc.
>
> On Tue, Nov 12, 2019 at 12:15 PM Mitch Phillips <mitchp at google.com> wrote:
>
>> > I am wondering if there is a reason I am not seeing the function in the
>> NEW_FUNC[x/xxx]: log lines.
>>
>> I can think of a couple of reasons why this might be happening.
>>
>>    1. The function __sanitizer_symbolize_pc is missing in your binary
>>    (you can check easily with `nm <binary> | grep sanitizer_symbolize_pc`)
>>    2. Symbolizer support is missing (either llvm-symbolizer is not in
>>    your path or in ASAN_OPTIONS=symoblizer_path, the internal symbolizer
>>    fails, or something else goes wrong).
>>
>> Do you see any outputs of NEW_FUNC[]? Is just the apifunc() line missing?
>>
>> On Tue, Nov 12, 2019 at 10:02 AM Shikhar Singh <
>> shikhar.singh8990 at gmail.com> wrote:
>>
>>> 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
>>>
>>
>
> --
> Live long and Prosper,
>
> Shikhar Singh
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191112/93f41867/attachment-0001.html>