<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi,<br>
<br>
Resending because the forwarded email likely got filtered out
because of the attachment.<br>
<br>
Regards,<br>
Bhargava<br>
<div class="moz-forward-container"><br>
<br>
-------- Forwarded Message --------
<table class="moz-email-headers-table" border="0" cellpadding="0"
cellspacing="0">
<tbody>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">Subject:
</th>
<td>Re: [cfe-dev] clang dataflow sanitizer vs. shared
objects</td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">Date: </th>
<td>Mon, 23 Feb 2015 01:27:04 +0100</td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">From: </th>
<td>Bhargava Shastry
<a class="moz-txt-link-rfc2396E" href="mailto:bshastry@sec.t-labs.tu-berlin.de"><bshastry@sec.t-labs.tu-berlin.de></a></td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">To: </th>
<td><a class="moz-txt-link-abbreviated" href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a></td>
</tr>
</tbody>
</table>
<br>
<br>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
Hello all,<br>
<br>
Following up on this thread: Found that Peter's instructions to
get dfsan support in libcxx/libcxxabi [1] does not work on latest
upstream commits (LLVM: 1f22900; Clang: 3457cd5; compiler-rt:
7bbc72c; libcxx: da1818a; libcxxabi: 75a7bf6).<br>
<br>
I have attached the stack trace with diagnostics. Basically, an
assertion fails here:<br>
<blockquote type="cite">lib/Transforms/Instrumentation/DataFlowSanitizer.cpp:1404:
void {anonymous}::DFSanVisitor::visitCallSite(llvm::CallSite):
Assertion `!(cast<FunctionType>(
CS.getCalledValue()->getType()->getPointerElementType())->isVarArg()
&& dyn_cast<InvokeInst>(CS.getInstruction()))'
failed.</blockquote>
<br>
Pointers are much appreciated.<br>
<br>
Thanks,<br>
Bhargava<br>
<br>
[1]: <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://lists.cs.uiuc.edu/pipermail/cfe-dev/2015-January/040895.html">http://lists.cs.uiuc.edu/pipermail/cfe-dev/2015-January/040895.html</a><br>
<br>
<div class="moz-cite-prefix">On 02/05/2015 05:04 PM, Christian
Convey wrote:<br>
</div>
<blockquote
cite="mid:CAPfS4ZzU3QcpfBowfGrMBG0briPjrn1VqEDSruEmBq6estVP_A@mail.gmail.com"
type="cite">
<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 moz-do-not-send="true"
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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
cfe-dev mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Learn more about COSADE 2015, the 6th Conference on
Constructive Side Channel Analysis and Secure Design
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.cosade.org">http://www.cosade.org</a>
Bhargava Shastry <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:bshastry@sec.t-labs.tu-berlin.de"><bshastry@sec.t-labs.tu-berlin.de></a>
Security in Telecommunications
TU Berlin / Telekom Innovation Laboratories
Ernst-Reuter-Platz 7, Sekr TEL 17 / D - 10587 Berlin, Germany
phone: +49 30 8353 58235</pre>
<br>
</div>
<br>
</body>
</html>