similar to: [LLVMdev] DataFlowSanitizer design discussion

On Thu, Jun 13, 2013 at 03:00:46PM -0700, Peter Collingbourne wrote: > Hi, > > I am starting a thread to discuss the design of DataFlowSanitizer, > a compiler instrumentation based analysis tool which I am hoping to > bring into LLVM. As a starting point, I have included the current > version of the design document below. Comments are appreciated. Any further comments on the

Hi, If there are no further comments on the design below I intend to commit my DFSan patches in a week. Thanks, Peter On Tue, Jun 25, 2013 at 06:13:49PM -0700, Peter Collingbourne wrote: > On Thu, Jun 13, 2013 at 03:00:46PM -0700, Peter Collingbourne wrote: > > Hi, > > > > I am starting a thread to discuss the design of DataFlowSanitizer, > > a compiler

Hi there. I’m trying to use LibFuzzer on OSX and face some issues: I checked out LibFuzzer documentation[1] and managed to proceed until the final step of the first example. Now I see linker errors related to dfsan, dfsan’s documentation[2] states explicitly “DataFlowSanitizer is a work in progress, currently under development for x86_64 Linux.”. Does it mean that LibFuzzer available only on

I am using pre-built LLVM/Clang 3.8.0 binaries on Ubuntu 16.04.2, 64 bit. I tried to lift a minimal program to LLVM IR, then link the IR to DataFlowSanitizer libraries to produce executable code. In the second step, the process throws a bunch of linker errors. ========================================= #include <sanitizer/dfsan_interface.h> #include <assert.h> int main(void) { int

Hi all, I have some questions about "DataFlowSanitizer" from "compiler-rt". I want to know how I can test the "DataFlowSanitizer"? Can I configure it to label only some values, i.e, the return values from specific functions? Also, how can I print these labels? Thanks, Dareen -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi. I'm using llvm DataFlowSanitizer. I add such code in library libtiff. dfsan_label lt_label = dfsan_create_label("buf_offset", 0); dfsan_set_label(lt_label, (unsigned char *)buf, size); But when i compile libtiff with "-fsanitize=dataflow" option, then there is an error as follows: ../libtiff/libtiff.so.5.2.5: undefined reference to `dfs$jbg_enc_init'

It is interesting. I can see some use cases with such a tool. To me, source-level implementation is not as accurate as binary translation. For instance, it is hard to check the taint for return addresses since there is no concept of return instructions on source level. The stack does not appear until later. For a security mechanism, return addresses need to be protected. On Fri, Jun 14, 2013 at

Could you maybe give some example use cases? Also, "sanitizer" may not be the best name for this, since it doesn't really sanitize anything. -- Sean Silva -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130613/89f3df75/attachment.html>

On Thu, Jun 13, 2013 at 03:13:37PM -0700, Sean Silva wrote: > Could you maybe give some example use cases? A use case I am interested in is to take a large application and use this instrumentation as a tool to help monitor how data flows from its inputs (sources) to its outputs (sinks). This has applications from a privacy/security perspective in that one can audit how a sensitive data item

15.06.2013, 00:53, "Bin Tzeng" <bintzeng at gmail.com>: > It is interesting. I can see some use cases with such a tool. To me, source-level implementation > is not as accurate as binary translation. For instance, it is hard to check the taint for return addresses > since there is no concept of return instructions on source level. Well, on many architectures there is no

On Sat, Mar 31, 2018 at 8:50 AM, 吕涛 via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hi. I'm using llvm DataFlowSanitizer. I add such code in library libtiff. > > dfsan_label lt_label = dfsan_create_label("buf_offset", 0); > > dfsan_set_label(lt_label, (unsigned char *)buf, size); > > But when i compile libtiff with "-fsanitize=dataflow" option,

Let in a program a variable 'x' is tainted. There is an assignment 'y=x' where y is untainted. How to check the taintflow in the output or data flow graph ? Any suggestions? Thank you. Have a great day. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190912/5bb3655c/attachment.html>

Dear Developers, I am a Master's student at the ECE department of the University of Florida, USA.​​ For my research project, supervised by Prof. Mark Tehranipoor<http://tehranipoor.ece.ufl.edu/> and Prof. Farimah Farahmandi<http://farimah.ece.ufl.edu/>, I need to use Clang LLVM DataflowSanitizer library in KLEE. However, I have faced some difficulties (explained below) while

Hi all, Any one tried using DataFlowSanitizer on Linux x86_64? I tried on: 3.13.0-44-generic #73~precise1-Ubuntu SMP Wed Dec 17 00:39:15 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux It assumes wrong memory layout and remaps application code segment as shadow memory, thus causing SIGSEV (Segmentation fault). Is this know? and fix under way? -Thanks, Aravind -------------- next part

Afternoon, I had an issue with trying to link a program with the DataFlowSanitizer functionality, this is from the libFuzzer project, and I was seeing: clang++ -fsanitize=address -fsanitize-coverage=edge test_fuzzer.cc Fuzzer*.o Undefined symbols for architecture x86_64: "_dfsan_create_label", referenced from: fuzzer::TraceState::DFSanCmpCallback(unsigned long, unsigned

FWIW see also http://lists.cs.uiuc.edu/pipermail/cfe-dev/2015-June/043301.html As far as I understand DFSan functionality isn't required for libFuzzer to work, so it should be safe to disable DFSan support on Mac. On Wed, Jul 8, 2015 at 7:45 AM, Kostya Serebryany <kcc at google.com> wrote: > +pcc , glider > > On Mon, Jul 6, 2015 at 12:59 PM, Juan Ceasar <juan.d.ceasar at

Kostya, I took a quick stab at patching libFuzzer for Apple, but so far I'm thinking something else is incorrect. Patch is attached but when I went to reproduce the examples, the toy example went fine, but with PCRE and Heartbleed I noticed the coverage statistics were pretty poor, and didn't find anything. Admittedly I moved onto Heartbleed pretty quickly so PCRE probably isn't the

On Tue, Oct 7, 2014 at 2:51 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > Looks good, thanks! > > Can you write the test case, please? You probably have more experience > writing debug info tests than I do. > Sure - though how would I get the pre-dfsan .ll file to produce this behavior? I've tried compiling to a .ll file without dfsan, then feeling that .ll

Here's a basic patch which would solve it in sort of the same way as the other optimizations I was fixing (just special case the debug info & fix it up). I can work up a test case for this as well, or you can, if you like/this seems reasonable. On Tue, Oct 7, 2014 at 2:30 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > On Tue, Oct 07, 2014 at 12:20:55PM -0700, David

On Tue, Oct 7, 2014 at 12:18 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > On Tue, Oct 7, 2014 at 12:10 PM, David Blaikie <dblaikie at gmail.com> wrote: > >> >> >> On Tue, Oct 7, 2014 at 11:48 AM, Peter Collingbourne <peter at pcc.me.uk> >> wrote: >> >>> On Tue, Oct 07, 2014 at 10:04:30AM -0700, David Blaikie wrote: