On Fri, Sep 26, 2014 at 12:26 AM, Alexander Potapenko < [email protected]> 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 > On Sep 26, 2014 8:52 AM, "'Alexey Samsonov' via address-sanitizer" < > [email protected]> wrote: > >> >> On Thu, Sep 25, 2014 at 9:46 PM, Konstantin Serebryany < >> [email protected]> 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. >> >> >>> >>> On Thu, Sep 25, 2014 at 6:17 PM, 'Alexey Samsonov' via >>> address-sanitizer <[email protected]> wrote: >>> > 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). >>> > >>> > >>> > On Thu, Sep 25, 2014 at 4:49 PM, Konstantin Serebryany >>> > <[email protected]> wrote: >>> >> >>> >> On Thu, Sep 25, 2014 at 2:16 AM, 'Alexander Potapenko' via >>> >> address-sanitizer <[email protected]> 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 >>> >> >>> >> > >>> >> > On Thu, Sep 25, 2014 at 4:08 AM, 'Alexey Samsonov' via >>> >> > address-sanitizer <[email protected]> wrote: >>> >> >> 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. >>> >> >> >>> >> >> On Wed, Sep 24, 2014 at 4:47 PM, Konstantin Serebryany >>> >> >> <[email protected]> wrote: >>> >> >>> >>> >> >>> We probably can reuse >>> lib/sanitizer_common/sanitizer_suppressions.h to >>> >> >>> suppress errors that come from the interceptors... >>> >> >>> Thoughts? >>> >> >>> >>> >> >>> On Wed, Sep 24, 2014 at 4:39 PM, 'Dmitry Vyukov' via >>> address-sanitizer >>> >> >>> <[email protected]> wrote: >>> >> >>> > +tetra2005 >>> >> >>> > >>> >> >>> > >>> >> >>> > On Wed, Sep 24, 2014 at 4:31 PM, Kuba Brecka < >>> [email protected]> >>> >> >>> > wrote: >>> >> >>> >> 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 >>> >> >>> >> >>> >> >>> >> -- >>> >> >>> >> 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 [email protected]. >>> >> >>> >> 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 [email protected]. >>> >> >>> > 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 [email protected]. >>> >> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> -- >>> >> >> Alexey Samsonov, Mountain View, CA >>> >> >> >>> >> >> -- >>> >> >> 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 [email protected]. >>> >> >> For more options, visit https://groups.google.com/d/optout. >>> >> > >>> >> > >>> >> > >>> >> > -- >>> >> > Alexander Potapenko >>> >> > Software Engineer >>> >> > Google Moscow >>> >> > >>> >> > -- >>> >> > 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 [email protected]. >>> >> > 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 [email protected]. >>> >> For more options, visit https://groups.google.com/d/optout. >>> > >>> > >>> > >>> > >>> > -- >>> > Alexey Samsonov, Mountain View, CA >>> > >>> > -- >>> > 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 [email protected]. >>> > 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 [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> -- >> Alexey Samsonov, Mountain View, CA >> >> -- >> 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 [email protected]. >> 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 [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- Alexey Samsonov, Mountain View, CA -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
