This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: libsanitizer merge from upstream r208536


On 05/22/2014 11:54 PM, Jakub Jelinek wrote:
> Kostya, guess you should ignore the vDSO.

Right, we didn't encounter this problem when testing on our kernels. I'll cook a patch for this.

> much better would be just dlsym a couple of
> interesting symbols to verify that libasan.so.1 is ahead
> of libc.so.6, libstdc++.so.6, libpthread.so.0 (whatever else
> you want to override).

One problem with dlsym() that I've seen is that it causes a call to malloc on failure (to allocate buffer for dlerror()) which forces allocator initialization and breaks Asan's delayed initialization feature.

Also on Linux dlsym() tends to return address of executable's PLT entry which is useless.

> Otherwise libasan apps will simply stop
> working altogether if LD_PRELOAD is set, to whatever library,
> even if it doesn't define any symbols you care about.

Right but I'm not sure whether failing fast here is necessarily bad.
Imagine preloaded library has an initializer which calls intercepted APIs. Asan didn't get a chance to initialize at the point of call and if interceptor doesn't contain a sanity call to asan_init,
we are risking hard-to-debug runtime error (call to NULL, etc.).
I've seen numerous bugs like this (both locally and on mailing lists) and they were main motivation to add this check.

Note that user can just prepend libasan to LD_PRELOAD list
to overcome this error.

We could remove the Die() but still leave the warning there
so that user is aware of possible consequences of using unconstrained LD_PRELOAD with Asan.

> Typically people in LD_PRELOAD override malloc (which we want to diagnose),
> or far more rarely stringops (e.g. memstomp, also undesirable).

I wonder whether overriding Asan's malloc, etc. is expected to work at all? Perhaps banning it altogether is just the safest thing to do?

-Y


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]