On Thu, Sep 7, 2017 at 9:02 AM, 吴潍浠(此彼) <weixi....@antfin.com> wrote:
> Hi
> The trace-div and trace-gep options seems be used to evaluate corpus
> to trigger specific kind of bugs. And they don't have strong effect to
> coverage.
>
> The trace-pc-guard is useful, but it may be much more complex than trace-pc.
> I think the best benefit of trace-pc-guard is avoiding dealing ASLR of
> programs,
> especially programs with dlopen(). Seems hard to implement it in Linux kernel.
>
> The inline-8bit-counters and pc-table is too close to implementation of fuzz
> tool and
> option trace-pc-guard .
>
> I am interesting in "stack-depth" and "func". If we trace user-defined
> functions enter and exit,
> we can calculate stack-depth and difference level of stack to past existed
> stack.
> Adding __sanitizer_cov_trace_pc_{enter,exit} is easy , but it is not standard
> of llvm.
>
> How do you think Dmitry ?
>
> Wish Wu
>
> ------------------------------------------------------------------
> From:Jakub Jelinek <ja...@redhat.com>
> Time:2017 Sep 6 (Wed) 22:37
> To:Wish Wu <weixi....@antfin.com>
> Cc:Dmitry Vyukov <dvyu...@google.com>; gcc-patches <gcc-patches@gcc.gnu.org>;
> Jeff Law <l...@redhat.com>; wishwu007 <wishwu...@gmail.com>
> Subject:Re: Add support to trace comparison instructions and switch statements
>
>
> On Wed, Sep 06, 2017 at 07:47:29PM +0800, 吴潍浠(此彼) wrote:
>> Hi Jakub
>> I compiled libjpeg-turbo and libdng_sdk with options "-g -O3 -Wall
>> -fsanitize-coverage=trace-pc,trace-cmp -fsanitize=address".
>> And run my fuzzer with pc and cmp feedbacks for hours. It works fine.
>> About __sanitizer_cov_trace_cmp{f,d} , yes, it isn't provided by llvm. But
>> once we trace integer comparisons, why not real type comparisons.
>> I remember Dmitry said it is not enough useful to trace real type
>> comparisons because it is rare to see them in programs.
>> But libdng_sdk really has real type comparisons. So I want to keep them and
>> implementing __sanitizer_cov_trace_const_cmp{f,d} may be necessary.
>
> Ok. Please make sure those entrypoints make it into the various example
> __sanitier_cov_trace* fuzzer implementations though, so that people using
> -fsanitize-coverage=trace-cmp in GCC will not need to hack stuff themselves.
> At least it should be added to sanitizer_common (both in LLVM and GCC).
>
> BTW, https://clang.llvm.org/docs/SanitizerCoverage.html shows various other
> -fsanitize-coverage= options, some of them terribly misnamed (e.g. trace-gep
> using some weirdo LLVM IL acronym instead of being named by what it really
> traces (trace-array-idx or something similar)).
>
> Any plans to implement some or all of those?
Thanks, Jakub!
I've tested it on Linux kernel. Compiler does not crash, code is instrumented.
Re terribly misnamed trace-gep, dunno, I will leave this to Kostya.
Re __sanitizer_cov_trace_cmp{f,d}, I am still not sure.
> But libdng_sdk really has real type comparisons.
Do they come from input data? In what format? How do you want to use
them? E.g. if they come from input but with using some non-trivial
transformation and the fuzzer will try to find them in the input, it
won't be able to do so.
On the other hand, it does not seem to be harmful, fuzzers that are
not interested in them can just add empty callbacks.
Re trace-pc-guard, I also don't have strong preference. Global
variables should work for kernel, but we probably will not use them in
kernel, because even aslr aside we would need to establish some global
numbering of these globals across multiple different machines. But
then it's much easier and simper to just use PCs as identifiers.
Re __sanitizer_cov_trace_pc_{enter,exit}, I don't think we ever
experimented/evaluated this idea. Do you have any data that it's
useful? I suspect that it can grow corpus too much.
