[PATCH] Optional support for dynamic Asan runtime

Yury Gribov tetra2005 at gmail.com
Fri Mar 28 01:48:03 PDT 2014



================
Comment at: lib/asan/asan_linux.cc:105
@@ +104,3 @@
+  if (dlsym(RTLD_DEFAULT, badsym)) {
+    Report("Your application is linked against "
+      "incompatible ASan runtimes.\n");
----------------
Alexey Samsonov wrote:
> Yury Gribov wrote:
> > Yury Gribov wrote:
> > > Alexey Samsonov wrote:
> > > > Consider running tools/clang/tools/clang-format/clang-format-diff.py on your patch.
> > > Ok, good to know.
> > Are you sure the tool is usable? I see some strange changes like
> > 
> > +extern "C" __attribute__((
> > +    no_sanitize_address)) // Malloc may be called from dlsym in __asan_init
> > +void *malloc(size_t size) {
> > 
> > and misplaced comments.
> Hm. If this happens with fresh clang-format in your PATH, feel free to disregard it then.
I'll try to get something from it but really noise ratio is just too high.

================
Comment at: lib/asan/asan_malloc_linux.cc:115
@@ +114,3 @@
+  if (!asan_inited)
+    return AsanPreinitAlloc(size);
+  if (AsanIsPreinitAllocated(ptr))
----------------
Yury Gribov wrote:
> Alexey Samsonov wrote:
> > Yury Gribov wrote:
> > > Alexey Samsonov wrote:
> > > > Yury Gribov wrote:
> > > > > Alexey Samsonov wrote:
> > > > > > This is just wrong. Is realloc() called before asan_inited or on PreinitAllocated pointers?
> > > > > AFAIR realloc() is called before asan_inited on PreinitAlloc-ated pointers (dlerror calls it to allocate string). So what's wrong exactly?
> > > > if realloc(ptr, new_size) != ptr, you have to copy the contents to the newly allocated buffer. It's so sad we need to appease dlerror() with hacks like this. Can you clarify why you need to call it in AsanCheckIncompatibleRT?
> > > > you have to copy the contents
> > > 
> > > Agreed, won't work in general case. Was enough for dlerror because I was ignoring them anyway.
> > > 
> > > > Can you clarify why you need to call it in AsanCheckIncompatibleRT?
> > > 
> > > I search for __asan_static via dlsym() and this fails and calls dlerror().
> > > 
> > > > It's so sad we need to appease dlerror() with hacks like this
> > > 
> > > It is. Unfortunately this seems to be the only reliable way to detect incompatible rts (which is super-important).
> > Can you search for ASan runtime (.so) in the contents of /proc/self/maps when initializing a static runtime? I think we can read it w/o calling malloc...
> > 
> > Or to add asan_runtime_type .bss global, and initialize it in __asan_init(). Set it to 1 if ASAN_DYNAMIC is set, and to 2 otherwise, and detect inconsistencies.
> > Can you search for ASan runtime (.so) in the contents of /proc/self/maps
> 
> No, this won't protect from dlopening dynamic rt.
> 
> > Or to add asan_runtime_type .bss global
> 
> Yup, this might work. I'll see how it goes tomorrow.
>> Or to add asan_runtime_type .bss global
> Yup, this might work. I'll see how it goes tomorrow.

Ok, now I remember. We will get segfault instead of proper error message if we try to preload dynamic rt to statically sanitized executable. Here is what happens: interceptors in static runtime will be initialized using dlsym(RTLD_NEXT, ...) but they will find dynamic runtime's symbols instead of true libc symbols. So __interception::real_* pointers will remain NULLs. This will cause segfaults in e.g. MaybeInstallSigaction, etc.


http://llvm-reviews.chandlerc.com/D3042



More information about the llvm-commits mailing list