trace comparison instructions and switch statements
On 09/19/2017 03:14 PM, Tamar Christina wrote:
> it's fine at O1, O2 and O3 though. Should the test be running for O0?
It's a known issue:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82183
Martin
On 09/19/2017 03:14 PM, Tamar Christina wrote:
> it's fine at O1, O2 and O3 though. Should the test be running for O0?
It's a known issue:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82183
Martin
uesday, September 12, 2017 5:35 PM
To: Dmitry Vyukov
Cc: 吴潍浠(此彼); Jakub Jelinek; gcc-patches; Jeff Law; wishwu007; Alexander
Potapenko; andreyknvl
Subject: Re: Add support to trace comparison instructions and switch statements
On Tue, Sep 12, 2017 at 7:32 AM, Dmitry Vyukov wrote:
> On Thu, Sep 7,
On Tue, Sep 12, 2017 at 7:32 AM, Dmitry Vyukov wrote:
> On Thu, Sep 7, 2017 at 9:02 AM, 吴潍浠(此彼) 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.
These are used for what I c
Some stats from kernel build for number of trace_cmp callbacks:
gcc
non-const: 38051
const: 272726
total: 310777
clang:
non-const: 45944
const: 266299
total: 312243
The total is quite close. Gcc seems to emit more const callbacks, which is good.
On Tue, Sep 12, 2017 at 4:32 PM, Dmitry Vyukov
On Thu, Sep 7, 2017 at 9:02 AM, 吴潍浠(此彼) 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 thin
Hi David,
> On Thu, Sep 7, 2017 at 6:57 PM, Rainer Orth
> wrote:
>> Jakub Jelinek writes:
>>
>>> On Wed, Sep 06, 2017 at 10:08:01PM +0200, David Edelsohn wrote:
This change broke bootstrap on AIX because sancov.c now references a
macro that is defined as a function on AIX. sancov.c n
On Thu, Sep 7, 2017 at 6:57 PM, Rainer Orth
wrote:
> Jakub Jelinek writes:
>
>> On Wed, Sep 06, 2017 at 10:08:01PM +0200, David Edelsohn wrote:
>>> This change broke bootstrap on AIX because sancov.c now references a
>>> macro that is defined as a function on AIX. sancov.c needs to include
>>>
Jakub Jelinek writes:
> On Wed, Sep 06, 2017 at 10:08:01PM +0200, David Edelsohn wrote:
>> This change broke bootstrap on AIX because sancov.c now references a
>> macro that is defined as a function on AIX. sancov.c needs to include
>> tm_p.h to pull in the target-dependent prototypes. The foll
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
On Wed, Sep 06, 2017 at 10:08:01PM +0200, David Edelsohn wrote:
> This change broke bootstrap on AIX because sancov.c now references a
> macro that is defined as a function on AIX. sancov.c needs to include
> tm_p.h to pull in the target-dependent prototypes. The following
> patch works for me.
This change broke bootstrap on AIX because sancov.c now references a
macro that is defined as a function on AIX. sancov.c needs to include
tm_p.h to pull in the target-dependent prototypes. The following
patch works for me. Is this okay?
* sancov.c: Include tm_p.h.
Index: sancov.c
On Wed, Sep 06, 2017 at 04:37:18PM +0200, Jakub Jelinek wrote:
> 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 l
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_tra
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 i
On Tue, Sep 05, 2017 at 09:03:52PM +0800, 吴潍浠(此彼) wrote:
> Attachment is my updated path.
> The implementation of parse_sanitizer_options is not elegance enough. Mixing
> handling flags of fsanitize is easy to make mistakes.
To avoid too many further iterations, I took the liberty to tweak your
p
Hi
Attachment is my updated path.
The implementation of parse_sanitizer_options is not elegance enough. Mixing
handling flags of fsanitize is easy to make mistakes.
ChangeLog:
gcc/ChangeLog:
2017-09-05 Wish Wu
* asan.c (initialize_sanitizer_builtins):
Build function type list
On Mon, Sep 04, 2017 at 09:36:40PM +0800, 吴潍浠(此彼) wrote:
> gcc/ChangeLog:
>
> 2017-09-04 Wish Wu
>
> * asan.c (initialize_sanitizer_builtins):
> * builtin-types.def (BT_FN_VOID_UINT8
Sorry. I made a terrible bug in it.
Attachment is my new patch.
Wish Wu
--
From:Wish Wu
Time:2017 Sep 4 (Mon) 21:17
To:Dmitry Vyukov ; Jakub Jelinek
Cc:gcc ; gcc-patches ; Jeff Law
; wishwu007
Subject:Re: Add support to trace com
Hi
I updated the patch and put it in attachment.
gcc/ChangeLog:
2017-09-04 Wish Wu
* asan.c (initialize_sanitizer_builtins):
* builtin-types.def (BT_FN_VOID_UINT8_UINT8):
On Sun, Sep 3, 2017 at 12:38 PM, 吴潍浠(此彼) wrote:
> Hi
> I will update the patch according to your requirements, and with some my
> suggestions.
> It will take me one or two days.
Thanks! No hurry, just wanted to make sure you still want to pursue this.
> Wish Wu
>
> -
Hi
I will update the patch according to your requirements, and with some my
suggestions.
It will take me one or two days.
Wish Wu
--
From:Dmitry Vyukov
Time:2017 Sep 3 (Sun) 18:21
To:Jakub Jelinek
Cc:Wish Wu ; gcc ; gcc-patches
;
On Sun, Sep 3, 2017 at 12:19 PM, Dmitry Vyukov wrote:
> On Sun, Sep 3, 2017 at 12:01 PM, Jakub Jelinek wrote:
>> On Sun, Sep 03, 2017 at 10:50:16AM +0200, Dmitry Vyukov wrote:
>>> What we instrument in LLVM is _comparisons_ rather than control
>>> structures. So that would be:
>>> _4 = x_8(D)
On Sun, Sep 3, 2017 at 12:01 PM, Jakub Jelinek wrote:
> On Sun, Sep 03, 2017 at 10:50:16AM +0200, Dmitry Vyukov wrote:
>> What we instrument in LLVM is _comparisons_ rather than control
>> structures. So that would be:
>> _4 = x_8(D) == 98;
>> For example, result of the comparison can be store
On Sun, Sep 03, 2017 at 10:50:16AM +0200, Dmitry Vyukov wrote:
> What we instrument in LLVM is _comparisons_ rather than control
> structures. So that would be:
> _4 = x_8(D) == 98;
> For example, result of the comparison can be stored into a bool struct
> field, and then used in branching long
On Fri, Sep 1, 2017 at 6:23 PM, Jakub Jelinek wrote:
> On Fri, Jul 21, 2017 at 01:38:17PM +0800, 吴潍浠(此彼) wrote:
>> Hi Jeff
>>
>> I have signed the copyright assignment, and used the name 'Wish Wu' .
>> Should I send you a copy of my assignment ?
>>
>> The attachment is my new patch with small chan
On Fri, Jul 21, 2017 at 01:38:17PM +0800, 吴潍浠(此彼) wrote:
> Hi Jeff
>
> I have signed the copyright assignment, and used the name 'Wish Wu' .
> Should I send you a copy of my assignment ?
>
> The attachment is my new patch with small changes.
> Codes are checked by ./contrib/check_GNU_style.sh, e
On Sat, Aug 5, 2017 at 11:53 AM, 吴潍浠(此彼) wrote:
> Hi all
> Is it worth adding my codes to gcc ? Are there some steps I need to do ?
> Could somebody tell me the progress ?
FYI, we've mailed a Linux kernel change that uses this instrumentation:
https://groups.google.com/forum/#!topic/syzkaller/r0
Hi all
Is it worth adding my codes to gcc ? Are there some steps I need to do ?
Could somebody tell me the progress ?
Maybe there should be a project like libfuzzer to solve bugs in program.
Wish Wu
--
From:Wish Wu
Time:2017 Jul 21
On Fri, Jul 21, 2017 at 1:38 AM, 吴潍浠(此彼) wrote:
> Hi Jeff
>
> I have signed the copyright assignment, and used the name 'Wish Wu' .
> Should I send you a copy of my assignment ?
Your assignment now is on file in the FSF Copyright Assignment list
where Jeff, I and other maintainers can see it. We
Hi Jeff
I have signed the copyright assignment, and used the name 'Wish Wu' .
Should I send you a copy of my assignment ?
The attachment is my new patch with small changes.
Codes are checked by ./contrib/check_GNU_style.sh, except some special files.
With
--
On Sat, Jul 15, 2017 at 9:21 AM, 吴潍浠(此彼) wrote:
> Hi
>
> Implementing __sanitizer_cov_trace_cmp[1248]_const is OK .
> And I will try to find some determinate way to judge this comparison is for
> loop or not.
> Because all the loops(for() or while()) seem to be transformed to "if" and
> "goto" b
Hi
Implementing __sanitizer_cov_trace_cmp[1248]_const is OK .
And I will try to find some determinate way to judge this comparison is for
loop or not.
Because all the loops(for() or while()) seem to be transformed to "if" and
"goto" before running sancov pass.
Does it necessary to include APIs
On Fri, Jul 14, 2017 at 11:17 PM, Kostya Serebryany wrote:
> Hi
>
> I wrote a test for "-fsanitize-coverage=trace-cmp" .
>
> Is there anybody tells me if these codes could be merged into gcc ?
Nice!
We are currently working on Linux kernel fuzzing
On Fri, Jul 14, 2017 at 5:23 AM, Dmitry Vyukov wrote:
> On Thu, Jul 13, 2017 at 11:18 PM, Kostya Serebryany wrote:
>>> > Hi
>>> >
>>> > I wrote a test for "-fsanitize-coverage=trace-cmp" .
>>> >
>>> > Is there anybody tells me if these codes could be merged into gcc ?
>>>
>>>
>>> Nice!
>>>
>>> We
On Thu, Jul 13, 2017 at 11:18 PM, Kostya Serebryany wrote:
>> > Hi
>> >
>> > I wrote a test for "-fsanitize-coverage=trace-cmp" .
>> >
>> > Is there anybody tells me if these codes could be merged into gcc ?
>>
>>
>> Nice!
>>
>> We are currently working on Linux kernel fuzzing that use the
>> comp
On 07/10/2017 06:07 AM, 吴潍浠(此彼) wrote:
> Hi
>
> I write some codes to make gcc support comparison-guided fuzzing.
> It is very like
> http://clang.llvm.org/docs/SanitizerCoverage.html#tracing-data-flow .
> With -fsanitize-coverage=trace-cmp the compiler will insert extra
> instrumentation around
On Thu, Jul 13, 2017 at 12:41 PM, Wish Wu wrote:
> Hi
>
> In fact, under linux with "return address" and file "/proc/self/maps",
> we can give unique id for every comparison.
Yes, it's doable. But you expressed worries about performance hit of
merging callbacks for different sizes. Mapping pc + i
Hi
In fact, under linux with "return address" and file "/proc/self/maps",
we can give unique id for every comparison.
For fuzzing, we may give 3 bits for every comparison as marker of if
"<", "==" or ">" is showed. :D
With Regards
Wish Wu of Ant-financial Light-Year Security Lab
On Thu, Jul 13,
Hi
In my perspective:
1. Do we need to assign unique id for every comparison ?
Yes, I suggest to implement it like -fsanitize-coverage=trace-pc-guard .
Because some fuzzing targets may invoke dlopen() like functions to
load libraries(modules) after fork(), while these libraries are
compil
On Tue, Jul 11, 2017 at 1:59 PM, Wish Wu wrote:
> Hi
>
> I wrote a test for "-fsanitize-coverage=trace-cmp" .
>
> Is there anybody tells me if these codes could be merged into gcc ?
Nice!
We are currently working on Linux kernel fuzzing that use the
comparison tracing. We use clang at the momen
Hi
I wrote a test for "-fsanitize-coverage=trace-cmp" .
Is there anybody tells me if these codes could be merged into gcc ?
Index: gcc/testsuite/gcc.dg/sancov/basic3.c
===
--- gcc/testsuite/gcc.dg/sancov/basic3.c (nonexistent)
+++ g
42 matches
Mail list logo
