[cfe-dev] clang dataflow sanitizer vs. shared objects

[Yury Gribov]

On 02/05/2015 01:23 AM, Peter Collingbourne wrote:
> On Wed, Feb 04, 2015 at 02:56:03PM -0500, Christian Convey wrote:
>> Hi guys,
>>
>> I'm running into some pain with dataflow sanitizer, and I'm wondering
>> anyone's found a good work-around.
>>
>> I'm trying to analyze a code base which delegates a lot of functionality to
>> shared objects.  The application looks up functions within the .so using
>> hard-coded function names.  For example, "dlsym(..., "foo" );"
>>
>> Unfortunately for me, the dataflow sanitizer prepends "dfsw$" to the name
>> of any function compiled with the dataflow sanitizer enabled.  So if
>> function "foo" was compiled with the sanitizer enabled, I'd need to change
>> these dlsym invocations to something like "dlsym(..., "dfsw$foo");"
>>
>> For now, I'm just black-listing ( via -fsanitize-blacklist ) every function
>> that's exported by one of the application's shared objects.  This addresses
>> the symbol lookup problem, but it means my dataflow labels are lost on data
>> transmitted through these black-listed functions.
>>
>> Does anyone know of a good workaround to this problem, and/or what a
>> longer-term solution might look like?
>
> I'm not aware of a good solution to this problem at the moment. One possibility
> is to write a custom wrapper for the dlsym function that tries the symbol
> name both with and without the "dfs$" prefix, but this would potentially
> allow uninstrumented function pointers to leak into the program.

Using --defsym to create aliases during linking is another option. 
Perhaps DFSan should do this itself?

-Y