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

[Bhargava Shastry]

Hi,

Resending because the forwarded email likely got filtered out because of
the attachment.

Regards,
Bhargava


-------- Forwarded Message --------
Subject: 	Re: [cfe-dev] clang dataflow sanitizer vs. shared objects
Date: 	Mon, 23 Feb 2015 01:27:04 +0100
From: 	Bhargava Shastry <bshastry at sec.t-labs.tu-berlin.de>
To: 	cfe-dev at cs.uiuc.edu



Hello all,

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).

I have attached the stack trace with diagnostics. Basically, an
assertion fails here:
> 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.

Pointers are much appreciated.

Thanks,
Bhargava

[1]: http://lists.cs.uiuc.edu/pipermail/cfe-dev/2015-January/040895.html

On 02/05/2015 05:04 PM, Christian Convey wrote:
> Yury, thanks, that's an interesting idea.
>
> Speaking only for myself, I think the ideal behavior would be the
> following, assuming there's a reasonable way to implement it:
>
> (1) Libraries (both static and dynamic) provide both a normal and
> dfs-enabled version of each exported function.
>
> (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.
>
> I realize this is non-trivial for a few reasons, I'm just thinking
> about what my ideal endpoint would be.
>
> On Thu, Feb 5, 2015 at 12:37 AM, Yury Gribov <y.gribov at samsung.com
> <mailto:y.gribov at samsung.com>> wrote:
>
>     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
>
>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

-- 
Learn more about COSADE 2015, the 6th Conference on
Constructive Side Channel Analysis and Secure Design
http://www.cosade.org

Bhargava Shastry <bshastry at sec.t-labs.tu-berlin.de>
Security in Telecommunications
TU Berlin / Telekom Innovation Laboratories
Ernst-Reuter-Platz 7, Sekr TEL 17 / D - 10587 Berlin, Germany
phone: +49 30 8353 58235



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150223/c8851a32/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: OpenPGP digital signature
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150223/c8851a32/attachment.sig>