sanitizer dlopen interception clobbers RUNPATH

[Quuxplusone]

Bugzilla Link	PR27790
Status	NEW
Importance	P normal
Reported by	Francis Ricci (francisjricci@gmail.com)
Reported on	2016-05-17 12:06:48 -0700
Last modified on	2020-04-30 09:21:20 -0700
Version	3.8
Hardware	PC Linux
CC	compnerd@compnerd.org, eugeni.stepanov@gmail.com, francisjricci@gmail.com, kcc@google.com, llvm-bugs@lists.llvm.org, m.ostapenko@samsung.com, pawel_sikora@zoho.com, tetra2005@gmail.com, vitalybuka@google.com, willdtz@gmail.com
Fixed by commit(s)
Attachments
Blocks
Blocked by
See also

dlopen() uses the RUNPATH of the dso which calls it. This means that when a
shared sanitizer dso intercepts dlopen, the RUNPATH of the sanitizer dso will
be used instead of the RUNPATH of the dso being intercepted.

Repro steps:
clang-3.8 test.c -Wl,-rpath,'$ORIGIN' -Wl,--enable-new-dtags -ldl -o clean
clang-3.8 test.c -Wl,-rpath,'$ORIGIN' -Wl,--enable-new-dtags -ldl -
fsanitize=address -o sanitized_static
clang-3.8 test.c -Wl,-rpath,'$ORIGIN' -Wl,--enable-new-dtags -ldl -
fsanitize=address -shared-libasan -o sanitized_dynamic
clang-3.8 foo.c -shared -o foo.so

Note that executing clean and sanitized_static will succeed, while executing
sanitized_dynamic will fail.

foo.c:

int foo = 0;

test.c:

#include <dlfcn.h>

int main() {
  if (dlopen("foo.so", RTLD_NOW)) {
    return 0;
  }

  return 1;
}

[Quuxplusone]

So, the problem only appears with -shared-libasan?
Adding the Yuri and Max who have more experience with shared-libasan

[Quuxplusone]

Yes. If asan is linked statically, the dlopen call will happen from within the original binary (or DSO), which will have the correct RUNPATH set. It's only a problem if dlopen is called from within the asan dso.

[Quuxplusone]

Sorry, only noticed this now (my Samsung address is inactive). I'm afraid I don't see how we could fix this easily and not intercepting dlopen is undesirable too. Perhaps just treat this as known issue?

[Quuxplusone]

So WONTFIX?