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
