Re: Stack oob not detected with -O2
I don't think there's a bug to fix here: undef is designed to support
optimizations, not catch bugs.
Also, while it is the case that any time an undef executes, you've done
something undefined, the opposite is not the case: there are going to be
plenty of cases where UBs are silently suppressed by the optimizer without
generating the explicit undef.
On Tue, Jan 19, 2016 at 11:36 PM, Konstantin Serebryany <
konstantin.s.serebry...@gmail.com> wrote:
> In LLVM this will also be non-trivial,
> but I expect it to be counter-productive because asan will inhibit many
> optimizations.
> Easier to just run with -O0 periodically. I know this is actually not easy
> at all. :(
>
> What we can and should do is to teach llvm to emit a proper trap.
>
> Consider my example:
>
> int bar() { return 3; }
> int foo() {
> int x[3] = {1, 2, 3};
> return x[bar()];
> }
>
>
> % clang -c -O2 sbo.cc -emit-llvm -o - -S
> define i32 @_Z3foov() #0 {
> entry:
> ret i32 undef
> }
>
>
> Here, if you use -O2, the compiler will optimize the illegal code into ret
> i32 undef,
> but it will not crash, sadly. Maybe it should.
>
> Same thing in your example:
> %call = tail call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([4
> x i8], [4 x i8]* @.str, i64 0, i64 0), i32 undef)
>
>
> I'd suggest you to either start a discussion at llvm-dev or file a LLVM
> bug.
>
> BTW, -fsanitize=bounds will catch these bugs.
>
> --kcc
>
>
> On Sun, Jan 17, 2016 at 3:24 AM, Yuri Gribov wrote:
>
>> On Sun, Jan 17, 2016 at 11:56 AM, John Regehr
>> wrote:
>> > Would it be possible to add an option specifying that the asan
>> > instrumentation is done before running any optimizers? Presumably this
>> would
>> > offer an interesting tradeoff where there transparent bugs aren't
>> missed but
>> > performance is still much better than -O0.
>>
>> This isn't so easy with GCC which tends to start "optimizing" code
>> long before GIMPLE. AFAIR in my case erroneous memory access was
>> removed during parsing.
>>
>> > On Friday, January 15, 2016 at 5:58:36 PM UTC+1, kcc wrote:
>> >>
>> >> +john
>> >>
>> >> Yea, if optimizations get rid of the buggy code before asan gets a
>> chance
>> >> to instrument it -- the bug will be missed.
>> >> We've seen it before in many *trivial* examples.
>> >> It's unclear how many bugs we miss this way; some for sure.
>> >>
>> >> On Fri, Jan 15, 2016 at 8:51 AM, Hanno Böck wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>> I just saw this tweet by John Regehr:
>> >>> https://twitter.com/johnregehr/status/688033344580399104
>> >>>
>> >>> He found a code example with a pretty obvious out of bounds stack read
>> >>> that asan doesn't catch with -O or -O2 (equivalent). I checked this
>> >>> with both current gcc and clang.
>> >>>
>> >>> This is a stripped down example:
>> >>> int main() {
>> >>> int b[1] = {0};
>> >>> int a=-1;
>> >>> printf("%i\n", b[a]);
>> >>> }
>> >>>
>> >>>
>> >>> I am a bit surprised, because this looks like a poster child example
>> of
>> >>> the kind of bug asan can find. But somehow the optimization
>> >>> seems to break the asan check here.
>> >>>
>> >>> I now wonder how many bugs keep being hidden because of this, as -O2
>> is
>> >>> a pretty common default setting for compilations.
>> >>>
>> >>>
>> >>> --
>> >>> Hanno Böck
>> >>> http://hboeck.de/
>> >>>
>> >>> mail/jabber: ha...@hboeck.de
>> >>> GPG: BBB51E42
>> >>>
>> >>> --
>> >>> You received this message because you are subscribed to the Google
>> Groups
>> >>> "address-sanitizer" group.
>> >>> To unsubscribe from this group and stop receiving emails from it,
>> send an
>> >>> email to address-saniti...@googlegroups.com.
>> >>> For more options, visit https://groups.google.com/d/optout.
>> >>
>> >>
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups
>> > "address-sanitizer" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an
>> > email to address-sanitizer+unsubscr...@googlegroups.com.
>> > For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "address-sanitizer" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to address-sanitizer+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
--
You received this message because you are subscribed to the Google Groups
"address-sanitizer" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to address-sanitizer+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Stack oob not detected with -O2
In LLVM this will also be non-trivial,
but I expect it to be counter-productive because asan will inhibit many
optimizations.
Easier to just run with -O0 periodically. I know this is actually not easy
at all. :(
What we can and should do is to teach llvm to emit a proper trap.
Consider my example:
int bar() { return 3; }
int foo() {
int x[3] = {1, 2, 3};
return x[bar()];
}
% clang -c -O2 sbo.cc -emit-llvm -o - -S
define i32 @_Z3foov() #0 {
entry:
ret i32 undef
}
Here, if you use -O2, the compiler will optimize the illegal code into ret
i32 undef,
but it will not crash, sadly. Maybe it should.
Same thing in your example:
%call = tail call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([4 x
i8], [4 x i8]* @.str, i64 0, i64 0), i32 undef)
I'd suggest you to either start a discussion at llvm-dev or file a LLVM
bug.
BTW, -fsanitize=bounds will catch these bugs.
--kcc
On Sun, Jan 17, 2016 at 3:24 AM, Yuri Gribov wrote:
> On Sun, Jan 17, 2016 at 11:56 AM, John Regehr
> wrote:
> > Would it be possible to add an option specifying that the asan
> > instrumentation is done before running any optimizers? Presumably this
> would
> > offer an interesting tradeoff where there transparent bugs aren't missed
> but
> > performance is still much better than -O0.
>
> This isn't so easy with GCC which tends to start "optimizing" code
> long before GIMPLE. AFAIR in my case erroneous memory access was
> removed during parsing.
>
> > On Friday, January 15, 2016 at 5:58:36 PM UTC+1, kcc wrote:
> >>
> >> +john
> >>
> >> Yea, if optimizations get rid of the buggy code before asan gets a
> chance
> >> to instrument it -- the bug will be missed.
> >> We've seen it before in many *trivial* examples.
> >> It's unclear how many bugs we miss this way; some for sure.
> >>
> >> On Fri, Jan 15, 2016 at 8:51 AM, Hanno Böck wrote:
> >>>
> >>> Hi,
> >>>
> >>> I just saw this tweet by John Regehr:
> >>> https://twitter.com/johnregehr/status/688033344580399104
> >>>
> >>> He found a code example with a pretty obvious out of bounds stack read
> >>> that asan doesn't catch with -O or -O2 (equivalent). I checked this
> >>> with both current gcc and clang.
> >>>
> >>> This is a stripped down example:
> >>> int main() {
> >>> int b[1] = {0};
> >>> int a=-1;
> >>> printf("%i\n", b[a]);
> >>> }
> >>>
> >>>
> >>> I am a bit surprised, because this looks like a poster child example of
> >>> the kind of bug asan can find. But somehow the optimization
> >>> seems to break the asan check here.
> >>>
> >>> I now wonder how many bugs keep being hidden because of this, as -O2 is
> >>> a pretty common default setting for compilations.
> >>>
> >>>
> >>> --
> >>> Hanno Böck
> >>> http://hboeck.de/
> >>>
> >>> mail/jabber: ha...@hboeck.de
> >>> GPG: BBB51E42
> >>>
> >>> --
> >>> You received this message because you are subscribed to the Google
> Groups
> >>> "address-sanitizer" group.
> >>> To unsubscribe from this group and stop receiving emails from it, send
> an
> >>> email to address-saniti...@googlegroups.com.
> >>> For more options, visit https://groups.google.com/d/optout.
> >>
> >>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "address-sanitizer" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to address-sanitizer+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "address-sanitizer" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to address-sanitizer+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"address-sanitizer" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to address-sanitizer+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Stack oob not detected with -O2
On Sun, Jan 17, 2016 at 11:56 AM, John Regehr wrote:
> Would it be possible to add an option specifying that the asan
> instrumentation is done before running any optimizers? Presumably this would
> offer an interesting tradeoff where there transparent bugs aren't missed but
> performance is still much better than -O0.
This isn't so easy with GCC which tends to start "optimizing" code
long before GIMPLE. AFAIR in my case erroneous memory access was
removed during parsing.
> On Friday, January 15, 2016 at 5:58:36 PM UTC+1, kcc wrote:
>>
>> +john
>>
>> Yea, if optimizations get rid of the buggy code before asan gets a chance
>> to instrument it -- the bug will be missed.
>> We've seen it before in many *trivial* examples.
>> It's unclear how many bugs we miss this way; some for sure.
>>
>> On Fri, Jan 15, 2016 at 8:51 AM, Hanno Böck wrote:
>>>
>>> Hi,
>>>
>>> I just saw this tweet by John Regehr:
>>> https://twitter.com/johnregehr/status/688033344580399104
>>>
>>> He found a code example with a pretty obvious out of bounds stack read
>>> that asan doesn't catch with -O or -O2 (equivalent). I checked this
>>> with both current gcc and clang.
>>>
>>> This is a stripped down example:
>>> int main() {
>>> int b[1] = {0};
>>> int a=-1;
>>> printf("%i\n", b[a]);
>>> }
>>>
>>>
>>> I am a bit surprised, because this looks like a poster child example of
>>> the kind of bug asan can find. But somehow the optimization
>>> seems to break the asan check here.
>>>
>>> I now wonder how many bugs keep being hidden because of this, as -O2 is
>>> a pretty common default setting for compilations.
>>>
>>>
>>> --
>>> Hanno Böck
>>> http://hboeck.de/
>>>
>>> mail/jabber: ha...@hboeck.de
>>> GPG: BBB51E42
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "address-sanitizer" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to address-saniti...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>
>>
> --
> You received this message because you are subscribed to the Google Groups
> "address-sanitizer" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to address-sanitizer+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"address-sanitizer" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to address-sanitizer+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Stack oob not detected with -O2
Would it be possible to add an option specifying that the asan
instrumentation is done before running any optimizers? Presumably this
would offer an interesting tradeoff where there transparent bugs aren't
missed but performance is still much better than -O0.
On Friday, January 15, 2016 at 5:58:36 PM UTC+1, kcc wrote:
>
> +john
>
> Yea, if optimizations get rid of the buggy code before asan gets a chance
> to instrument it -- the bug will be missed.
> We've seen it before in many *trivial* examples.
> It's unclear how many bugs we miss this way; some for sure.
>
> On Fri, Jan 15, 2016 at 8:51 AM, Hanno Böck
> > wrote:
>
>> Hi,
>>
>> I just saw this tweet by John Regehr:
>> https://twitter.com/johnregehr/status/688033344580399104
>>
>> He found a code example with a pretty obvious out of bounds stack read
>> that asan doesn't catch with -O or -O2 (equivalent). I checked this
>> with both current gcc and clang.
>>
>> This is a stripped down example:
>> int main() {
>> int b[1] = {0};
>> int a=-1;
>> printf("%i\n", b[a]);
>> }
>>
>>
>> I am a bit surprised, because this looks like a poster child example of
>> the kind of bug asan can find. But somehow the optimization
>> seems to break the asan check here.
>>
>> I now wonder how many bugs keep being hidden because of this, as -O2 is
>> a pretty common default setting for compilations.
>>
>>
>> --
>> Hanno Böck
>> http://hboeck.de/
>>
>> mail/jabber: ha...@hboeck.de
>> GPG: BBB51E42
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "address-sanitizer" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to address-saniti...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
--
You received this message because you are subscribed to the Google Groups
"address-sanitizer" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to address-sanitizer+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Stack oob not detected with -O2
It's in ASan FAQ btw.
On Fri, Jan 15, 2016 at 7:58 PM, Konstantin Serebryany
wrote:
> +john
>
> Yea, if optimizations get rid of the buggy code before asan gets a chance to
> instrument it -- the bug will be missed.
> We've seen it before in many *trivial* examples.
> It's unclear how many bugs we miss this way; some for sure.
>
> On Fri, Jan 15, 2016 at 8:51 AM, Hanno Böck wrote:
>>
>> Hi,
>>
>> I just saw this tweet by John Regehr:
>> https://twitter.com/johnregehr/status/688033344580399104
>>
>> He found a code example with a pretty obvious out of bounds stack read
>> that asan doesn't catch with -O or -O2 (equivalent). I checked this
>> with both current gcc and clang.
>>
>> This is a stripped down example:
>> int main() {
>> int b[1] = {0};
>> int a=-1;
>> printf("%i\n", b[a]);
>> }
>>
>>
>> I am a bit surprised, because this looks like a poster child example of
>> the kind of bug asan can find. But somehow the optimization
>> seems to break the asan check here.
>>
>> I now wonder how many bugs keep being hidden because of this, as -O2 is
>> a pretty common default setting for compilations.
>>
>>
>> --
>> Hanno Böck
>> http://hboeck.de/
>>
>> mail/jabber: ha...@hboeck.de
>> GPG: BBB51E42
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "address-sanitizer" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to address-sanitizer+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "address-sanitizer" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to address-sanitizer+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"address-sanitizer" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to address-sanitizer+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Stack oob not detected with -O2
+john
Yea, if optimizations get rid of the buggy code before asan gets a chance
to instrument it -- the bug will be missed.
We've seen it before in many *trivial* examples.
It's unclear how many bugs we miss this way; some for sure.
On Fri, Jan 15, 2016 at 8:51 AM, Hanno Böck wrote:
> Hi,
>
> I just saw this tweet by John Regehr:
> https://twitter.com/johnregehr/status/688033344580399104
>
> He found a code example with a pretty obvious out of bounds stack read
> that asan doesn't catch with -O or -O2 (equivalent). I checked this
> with both current gcc and clang.
>
> This is a stripped down example:
> int main() {
> int b[1] = {0};
> int a=-1;
> printf("%i\n", b[a]);
> }
>
>
> I am a bit surprised, because this looks like a poster child example of
> the kind of bug asan can find. But somehow the optimization
> seems to break the asan check here.
>
> I now wonder how many bugs keep being hidden because of this, as -O2 is
> a pretty common default setting for compilations.
>
>
> --
> Hanno Böck
> http://hboeck.de/
>
> mail/jabber: ha...@hboeck.de
> GPG: BBB51E42
>
> --
> You received this message because you are subscribed to the Google Groups
> "address-sanitizer" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to address-sanitizer+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"address-sanitizer" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to address-sanitizer+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
