On Fri, Jun 9, 2017 at 4:52 PM, 'Evgenii Stepanov' via address-sanitizer <
address-sanitizer@googlegroups.com> wrote:

> On Fri, Jun 9, 2017 at 4:26 PM, hariri via address-sanitizer
> <address-sanitizer@googlegroups.com> wrote:
> > Thanks for your reply Evgeniy.
> >
> >> It could be possible
> > to hack something, but it does not sound easy
> >
> > Could you please give me some pointers into what needs to be hacked to
> make
> > this possible?
>
> A few problems come to mind:
> 1. Shadow mappings of asan and dfsan probably overlap. ASan has a mode
> where shadow address is detemined at run time, it might help.
> 2. runtime libraries for asan and dfsan include the same code from
> lib/sanitizer_common. They must learn to share. See lib/lsan in
> compiler-rt for an example of a tool that can work either on its own,
> or with asan. This will also need build system changes to create a
> combined runtime library (asan + dfsan + sanitizer_common), and clang
> frontend changes to link it when necessary.
> 3. Do something about the interceptors. DFsan uses __dfsw_ -prefixed
> wrappers that update labels for some libc functions; need to make sure
> that asan interceptors (in lib/asan/asan_interceptors.cc) also run. It
> may just work out of the box.
>
> >
> >>  it's not clear to
> > me how one would tie them together.
> >
> > The scenario is the following: I am using libFuzzer to fuzz a library,
> and
> > libFuzzer works best
> > with a sanitizer like asan (as recommended by the documentation). What I
> > would like to do is
> > use taint information from the dataflow sanitizer to make fuzzing more
> > efficient and focus on
> > interesting parts of the input.
>
> The easiest way is to run two separate builds over the same corpus.
>

+1
We actually had some code in libFuzzer to work with dfsan and the idea was
to run with
dfsan to increase the coverage and separately run with asan to catch bugs.
I then deleted all this code from libFuzzer because it was a) not used and
b) made it much harder to do refactoring.
I still hope to get dfsan support back in at some point though --
data-flow-based mutations are too attractive.

I do not recommend you to invest time into running asan and dfsan in one
process -- simply too much work.

--kcc



>
> >
> > On Friday, June 9, 2017 at 2:41:57 PM UTC-7, Evgeniy Stepanov wrote:
> >>
> >> Hi,
> >>
> >> these tools were not designed to work together. It could be possible
> >> to hack something, but it does not sound easy. In particular, they use
> >> different techniques for intercepting libc calls and it's not clear to
> >> me how one would tie them together.
> >>
> >>
> >> On Fri, Jun 9, 2017 at 8:52 AM, hariri via address-sanitizer
> >> <address-...@googlegroups.com> wrote:
> >> > Hi,
> >> >
> >> > I am trying to use the dataflow sanitizer with the address sanitizer,
> >> > but
> >> > they clash together giving me a long sequence of errors due to
> multiple
> >> > definitions in both sanitizers:
> >> >
> >> >
> >> > clang-llvm/ninja-build-clang/lib/clang/5.0.0/lib/linux/
> libclang_rt.dfsan-x86_64.a(interception_linux.cc.o):
> >> > In function `__interception::GetRealFunctionAddress(char const*, \
> >> >
> >> > unsigned long*, unsigned long, unsigned long)':
> >> >
> >> >
> >> > clang-llvm/llvm/projects/compiler-rt/lib/interception/
> interception_linux.cc:22:
> >> > multiple definition of `__interception::GetRealFunctionAddress(char
> >> > const*,
> >> > unsigned long*, u\
> >> >
> >> > nsigned long, unsigned long)'
> >> >
> >> >
> >> > clang-llvm/ninja-build-clang/lib/clang/5.0.0/lib/linux/
> libclang_rt.asan-x86_64.a(interception_linux.cc.o):
> clang-llvm/llvm/projects/compiler-rt/\
> >> >
> >> > lib/interception/interception_linux.cc:22: first defined here
> >> >
> >> >
> >> > clang-llvm/ninja-build-clang/lib/clang/5.0.0/lib/linux/
> libclang_rt.dfsan-x86_64.a(interception_linux.cc.o):
> >> > In function `__interception::GetFuncAddrVer(char const*, char con\
> >> >
> >> > st*)':
> >> >
> >> >
> >> > clang-llvm/llvm/projects/compiler-rt/lib/interception/
> interception_linux.cc:28:
> >> > multiple definition of `__interception::GetFuncAddrVer(char const*,
> char
> >> > const*)'
> >> >
> >> >
> >> > clang-llvm/ninja-build-clang/lib/clang/5.0.0/lib/linux/
> libclang_rt.asan-x86_64.a(interception_linux.cc.o):
> clang-llvm/llvm/projects/compiler-rt/\
> >> >
> >> > lib/interception/interception_linux.cc:28: first defined here
> >> >
> >> >
> >> > clang-llvm/ninja-build-clang/lib/clang/5.0.0/lib/linux/
> libclang_rt.dfsan-x86_64.a(sanitizer_allocator.cc.o):
> >> > In function `atomic_load<__sanitizer::atomic_uint8_t>':
> >> >
> >> >
> >> > clang-llvm/llvm/projects/compiler-rt/lib/sanitizer_
> common/sanitizer_atomic_clang_x86.h:47:
> >> > multiple definition of `__sanitizer::internal_allocator()'
> >> >
> >> >
> >> > clang-llvm/ninja-build-clang/lib/clang/5.0.0/lib/linux/
> libclang_rt.asan-x86_64.a(sanitizer_allocator.cc.o):
> clang-llvm/llvm/projects/compiler-rt\
> >> >
> >> > /lib/sanitizer_common/sanitizer_atomic_clang_x86.h:47: first defined
> >> > here
> >> >
> >> >
> >> > clang-llvm/ninja-build-clang/lib/clang/5.0.0/lib/linux/
> libclang_rt.dfsan-x86_64.a(sanitizer_allocator.cc.o):
> >> > In function `__sanitizer::LowLevelAllocator::Allocate(unsigned l\
> >> >
> >> > ong)':
> >> >
> >> >
> >> > The simplest stripped example is compiling any cpp file for example:
> >> >
> >> > // simple.cc
> >> >
> >> > int main() {
> >> >
> >> >   return 0;
> >> >
> >> > }
> >> >
> >> >
> >> > with the command:
> >> >
> >> > clang++ simple.cc -fsanitize=address,dataflow
> >> >
> >> >
> >> > Thanks,
> >> >
> >> > Farah
> >> >
> >> > --
> >> > You received this message because you are subscribed to the Google
> >> > Groups
> >> > "address-sanitizer" group.
> >> > To unsubscribe from this group and stop receiving emails from it, send
> >> > an
> >> > email to address-saniti...@googlegroups.com.
> >> > For more options, visit https://groups.google.com/d/optout.
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "address-sanitizer" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to address-sanitizer+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "address-sanitizer" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to address-sanitizer+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"address-sanitizer" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to address-sanitizer+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to