AddressSanitizer and issue suppression

[Kuba Brecka]

Hi,

I'm trying to explore the possibilities of extending ASan to be able to continue execution after an error is found and a report printed out. I understand that the fact that ASan is currently aborting/exiting on a report is totally intentional and that there are some good reasons for it, e.g. that it's not safe to continue because the memory is corrupted, or that the UnreachableInst/doesNotReturn play an important role for optimizations.

However, I believe that there may be some valid reasons to allow continuing program execution, like when there's a bug in a system library. This can easily happen even when this library itself is not instrumented, due to wrappers/interceptors affecting system libraries as well. So doing something like...

a = malloc(15);

memset(a, 0, 16);

...in a system library would get caught by ASan, and it's definitely a bug. On the other hand, in this specific case, without ASan, this alone would (almost certainly) never crash or cause *real* memory corruption, since malloc allocates 16 bytes anyway. We want to learn about the bug (to be able to fix it), but I think we also want to be able to continue using ASan before a new version of the library is shipped with an OS update.

I am mainly interested in wrappers/interceptors only, because the reports invoked by instrumentation cannot happen in a library function (since it's not instrumented) and if a bug in a library triggers a report to be produced in user's instrumented code, he can blacklist that function or use __attribute__((no_sanitize_address)). It seems to me it should be possible to modify the error reporting (in the wrappers only) not to be fatal, and if that decision whether to abort or not (let's say via a suppression list) is done only in the case when a poisoned memory access is detected, it shouldn't have any significant performance hit.

I noticed that there is an issue suppression mechanism in ThreadSanitizer and I'm aware that the circumstances for this feature in TSan are different. However, I'd still like to discuss the possibilities and opinions on this topic.

Thank you for any feedback!

Kuba

[Dmitry Vyukov]

+tetra2005

> --
> 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.

[Konstantin Serebryany]

We probably can reuse lib/sanitizer_common/sanitizer_suppressions.h to
suppress errors that come from the interceptors...
Thoughts?

[Alexey Samsonov]

I haven't looked at the code in a while, but this should be possible. We already have a global suppression context in sanitizer_common.

Alexey Samsonov, Mountain View, CA

[Alexander Potapenko]

Some time ago I've been thinking about adding a flag for each
interceptor that disables checks in that interceptor similar to
replace_intrin flag.
Using suppressions for that sounds more flexible, but we must make
sure the users do not try to suppress errors in instrumented code.
(For example we could print a warning about that when a suppression
matches the report that didn't originate from an interceptor)

Alexander Potapenko
Software Engineer
Google Moscow

[Konstantin Serebryany]

On Thu, Sep 25, 2014 at 2:16 AM, 'Alexander Potapenko' via
address-sanitizer <address-...@googlegroups.com> wrote:
> Some time ago I've been thinking about adding a flag for each
> interceptor that disables checks in that interceptor similar to
> replace_intrin flag.
> Using suppressions for that sounds more flexible, but we must make
> sure the users do not try to suppress errors in instrumented code.

Correct.

> (For example we could print a warning about that when a suppression
> matches the report that didn't originate from an interceptor)

SGTM

[Alexey Samsonov]

Can you add a new suppression kind that would disable certain interceptors?

E.g. the following line in suppressions file:

interceptor:strcasecmp

will disable the checks in this interceptor (in case of ASan it would turn COMMON_INTERCEPTOR_READ_RANGE to nop).

  

[Konstantin Serebryany]

I don't think this is what we want.
I'd rather suppress by one of the frames in the stack where strcasecmp is called
(This may, of course, be the #0 frame with strcasecmp)

On Thu, Sep 25, 2014 at 6:17 PM, 'Alexey Samsonov' via

[Alexey Samsonov]

On Thu, Sep 25, 2014 at 9:46 PM, Konstantin Serebryany <konstantin....@gmail.com> wrote:

I don't think this is what we want.
I'd rather suppress by one of the frames in the stack where strcasecmp is called
(This may, of course, be the #0 frame with strcasecmp)

Sure. But it would be great to be able to disable interceptors in ASan while still keeping __asan_report_error  noreturn.

[Alexander Potapenko]

We just need a separate error reporting function that'll be called exclusively from interceptors. It doesn't have to be noreturn, because the interceptors themselves aren't.

[Konstantin Serebryany]

On Fri, Sep 26, 2014 at 12:26 AM, Alexander Potapenko
<ramosia...@gmail.com> wrote:
> We just need a separate error reporting function that'll be called
> exclusively from interceptors. It doesn't have to be noreturn, because the
> interceptors themselves aren't.

yep

[Alexey Samsonov]

On Fri, Sep 26, 2014 at 12:26 AM, Alexander Potapenko <ramosia...@gmail.com> wrote:

We just need a separate error reporting function that'll be called exclusively from interceptors. It doesn't have to be noreturn, because the interceptors themselves aren't.

Sure. The relevant parts are ACCESS_MEMORY_RANGE and CHECK_RANGES_OVERLAP macro in asan_interceptors.cc

[tetra...@gmail.com]

On Fri, Sep 26, 2014 at 12:26 AM, Alexander Potapenko <ramosia...@gmail.com> wrote:

We just need a separate error reporting function that'll be called exclusively from interceptors. It doesn't have to be noreturn, because the interceptors themselves aren't.

Sounds like a match for __asan_report_*_noabort (which are available in GCC but not yet in Clang).