This is an archive of the discontinued LLVM Phabricator instance.

[compiler-rt] Split dll_thunks into different sanitizers.
ClosedPublic

Authored by mpividori on Jan 25 2017, 3:40 PM.

Details

Summary

In Windows, when the sanitizer is implemented as a static library and is included in the main executable, we need an auxiliary static library dll_thunk that will be linked to the dlls that have instrumentation, so they can refer to the runtime in the main executable. Basically, it uses interception to get a pointer the function in the main executable and override its function with that pointer.

Before this diff, all of this implementation was included in asan. In this diff I split it into different sanitizers, so we can use other sanitizers regardless of whether we include asan or not.

All the sanitizers will include a file sanitizer_win_dll_thunk.cc that register functions to be intercepted in the binary section: DLLTH

When the dll including dll_thunk is initialized, it will execute __dll_thunk_init() implemented in: sanitizer_common/sanitizer_win_dll_thunk.cc, which will consider all the CB registered in the section DLLTH. So, all the functions registered will be intercepted, and redirected to the implementation in the main executable.

All the files "sanitizer_win_dll_thunk.cc" are independent, so we don't need to include a specific list of sanitizers.
To create a dll_thunk for sanitizers SanitizerA and SanitizerB, we only need to compile: sanitizera/sanitizera_win_dll_thunk.cc sanitizerb/sanitizerb_win_dll_thunk.cc and sanitizer_common/sanitizer_win_dll_thunk.cc.

So, now, we compile: asan_win_dll_thunk.cc ubsan_win_dll_thunk.cc, sanitizer_coverage_win_dll_thunk.cc and sanitizer_win_dll_thunk.cc , to generate asan_dll_thunk, because we include asan, ubsan and sanitizer coverage in the address sanitizer library.

But we could also compile: sanitizer_coverage_win_dll_thunk.cc and sanitizer_win_dll_thunk.cc , to generate a dll_thunk only for sanitizer_coverage.

In a new diff I will add code to intercept weak functions.

Diff Detail

Repository
rL LLVM

Event Timeline

mpividori created this revision.Jan 25 2017, 3:40 PM
mpividori updated this revision to Diff 85860.Jan 25 2017, 8:47 PM
mpividori updated this revision to Diff 85929.Jan 26 2017, 9:21 AM
mpividori updated this revision to Diff 86098.Jan 27 2017, 12:29 PM
rnk edited edge metadata.Jan 30 2017, 10:10 AM

This thunking code needs to be rewritten at some point. It's basically doing it's own lazy PLT resolution. There must be some way that we can get the loader to do our work for us. It will already create thunks for functions provided by import libraries.

@rnk I would like to simply generate an import library. I have been reading some documentation to see if there is a way to simplify this and generate all of this code automatically with the linker. But, according to what I have found. (I really spent some time reading about this, but I don't have previous experience on Windows environment, so maybe I am missing something) . To create an import library, you need to provide exactly the same object files, that will be used to the final linkage. From: https://msdn.microsoft.com/en-us/library/f0z8kac4.aspx

"Note that if you create your import library in a preliminary step, before creating your .dll, you must pass the same set of object files when building the .dll, as you passed when building the import library."

So, as the library will be statically linked to the main executable, and we don't have access to the code in the main executable, we can not generate an import library.

mpividori updated this revision to Diff 86518.Jan 31 2017, 4:19 PM

@alekseyshl Would you agree with this diff? Ready to land?

This revision is now accepted and ready to land.Feb 1 2017, 6:51 PM
This revision was automatically updated to reflect the committed changes.