On Fri, Jun 9, 2017 at 4:26 PM, hariri via address-sanitizer
<[email protected]> 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.

>
> 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
>> <[email protected]> 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 [email protected].
>> > 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 [email protected].
> 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 [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to