<div dir="ltr">Yury, thanks, that's an interesting idea.<div><br></div><div>Speaking only for myself, I think the ideal behavior would be the following, assuming there's a reasonable way to implement it:</div><div><br></div><div>(1) Libraries (both static and dynamic) provide both a normal and dfs-enabled version of each exported function.</div><div><br></div><div>(2) The compiler and linker work together so that a function call site calls the dfs-enabled version of the target function if and only if the caller was also compiled with dfs.</div><div><br></div><div>I realize this is non-trivial for a few reasons, I'm just thinking about what my ideal endpoint would be.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 5, 2015 at 12:37 AM, Yury Gribov <span dir="ltr"><<a href="mailto:y.gribov@samsung.com" target="_blank">y.gribov@samsung.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 02/05/2015 01:23 AM, Peter Collingbourne wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Wed, Feb 04, 2015 at 02:56:03PM -0500, Christian Convey wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi guys,<br>
<br>
I'm running into some pain with dataflow sanitizer, and I'm wondering<br>
anyone's found a good work-around.<br>
<br>
I'm trying to analyze a code base which delegates a lot of functionality to<br>
shared objects.  The application looks up functions within the .so using<br>
hard-coded function names.  For example, "dlsym(..., "foo" );"<br>
<br>
Unfortunately for me, the dataflow sanitizer prepends "dfsw$" to the name<br>
of any function compiled with the dataflow sanitizer enabled.  So if<br>
function "foo" was compiled with the sanitizer enabled, I'd need to change<br>
these dlsym invocations to something like "dlsym(..., "dfsw$foo");"<br>
<br>
For now, I'm just black-listing ( via -fsanitize-blacklist ) every function<br>
that's exported by one of the application's shared objects.  This addresses<br>
the symbol lookup problem, but it means my dataflow labels are lost on data<br>
transmitted through these black-listed functions.<br>
<br>
Does anyone know of a good workaround to this problem, and/or what a<br>
longer-term solution might look like?<br>
</blockquote>
<br>
I'm not aware of a good solution to this problem at the moment. One possibility<br>
is to write a custom wrapper for the dlsym function that tries the symbol<br>
name both with and without the "dfs$" prefix, but this would potentially<br>
allow uninstrumented function pointers to leak into the program.<br>
</blockquote>
<br></div></div>
Using --defsym to create aliases during linking is another option. Perhaps DFSan should do this itself?<span class="HOEnZb"><font color="#888888"><br>
<br>
-Y<br>
<br>
</font></span></blockquote></div><br></div>