<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    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 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 class="moz-txt-link-abbreviated" href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a>
<a 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 class="moz-txt-link-freetext" href="http://www.cosade.org">http://www.cosade.org</a>

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>
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>
  </body>
</html>