[Bug sanitizer/58937] New: Preloaded libasan segfaults on unsanitized executables

[Bug sanitizer/58937] New: Preloaded libasan segfaults on unsanitized executables

[y.gribov at samsung dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58937

            Bug ID: 58937
           Summary: Preloaded libasan segfaults on unsanitized executables
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: sanitizer
          Assignee: unassigned at gcc dot gnu.org
          Reporter: y.gribov at samsung dot com
                CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
                    e.gavrin at samsung dot com, jakub at gcc dot gnu.org,
                    kcc at gcc dot gnu.org

My system has a mix of sanitized and unsanitized executables and libs calling
each other in a complex manner. I've recently tried doing a global
LD_PRELOAD=libasan to make sure I don't have problems with initialization order
outlined in #56393.

I quickly ran into a problem which is reproduced in the attach. Here is the gdb
session log:
 $ /home/ygribov/install/gcc-master/bin/gcc -g main.i
 $ ./a.out
 $ LD_PRELOAD=~/install/gcc-master/lib64/libasan.so.0 ./a.out 
 Segmentation fault (core dumped)
 $ gdb a.out
 (gdb) set env LD_PRELOAD /home/ygribov/install/gcc-master/lib64/libasan.so.0
 (gdb) b __asan_init_v1
 (gdb) run
 Program received signal SIGSEGV, Segmentation fault.
 0x0000000000000000 in ?? ()
 (gdb) bt
 #0  0x0000000000000000 in ?? ()
 #1  0x00007ffff4e4fa62 in signal () at
/home/ygribov/gcc/gcc-master/libsanitizer/asan/asan_interceptors.cc:133
 #2  0x000000000040052c in main ()
 (gdb) fr 1
 #1  0x00007ffff4e4fa62 in signal () at
/home/ygribov/gcc/gcc-master/libsanitizer/asan/asan_interceptors.cc:133
 133        return REAL(signal)(signum, handler);
 (gdb) l
 128    #endif  // ASAN_INTERCEPT_PTHREAD_CREATE
 129    
 130    #if ASAN_INTERCEPT_SIGNAL_AND_SIGACTION
 131    INTERCEPTOR(void*, signal, int signum, void *handler) {
 132      if (!AsanInterceptsSignal(signum)) {
 133        return REAL(signal)(signum, handler);
 134      }
 135      return 0;
 136    }
 137    

It seems that current libasan currently relies on sanitized code to call
__asan_init. If we preload it into an unsanitized executable, it will remain
uninitialized and will segfault on every REAL(whatever) call.

IMHO ability to do global LD_PRELOAD for all executables in the system is
rather useful so I think it makes sense to support this usage scenario. What
about adding a ctor to call __asan_init in libasan itself?

Note that this error should repro in Clang (on platforms that use dynamic
linking).

-Y

[Bug sanitizer/58937] Preloaded libasan segfaults on unsanitized executables

[y.gribov at samsung dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58937

--- Comment #1 from Yury Gribov <y.gribov at samsung dot com> ---
Created attachment 31118
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31118&action=edit
Draft patch

Here is a draft patch implementing my proposal.

[Bug sanitizer/58937] Preloaded libasan segfaults on unsanitized executables

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58937

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Why don't you add __attribute__((constructor)) to __asan_init instead?

[Bug sanitizer/58937] Preloaded libasan segfaults on unsanitized executables

[y.gribov at samsung dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58937

Yury Gribov <y.gribov at samsung dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #31118|0                           |1
        is obsolete|                            |

--- Comment #3 from Yury Gribov <y.gribov at samsung dot com> ---
Created attachment 31120
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31120&action=edit
Better patch

(In reply to Jakub Jelinek from comment #2)
> Why don't you add __attribute__((constructor)) to __asan_init instead?

Point taken, patch updaten.

[Bug sanitizer/58937] Preloaded libasan segfaults on unsanitized executables

[y.gribov at samsung dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58937

Yury Gribov <y.gribov at samsung dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |samsonov at google dot com

--- Comment #4 from Yury Gribov <y.gribov at samsung dot com> ---
Added Alexey to maybe comment on making __asan_init a constructor.

[Bug sanitizer/58937] Preloaded libasan segfaults on unsanitized executables

[samsonov at google dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58937

Alexey Samsonov <samsonov at google dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |eugeni.stepanov at gmail dot com,
                   |                            |glider at google dot com

--- Comment #5 from Alexey Samsonov <samsonov at google dot com> ---
+eugenis,glider

Do we have any similar issues on systems where we use dynamic ASan runtime
ourselves (Mac and Android)?

[Bug sanitizer/58937] Preloaded libasan segfaults on unsanitized executables

[kcc at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58937

--- Comment #6 from Kostya Serebryany <kcc at gcc dot gnu.org> ---
adding attribute ctor to __asan_init is questionable
- windows has different syntax.
- running non-instrumented binary w/o calling __asan_init at startup is risky:
the binary may call memset/etc an touch shadow memory, which is not initialized
before __asan_init

[Bug sanitizer/58937] Preloaded libasan segfaults on unsanitized executables

[y.gribov at samsung dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58937

--- Comment #7 from Yury Gribov <y.gribov at samsung dot com> ---
(In reply to Kostya Serebryany from comment #6)
> adding attribute ctor to __asan_init is questionable
> - windows has different syntax.

We'll fix that (see the obsolete patch).

> - running non-instrumented binary w/o calling __asan_init at startup is
> risky: the binary may call memset/etc an touch shadow memory, which is not
> initialized before __asan_init

Sorry, I didn't understand. The proposal is to call __asan_init at startup so
that we don't have this problem.

[Bug sanitizer/58937] Preloaded libasan segfaults on unsanitized executables

[eugeni.stepanov at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58937

--- Comment #8 from Evgeniy Stepanov <eugeni.stepanov at gmail dot com> ---
I'm a little surprised we did not run into this on Android yet - we use the
same LD_PRELOAD scheme there. Are you linking libasan with libpthread? This
might go away as libpthread constructors call one of the ASan interceptors that
does ENSURE_ASAN_INITED(). Arguably, all interceptors should do it.

I think Kostya raises valid points, but still, adding attribute((constructor))
is reasonable.

[Bug sanitizer/58937] Preloaded libasan segfaults on unsanitized executables

[y.gribov at samsung dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58937

--- Comment #9 from Yury Gribov <y.gribov at samsung dot com> ---
Created attachment 31204
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31204&action=edit
Repro

Just occured to me that I forgot to attach a reprocase, so doing this now.

@Evegeniy: could you check whether this reproduces under Android/Darwin?

[Bug sanitizer/58937] Preloaded libasan segfaults on unsanitized executables

[eugeni.stepanov at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58937

--- Comment #10 from Evgeniy Stepanov <eugeni.stepanov at gmail dot com> ---
We don't intercept signal() on Android, because there is a friendly crash
handler installed by the OS, and we don't need to handle segv ourselves.

[Bug sanitizer/58937] Preloaded libasan segfaults on unsanitized executables

[y.gribov at samsung dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58937

--- Comment #11 from Yury Gribov <y.gribov at samsung dot com> ---
(In reply to Evgeniy Stepanov from comment #10)
> We don't intercept signal() on Android

This is just an implementation detail, this fails just as well:

 $ cat repro.c
 #include <stdio.h>
 #include <stdlib.h>
 #include <setjmp.h>

 int main() {
   jmp_buf env;

   int val = setjmp (env);
   if (val)
     exit (val);

   longjmp (env,101);

   return 0;
 }
 $ gcc -g repro.c
 $ LD_PRELOAD=/home/ygribov/install/gcc-master/lib64/libasan.so.0 ./a.out
 ==11784== Sanitizer CHECK failed:
/home/ygribov/gcc/gcc-master/libsanitizer/asan/asan_posix.cc:107
((tsd_key_inited)) != (0) (0, 0)

[Bug sanitizer/58937] Preloaded libasan segfaults on unsanitized executables

[y.gribov at samsung dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58937

--- Comment #12 from Yury Gribov <y.gribov at samsung dot com> ---
(In reply to Evgeniy Stepanov from comment #8)
> ... one of the ASan interceptors
> that does ENSURE_ASAN_INITED().
> Arguably, all interceptors should do it.

Can we force all interceptors to do this?

[Bug sanitizer/58937] Preloaded libasan segfaults on unsanitized executables

[eugeni.stepanov at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58937

--- Comment #13 from Evgeniy Stepanov <eugeni.stepanov at gmail dot com> ---
(In reply to Yury Gribov from comment #12)
> (In reply to Evgeniy Stepanov from comment #8)
> > ... one of the ASan interceptors
> > that does ENSURE_ASAN_INITED().
> > Arguably, all interceptors should do it.
> 
> Can we force all interceptors to do this?

I think it would be a good thing to do.
Some interceptors are special in that they are allowed during __asan_init (ex.
memmove). Something like COMMON_INTERCEPTOR_ENTER in asan_interceptors.cc could
probably be applied safely to all interceptors.

[Bug sanitizer/58937] Preloaded libasan segfaults on unsanitized executables

[y.gribov at samsung dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58937

--- Comment #14 from Yury Gribov <y.gribov at samsung dot com> ---
With recent decision to enable ASAN_FLEXIBLE_MAPPING_AND_OFFSET by default I
don't see how LD_PRELOAD is going to work at all. What's the reasoning behind
this change?

[Bug sanitizer/58937] Preloaded libasan segfaults on unsanitized executables

[y.gribov at samsung dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58937

--- Comment #16 from Yury Gribov <y.gribov at samsung dot com> ---
(In reply to Evgeniy Stepanov from comment #15)
> In fact, a recent change disabled ASAN_FLEXIBLE_MAPPING_AND_OFFSET and
> killed all supporting code. Or are you talking about a different change?

Sorry, I was looking at commit which introduced it in Jan 21 _2013_. It works.

[Bug sanitizer/58937] Preloaded libasan segfaults on unsanitized executables

[y.gribov at samsung dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58937

--- Comment #17 from Yury Gribov <y.gribov at samsung dot com> ---
This should be fully resolved once
https://github.com/llvm-mirror/compiler-rt/commit/d6535ea4c4d49078a93735b315b8518fb692a592
is merged into gcc trunk.

BTW it no longer reproduces on trunk because newer versions of libstdc++
silently call __asan_init from __cxa_atexit in some constructor:
 #1  0x00007ffff6f45a09 in __asan::InitializeAsanInterceptors() () at
/home/ygribov/src/gcc-master/libsanitizer/asan/asan_interceptors.cc:710
 #2  0x00007ffff6f5b71f in __asan_init_v3 () from
/home/ygribov/install/gcc-master/lib64/libasan.so
 #3  0x00007ffff6f24462 in __interceptor___cxa_atexit () at
/home/ygribov/src/gcc-master/libsanitizer/asan/asan_interceptors.cc:671
 #4  0x00007ffff62bfa32 in std::future_category() () at
/home/ygribov/src/gcc-master/libstdc++-v3/src/c++11/future.cc:63
 #5  0x00007ffff6265c79 in _GLOBAL__sub_I_compatibility_thread_c__0x.cc () at
/home/ygribov/src/gcc-master/libstdc++-v3/src/c++11/compatibility-thread-c++0x.cc:49
 #6  0x00007ffff7de9306 in call_init (l=<optimized out>, argc=1,
argv=0x7fffffffdeb8, env=0x7fffffffdec8) at dl-init.c:85
 #7  0x00007ffff7de93df in call_init (env=<optimized out>, argv=<optimized
out>, argc=<optimized out>, l=<optimized out>) at dl-init.c:52
 #8  _dl_init (main_map=0x7ffff7ffe2c8, argc=1, argv=0x7fffffffdeb8,
env=0x7fffffffdec8) at dl-init.c:134
 #9  0x00007ffff7ddb6ea in _dl_start_user () from /lib64/ld-linux-x86-64.so.2

[Bug sanitizer/58937] Preloaded libasan segfaults on unsanitized executables

[y.gribov at samsung dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58937

Yury Gribov <y.gribov at samsung dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED

--- Comment #18 from Yury Gribov <y.gribov at samsung dot com> ---
Fixed with last merge from LLVM.