Re: ASAN - How to suppress strlen Error ?
You can run Asan in error recovery mode (it's not generally recommended as errors after the first one can not be reported reliably but normally it works fine). You can see details e.g. in this answer: https://github.com/google/sanitizers/issues/649#issuecomment-176304136 On 2/19/19, Hiren Shah wrote: > Hi, > > I am new to asan. I want to suppress strlen error. I am getting following > backtrace which is aborting ASAN. I would like ASAN to skip that error. > > > #3 0x7fd8f5994288 in __sanitizer::Die() () from /lib64/libasan.so.4 > > #4 0x7fd8f5975275 in __asan::ReportGenericError(unsigned long, > unsigned long, unsigned long, unsigned long, bool, unsigned long, unsigned > int, bool) () > >from /lib64/libasan.so.4 > > #5 0x7fd8f58dd3dd in __interceptor_strlen.part.24 () from > /lib64/libasan.so. > > -- > 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. > -- Best regards, Yuri -- 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.
Re: Leak sanitizer not working with optimisations enabled
Hi Ankur,
If pointer to allocated buffer manages to survive in one of the
registers or on stack (after program returns from main), LSan would
consider buffer to be reachable and won't report it. This behavior is
very sensitive to compiler/Glibc version and compilation flags.
On 2/15/19, Ankur Raj wrote:
> Hi Folks ,
> Wondering if someone can explain this
> Adress sanitizer does not report and leak in this code below when compiled
> with O1 , O2 ,,,
>
> But it works as expected when compiled with O0
>
> #include
> #include
>
> int main () {
>volatile char *str;
>
>/* Initial memory allocation */
>str = (char *) malloc(25);
>strcpy(str, "sameple st");
>printf("String = %s, Address = %u\n", str, str);
>
>strcat(str, "append");
>printf("String = %s, Address = %u\n", str, str);
>
>
>return(0);
> }
>
> I am compiling this code as
>
> gcc -fsanitize=address -O0 a.c
> gcc --version
> gcc (GCC) 8.2.1 20190102
>
> I looked at asm code also and clearly malloc has not been removed by
> optimizers
>
> 22 .cfi_startproc
> 23 pushq %rbp
> 24 .cfi_def_cfa_offset 16
> 25 .cfi_offset 6, -16
> 26 movq%rsp, %rbp
> 27 .cfi_def_cfa_register 6
> 28 subq$16, %rsp
> 29 movl$25, %edi
> 30 *callmalloc*
> 31 movq%rax, -8(%rbp)
> 32 movq-8(%rbp), %rax
> 33 movl$11, %edx
> 34 movl$.LC0, %esi
> 35 movq%rax, %rdi
> 36 callmemcpy
>
> Any clue what is happening here ?
>
>
>
>
> --
> 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.
>
--
Best regards,
Yuri
--
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.
Re: How to use address sanitizer on a sub process
On Mon, May 21, 2018 at 5:24 PM, Konstantin Serebryany wrote: > > > On Mon, May 21, 2018 at 9:01 AM Seshadri R wrote: >> >> Hi, >> >> I want to use address sanitizer to profile a program (say A). However, >> this program is launched as a child of another process (B). I have built the >> executable for A using the compiler flags : >> -fsanitize=address -static-libasan >> >> and linked the process using the flags >> -fsanitize=address -static-libasan -lasan. > > > You should never need -lasan. > If any piece of documentation tells you to use -lasan, please let us know, > we need to remove that. Most people pick it up from stackoverflow or blogposts... > -fsanitize=address at both compile and link-time should be sufficient. > -static-libasan is optional. > > >> >> >> However, when I launch Process A as a subprocess of process B, I am not >> getting any errors or warnings. > > > Maybe your program doesn't have bugs? > >> >> >> How do I get the memory leaks in process A using Address Sanitizer? > > > Are you only looking for memory leaks or for other types of bugs too? > Unlike most other kinds of bugs, memory leaks are reported when the process > is exiting, > see https://clang.llvm.org/docs/LeakSanitizer.html > >> >> >> Thanks and Regards >> Seshadri >> >> -- >> 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.
Re: Address Sanitizer with Ruby Nokogiri module/Gem
On Fri, May 18, 2018 at 11:05 PM, Konstantin Serebryany wrote: > > > On Fri, May 18, 2018 at 2:30 PM MK wrote: >> >> Hi kcc, >> >> Thanks for your hint. It did get me further to some point. >> >> I successfully compiled Ruby, libxml2, libxst and Nokogiri with ASan, but >> when I run it I still get: I think using GCC and Clang to built different parts of the program (and preloading GCC's Asan runtime to Clang-built executable) may be part of the problem. -Y -- 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.
Re: RFC: Enable core dumps even on 64-bit platforms
On Thu, Jul 27, 2017 at 10:51 PM, Konstantin Serebryany wrote: > Just to make sure: all you are suggesting is to change the default value(s) > of flag(s), right? Yup. > I am reluctant to change the defaults here because core dumps are rarely > useful with asan reports and because they will cause more trouble then is > worth it (atexit timeout, disk full, etc) Well, maybe this isn't an issue with madv_dont_dump being default? > On Wed, Jul 26, 2017 at 11:57 PM, Yuri Gribov wrote: >> >> Hi all, >> >> Currently core dumps are disabled on 64-bit platforms. This decisions >> come from old times when 16 TB shadow memory was included in coredump. >> Nowadays we have use_madv_dontdump (enabled by default) which keeps >> size of core file reasonable. Perhaps we can disable disable_coredump >> on all platforms unconditionally? This is causing real usability >> issues (see >> https://stackoverflow.com/questions/45280910/gcc-address-sanitizer-core-dump-on-error). >> >> -I >> >> -- >> 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.
RFC: Enable core dumps even on 64-bit platforms
Hi all, Currently core dumps are disabled on 64-bit platforms. This decisions come from old times when 16 TB shadow memory was included in coredump. Nowadays we have use_madv_dontdump (enabled by default) which keeps size of core file reasonable. Perhaps we can disable disable_coredump on all platforms unconditionally? This is causing real usability issues (see https://stackoverflow.com/questions/45280910/gcc-address-sanitizer-core-dump-on-error). -I -- 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.
Re: Making adaptive redzones less aggressive
On Mon, Jul 17, 2017 at 10:25 AM, 'Alexander Potapenko' via
address-sanitizer wrote:
> On Sat, Jul 15, 2017 at 4:39 PM, Yuri Gribov wrote:
>> Hi all,
>>
>> From reading the original feature request in
>> https://github.com/google/sanitizers/issues/8 it seems that adaptive
>> redzones were mainly meant for catching overflows in arrays of large
>> objects e.g.
>>
>> struct {
>> int a[10];
>> int x;
>> } a[100];
>> a[101].x = 0; // Skips redzone
>>
>> Current adaptation only considers size of array as a whole so would
>> add similarly big redzone for same-sized
>>
>> int a[1100];
>>
>> even though risk of large overflow offset here seems to be much lower.
>>
>> Has anyone considered selecting redzone based on array element size
>> rather than array size? Firstly this would allow more intelligent
>> redzone selection (current approach does not guarantee that generated
>> redzone will cover one array element) and also reduce memory pressure
>> (which is important for "embedded" targets).
>
> I totally agree that for compound type arrays the redzone size must be
> based on the array element size.
>
> Not sure if we need to reduce the redzone size for big arrays of
> scalars, as e.g. char arrays are sometimes used as opaque storage for
> compound types.
Good point.
> Do you have any evidence how big is the memory overhead caused by
> redzones in this case?
Not yet, this is something we'll need to investigate (my question was
mainly whether it makes sense to investigate this).
-Y
--
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.
Making adaptive redzones less aggressive
Hi all,
>From reading the original feature request in
https://github.com/google/sanitizers/issues/8 it seems that adaptive
redzones were mainly meant for catching overflows in arrays of large
objects e.g.
struct {
int a[10];
int x;
} a[100];
a[101].x = 0; // Skips redzone
Current adaptation only considers size of array as a whole so would
add similarly big redzone for same-sized
int a[1100];
even though risk of large overflow offset here seems to be much lower.
Has anyone considered selecting redzone based on array element size
rather than array size? Firstly this would allow more intelligent
redzone selection (current approach does not guarantee that generated
redzone will cover one array element) and also reduce memory pressure
(which is important for "embedded" targets).
-Y
--
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.
Re: AddressSanitizer: attempting free on address which was not malloc()-ed
On Wed, Jul 12, 2017 at 4:55 PM, sothy shan wrote:
>
>
> On Wednesday, July 12, 2017 at 2:52:12 PM UTC+2, Maxim Ostapenko wrote:
>>
>> Hm, looks pretty the same to
>> https://github.com/google/sanitizers/issues/830. Could you provide more
>> details how to reproduce the issue?
>
>
> This error is made at run-time. From the stack, FeatureReply DTOR is
> called.
> From there, of10::Port DTOR is called and subsequently Port Common is
> called.
> When PortCommon is called , it gives error.
You built your app with GCC6 (which thus used libstdc++ headers from
GCC6) but then ran it with libstdc++ from GCC5
(/usr/lib/x86_64-linux-gnu/libstdc++.so.6) which might have caused ABI
mismatch. Try to set up LD_LIBRARY_PATH appropriately so that app
loads proper libstdc++.so.
>
> [~PortCommon]
> https://github.com/OpenNetworkingFoundation/libfluid_msg/blob/master/fluid/ofcommon/common.hh
> (line 28).
> [~Port]
> https://github.com/OpenNetworkingFoundation/libfluid_msg/blob/master/fluid/of10/of10common.hh
> [~~FeaturesReply() /usr/local/include/fluid/of10msg.hh:121]
> https://github.com/OpenNetworkingFoundation/libfluid_msg/blob/master/fluid/of10msg.hh
>
> These information is not enough. I can provide more details. Bit complex to
> reproduce the issue. Otherwise, I can do some test here if you propose.
>
> Best regards
> Sothy
>
>
>
>
>>
>>
>>> Hello,
>>> I'm running the gcc 6.3.0 version with opensource code in ubuntu 16.04
>>> LTS.
>>> When I run my code, I am getting error.
>>>
>>>
>>> ==5094==ERROR: AddressSanitizer: attempting free on address which was not
>>> malloc()-ed: 0x60312d78 in thread T0
>>> #0 0x7f6115c33630 in operator delete(void*)
>>> (/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc8630)
>>> #1 0x12054a6 in fluid_msg::PortCommon::~PortCommon()
>>> /usr/local/include/fluid/ofcommon/common.hh:28
>>> #2 0x1205842 in fluid_msg::of10::Port::~Port()
>>> /usr/local/include/fluid/of10/of10common.hh:26
>>> #3 0x1214d62 in void
>>> std::_Destroy(fluid_msg::of10::Port*)
>>> /usr/include/c++/6/bits/stl_construct.h:93
>>> #4 0x1213686 in void
>>> std::_Destroy_aux::__destroy(fluid_msg::of10::Port*,
>>> fluid_msg::of10::Port*) /usr/include/c++/6/bits/stl_construct.h:103
>>> #5 0x120f4e6 in void
>>> std::_Destroy(fluid_msg::of10::Port*,
>>> fluid_msg::of10::Port*) /usr/include/c++/6/bits/stl_construct.h:126
>>> #6 0x120c5e5 in void std::_Destroy>> fluid_msg::of10::Port>(fluid_msg::of10::Port*, fluid_msg::of10::Port*,
>>> std::allocator&)
>>> /usr/include/c++/6/bits/stl_construct.h:151
>>> #7 0x1208a0a in std::vector>> std::allocator >::~vector()
>>> /usr/include/c++/6/bits/stl_vector.h:426
>>> #8 0x1205966 in fluid_msg::of10::FeaturesReply::~FeaturesReply()
>>> /usr/local/include/fluid/of10msg.hh:121
>>> #9 0x1238881 in
>>> ofd::of_server::OFconnection::proces_read_msg(seastar::temporary_buffer)
>>> /home/sothy/netbricks/bitbucket/ofd/ofserver.hh:513
>>> #10 0x12353b8 in
>>> _ZZN3ofd9of_server12OFconnection8read_oneEvENKUlT_E_clIN7seastar6futureIJNS5_16temporary_bufferIcEEEDaS2_
>>> /home/sothy/netbricks/bitbucket/ofd/ofserver.hh:450
>>> #11 0x128108f in seastar::future<>
>>> seastar::futurize
>>> >::apply>> seastar::future >
>>> >(ofd::of_server::OFconnection::read_one()::{lambda(auto:1)#1}&&,
>>> seastar::future >&&)
>>> /home/sothy/netbricks/development/seastar/core/future.hh:1312
>>> #12 0x1340a2f in
>>> _ZZN7seastar6futureIJNS_16temporary_bufferIc12then_wrappedIZN3ofd9of_server12OFconnection8read_oneEvEUlT_E_NS0_IJET0_OS8_ENUlSC_E_clINS_12future_stateIJS2_EDaSC_
>>> /home/sothy/netbricks/development/seastar/core/future.hh:940
>>> #13 0x134131c in seastar::continuation
>>> seastar::future
>>> >::then_wrapped>> seastar::future<>
>>> >(ofd::of_server::OFconnection::read_one()::{lambda(auto:1)#1}&&)::{lambda(auto:2)#1},
>>> seastar::temporary_buffer >::run()
>>> /home/sothy/netbricks/development/seastar/core/future.hh:395
>>> #14 0x456004 in
>>> seastar::reactor::run_tasks(seastar::circular_buffer>> std::default_delete >,
>>> std::allocator>> std::default_delete > > >&) core/reactor.cc:2316
>>> #15 0x45cc46 in seastar::reactor::run() core/reactor.cc:2774
>>> #16 0xab585e in seastar::app_template::run_deprecated(int, char**,
>>> std::function&&) core/app-template.cc:142
>>> #17 0x1218aa0 in main
>>> /home/sothy/netbricks/bitbucket/ofd/ofapp.cc:186
>>> #18 0x7f6110f2682f in __libc_start_main
>>> (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
>>> #19 0x415428 in _start
>>> (/home/sothy/netbricks/bitbucket/ofd/a.out+0x415428)
>>>
>>> 0x60312d78 is located 24 bytes inside of 32-byte region
>>> [0x60312d60,0x60312d80)
>>> allocated by thread T0 here:
>>> #0 0x7f6115c32fb0 in operator new(unsigned long)
>>> (/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc7fb0)
>>> #1 0x7f61142f96f8 in std::string::_Rep::_S_create(unsigned long,
>>> unsigned long, std::allocator const&)
>>> (/usr/lib/x86_64-linux-gnu/libstdc++.so.6+0xd
Re: c1plus: error: unrecognized command line option "-fsanitize=address"
On Fri, Jul 7, 2017 at 1:00 PM, Ramin Farajpour Cami wrote: > g++ and c++ is version 4.9.1-10 For some reason configure script has different opinion on this, it seems to use an older version: c++: error: unrecognized command line option '-fsanitize=address' To understand what's going on, you probly need to inspect config.log and see which command is failing and why. > On Fri, Jul 7, 2017 at 4:25 PM, Yuri Gribov wrote: >> >> On Fri, Jul 7, 2017 at 10:48 AM, Ramin Farajpour Cami >> wrote: >> > Ok Thanks a lot Yuri, >> > >> > you say work ASAN in the version GCC > 4.7.* but i have GCC = 4.9.1 >> > >> > do you think i should install GCC 5 resolve my issue? >> > >> > >> > [root@localhost usb]# gcc --version >> >> So what about version of g++ and c++? >> >> > gcc (GCC) 4.9.1 20140922 (Red Hat 4.9.1-10) >> > Copyright (C) 2014 Free Software Foundation, Inc. >> > This is free software; see the source for copying conditions. There is >> > NO >> > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR >> > PURPOSE. >> > >> > >> > >> > On Friday, July 7, 2017 at 2:00:50 PM UTC+4:30, Yuri Gribov wrote: >> >> >> >> On Fri, Jul 7, 2017 at 10:22 AM, Ramin Farajpour Cami >> >> wrote: >> >> > i don't know, i spend many time for resolve it, but nothing, >> >> > >> >> > please look : https://fuzzing-project.org/tutorial2.html >> >> >> >> The instructions aren't quite correct, they miss the LDFLAGS setting. >> >> I emailed Hanno, not sure when he fixes this. >> >> >> >> > so i use : ./configure --disable-shared CFLAGS="-fsanitize=address >> >> > -ggdb" >> >> > CXXFLAGS="-fsanitize=address -ggdb" >> >> > >> >> > again i got error: >> >> > >> >> > c++: error: unrecognized command line option '-fsanitize=address' >> >> >> >> Please try to execute >> >> gcc --version >> >> g++ --version >> >> c++ --version >> >> and report your findings. >> >> >> >> > On Friday, July 7, 2017 at 11:18:33 AM UTC+4:30, Yuri Gribov wrote: >> >> >> >> >> >> On Fri, Jul 7, 2017 at 7:32 AM, Ramin Farajpour Cami >> >> >> wrote: >> >> >> > Yuri, >> >> >> > >> >> >> > again i have error: >> >> >> > >> >> >> > [root@localhost usb]# ./configure CXXFLAGS="-fsanitize=address >> >> >> > -ggdb" >> >> >> > checking for a BSD-compatible install... /usr/bin/install -c >> >> >> > checking whether build environment is sane... yes >> >> >> > checking for a thread-safe mkdir -p... /bin/mkdir -p >> >> >> > checking for gawk... gawk >> >> >> > checking whether make sets $(MAKE)... yes >> >> >> > checking for C++ compiler default output file name... >> >> >> > configure: error: in `/root/usb': >> >> >> > configure: error: C++ compiler cannot create executables >> >> >> > See `config.log' for more details. >> >> >> >> >> >> Ramin, >> >> >> >> >> >> First of all, you should add -fsanitize=address to CFLAGS, CXXFLAGS >> >> >> and >> >> >> LDFLAGS. >> >> >> >> >> >> If that does not help, you'll need to investigate why compiler test >> >> >> inside configure fails. You can find particular source code and >> >> >> command line options which cause your g++ compilation to abort in >> >> >> config.log. >> >> >> >> >> >> -Y >> >> > >> >> > -- >> >> > 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 a topic in the >> Google Groups "address-sanitizer" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/address-sanitizer/vEKMbOz7qqs/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> address-sanitizer+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. > > > > > -- > Security researcher, Web developer, Linux kernel developer > Ramin Farajpour Cami > > -- > 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.
Re: c1plus: error: unrecognized command line option "-fsanitize=address"
On Fri, Jul 7, 2017 at 10:48 AM, Ramin Farajpour Cami wrote: > Ok Thanks a lot Yuri, > > you say work ASAN in the version GCC > 4.7.* but i have GCC = 4.9.1 > > do you think i should install GCC 5 resolve my issue? > > > [root@localhost usb]# gcc --version So what about version of g++ and c++? > gcc (GCC) 4.9.1 20140922 (Red Hat 4.9.1-10) > Copyright (C) 2014 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > > > On Friday, July 7, 2017 at 2:00:50 PM UTC+4:30, Yuri Gribov wrote: >> >> On Fri, Jul 7, 2017 at 10:22 AM, Ramin Farajpour Cami >> wrote: >> > i don't know, i spend many time for resolve it, but nothing, >> > >> > please look : https://fuzzing-project.org/tutorial2.html >> >> The instructions aren't quite correct, they miss the LDFLAGS setting. >> I emailed Hanno, not sure when he fixes this. >> >> > so i use : ./configure --disable-shared CFLAGS="-fsanitize=address >> > -ggdb" >> > CXXFLAGS="-fsanitize=address -ggdb" >> > >> > again i got error: >> > >> > c++: error: unrecognized command line option '-fsanitize=address' >> >> Please try to execute >> gcc --version >> g++ --version >> c++ --version >> and report your findings. >> >> > On Friday, July 7, 2017 at 11:18:33 AM UTC+4:30, Yuri Gribov wrote: >> >> >> >> On Fri, Jul 7, 2017 at 7:32 AM, Ramin Farajpour Cami >> >> wrote: >> >> > Yuri, >> >> > >> >> > again i have error: >> >> > >> >> > [root@localhost usb]# ./configure CXXFLAGS="-fsanitize=address -ggdb" >> >> > checking for a BSD-compatible install... /usr/bin/install -c >> >> > checking whether build environment is sane... yes >> >> > checking for a thread-safe mkdir -p... /bin/mkdir -p >> >> > checking for gawk... gawk >> >> > checking whether make sets $(MAKE)... yes >> >> > checking for C++ compiler default output file name... >> >> > configure: error: in `/root/usb': >> >> > configure: error: C++ compiler cannot create executables >> >> > See `config.log' for more details. >> >> >> >> Ramin, >> >> >> >> First of all, you should add -fsanitize=address to CFLAGS, CXXFLAGS and >> >> LDFLAGS. >> >> >> >> If that does not help, you'll need to investigate why compiler test >> >> inside configure fails. You can find particular source code and >> >> command line options which cause your g++ compilation to abort in >> >> config.log. >> >> >> >> -Y >> > >> > -- >> > 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.
Re: c1plus: error: unrecognized command line option "-fsanitize=address"
On Fri, Jul 7, 2017 at 10:22 AM, Ramin Farajpour Cami wrote: > i don't know, i spend many time for resolve it, but nothing, > > please look : https://fuzzing-project.org/tutorial2.html The instructions aren't quite correct, they miss the LDFLAGS setting. I emailed Hanno, not sure when he fixes this. > so i use : ./configure --disable-shared CFLAGS="-fsanitize=address -ggdb" > CXXFLAGS="-fsanitize=address -ggdb" > > again i got error: > > c++: error: unrecognized command line option '-fsanitize=address' Please try to execute gcc --version g++ --version c++ --version and report your findings. > On Friday, July 7, 2017 at 11:18:33 AM UTC+4:30, Yuri Gribov wrote: >> >> On Fri, Jul 7, 2017 at 7:32 AM, Ramin Farajpour Cami >> wrote: >> > Yuri, >> > >> > again i have error: >> > >> > [root@localhost usb]# ./configure CXXFLAGS="-fsanitize=address -ggdb" >> > checking for a BSD-compatible install... /usr/bin/install -c >> > checking whether build environment is sane... yes >> > checking for a thread-safe mkdir -p... /bin/mkdir -p >> > checking for gawk... gawk >> > checking whether make sets $(MAKE)... yes >> > checking for C++ compiler default output file name... >> > configure: error: in `/root/usb': >> > configure: error: C++ compiler cannot create executables >> > See `config.log' for more details. >> >> Ramin, >> >> First of all, you should add -fsanitize=address to CFLAGS, CXXFLAGS and >> LDFLAGS. >> >> If that does not help, you'll need to investigate why compiler test >> inside configure fails. You can find particular source code and >> command line options which cause your g++ compilation to abort in >> config.log. >> >> -Y > > -- > 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.
Re: c1plus: error: unrecognized command line option "-fsanitize=address"
On Fri, Jul 7, 2017 at 7:32 AM, Ramin Farajpour Cami wrote: > Yuri, > > again i have error: > > [root@localhost usb]# ./configure CXXFLAGS="-fsanitize=address -ggdb" > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for a thread-safe mkdir -p... /bin/mkdir -p > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for C++ compiler default output file name... > configure: error: in `/root/usb': > configure: error: C++ compiler cannot create executables > See `config.log' for more details. Ramin, First of all, you should add -fsanitize=address to CFLAGS, CXXFLAGS and LDFLAGS. If that does not help, you'll need to investigate why compiler test inside configure fails. You can find particular source code and command line options which cause your g++ compilation to abort in config.log. -Y -- 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.
Re: c1plus: error: unrecognized command line option "-fsanitize=address"
On Fri, Jul 7, 2017 at 6:41 AM, Ramin Farajpour Cami wrote: > Hi, > > I going to enable ASAN for my C++ program,i install libasan package, i get > this error message, i don't know how to resolve it? You need a newer compiler (gcc 4.7 at least, newer versions are better). -Y -- 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.
Re: How to enable GCC Asan dynamic shadow address?
On Mon, Jun 12, 2017 at 9:23 AM, steven shi wrote: > Hi Yuri, >> >> >> > Note that this flag only allows you to set fixed offset (in contrast, >> > dynamic offset allows the selection to be done at runtime). This may >> > or may not be enough for your case. > > > It is not perfect but really works for me. I have enabled gcc Kasan on my > Uefi firmware today :) Thank you! > I found I only need -fasan-shadow-offset for the fake stack red-zone in > fact. You know, my firmware is self-contained, and I implement all the > instrumentation library myself. So, no problem for the global variable and > heap buffer shadow memory mapping. Only the stack instrumentation > implementations are offered by compiler directly, which use the fixed offset > for the shadow memory. If I disable the stack buffer protection, I can use > both Asan and Kasan actually. Now, I have to set the -fasan-shadow-offset > with Kasan in build time to enable the stack buffer protection. It is not > perfect, but can work at least. > > BTW, since my Uefi firmware (a.k.a bios) use the same Kasan as Linux > kernel, I'm thinking whether it make sense if we enable the Kasan for the > whole Linux booting process. I could reserve a fixed range physical memory > as shadow memory according to config (dynamic is also ok for me, and I can > pass this info through Uefi interface to Linux). The Linux boot loader and > other kernel necessary modules can rebuild against the fixed shadow memory. > This way can let the Kasan work through the all the flow from memory HW is > ready to OS boot up. Does it make sense? Cc Andrew (he's KAsan implementor so has more informed opinion). -- 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.
Re: How to enable GCC Asan dynamic shadow address?
On Fri, Jun 9, 2017 at 5:51 AM, steven shi wrote: > Hi Yuri, > I'm trying to use the Kasan -fasan-shadow-offset option to work around the > Asan fixed shadow offset issue in gcc. I see you enabled it with this patch > https://patchwork.ozlabs.org/patch/402873/. If it works, I will replace the > Asan with Kasan in my firmware. Hi Steven, Note that this flag only allows you to set fixed offset (in contrast, dynamic offset allows the selection to be done at runtime). This may or may not be enough for your case. > I have two questions about Kasan: > 1. Besides the different run-time libraries for OS kernel and application, > is there other difference between Kasan and Asan, especially in the > instrumentation part? The one (and AFAIR only) change is that KAsan enables -fsanitize-recover=address by default (so it calls callbacks like __asan_report_storeX_noabort rather than __asan_report_storeX). > 2. I need to disable Kasan and -fasan-shadow-offset when compile my > instrumentation library (e.g. __asan_store8). How to force to > override/disable the -fasan-shadow-offset option if I have enabled it in > parent compile options? Now, I enable the -fno-sanitize=address > -fsanitize=kernel-address -fasan-shadow-offset=0x12345678 in parent compile > options for all modules, and add the -fno-sanitize=all to disable them in > instrumentation library. But the instrumentation library compile fail with > "cc1: error: -fasan-shadow-offset should only be used with > -fsanitize=kernel-address". How could I disable the > -fsanitize=kernel-address and -fasan-shadow-offset options together? I believe the best approach is simply to not enable Asan flags in instrumentation library. I.e. have CFLAGS_NO_ASAN and use that in instrumentation lib. BTW you don't need -fsanitize=address if you enabled -fsanitize=kernel-address. -Y -- 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.
Re: How to enable GCC Asan dynamic shadow address?
On Thu, Jun 1, 2017 at 11:51 AM, steven shi wrote: > Clang does works, at least for X64, and I have depended on it to enable the > LLVM Asan in my Uefi firmware. I can see the related patch is here: > https://reviews.llvm.org/D23354. Although this patch say it is for Windows > 64bits, but I think this patch is architecture independent, isn't it? > > The dynamic shadow address is very important for my firmware enabling, > because my firmware directly map virtual address to physical, and it doesn't > have sophisticated memory page managements. The Asan shadow memory is > allocated according to platform memory real size which could be different > from boot to boot and different from platform to platform. Set the dynamic > shadow address is the easiest way to enable Asan in my firmware. Yup, many people have expressed desire for dynamic shadow for similar reasons. > Does Asan developers have plan to port the D23354 patch to gcc main trunk? > The D23354 functionality already meet my firmware requirement. I guess it > should not too difficult. Cc Max. -Y -- 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.
Re: How to enable GCC Asan dynamic shadow address?
On Thu, Jun 1, 2017 at 9:40 AM, steven shi wrote: > Hello, > I'm trying to enable the gcc asan on my bare-mental firmware after llvm. I > need to set the GCC Asan shadow memory value dynamically, but I cannot find > proper gcc build option to do it. With Clang, I can use "-mllvm > -asan-force-dynamic-shadow=true" build option and assign the dynamic shadow > address in the module entry as "__asan_shadow_memory_dynamic_address = > DynamicShadowAddress". What's the equivalent build option in gcc? AFAIK this isn't supported in GCC and I'm not sure that this works in Clang either. AArch64 folks asked for dynamic shadow but Asan developers were concerned about potential performance implications so it went nowhere... -I -- 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.
Re: GetPreviousInstructionPc question
On Thu, Apr 20, 2017 at 10:53 AM, 'Dmitry Vyukov' via address-sanitizer wrote: > On Thu, Apr 20, 2017 at 11:50 AM, Yuri Gribov wrote: >> On Thu, Apr 20, 2017 at 10:20 AM, 'Dmitry Vyukov' via >> address-sanitizer wrote: >>> On Thu, Apr 20, 2017 at 11:11 AM, evgeny777 >>> wrote: >>>> Thanks for clarifying it, Dmitry. >>>> >>>> Here is piece of report I get: >>>> >>>> ==18244==ERROR: AddressSanitizer: heap-buffer-overflow on address >>>> 0x6020001a at pc 0x005a9cad bp 0x7ffc10528760 sp 0x7ffc10528740 >>>> WRITE of size 1 at 0x6020001a thread T0 >>>> #0 0x5a9cac (/home/evgeny/work/linker_scripts/asan/asan+0x5a9cac) >>>> #1 0x7f310488082f (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) >>>> #2 0x419498 (/home/evgeny/work/linker_scripts/asan/asan+0x419498) >>>> >>>> >>>> >>>> Below is the piece of disassembly of main : >>>> >>>> . >>>> 0x5a9ca8 <+136>: callq 0x56d9d0 ; >>>> ::__asan_report_store1(__sanitizer::uptr) at asan_rtl.cc:136 >>>> 0x5a9cad <+141>: xorl %eax, %eax >>>> . >>>> >>>> As you may noticed 0x5a9cac == (0x5a9cad - 1) >>> >>> >>> I think tsan prints unmodified PC and we should do the same in asan. >>> This also reliefs us from figuring out correct instruction length on >>> ARM/thumb/etc as nobody sees the modified PC. >> >> Hm, the unmodified PC will make symbolized stacktraces less readable. >> What's the problem with "-1"? Addr2line and other bintools work fine >> with it. > > I literally mean "print unmodified PC" (as a hex value). I am not > proposing to change how symbolization works. My understanding is that symbolization code symbolizes "pc-1" as well. If we keep symbolization code unchanged and only change printed hex value, this will probly cause offline symbolizer to behave differently from internal symbolizer. Actually the situation is even more interesting: on ARM we do pc & (~1) (not pc-1) to cancel out Thumb bit. >>>> On Thursday, April 20, 2017 at 12:01:25 PM UTC+3, Dmitry Vyukov wrote: >>>>> >>>>> On Thu, Apr 20, 2017 at 10:44 AM, evgeny777 wrote: >>>>> > I noticed that GetPreviousInstructionPc() function returns 'pc - 1' for >>>>> > both >>>>> > arm32 and arm64. >>>>> > This causes odd addresses to appear in stack traces, which is nonsense, >>>>> > as >>>>> > both arm32/64 instructions >>>>> > have 4 byte size and alignment. >>>>> > >>>>> > The x86 and x86_64 cases are even more confusing, because instruction >>>>> > length >>>>> > is not constant. What exactly this 'pc - 1' is expected to return? >>>>> > >>>>> > But even if one is able to get previous instruction address correctly he >>>>> > may >>>>> > still get confusing results. In case some instruction triggers >>>>> > hardware exception, its address will go to ASAN stack trace (via >>>>> > SlowUnwindStackWithContext). Returning address of previous instruction >>>>> > in such case can be extremely confusing. >>>>> > >>>>> > Is there any point in using this function? >>>>> >>>>> Hi, >>>>> >>>>> Yes, there is a very bold point in using this function. >>>>> Typically top frame PC is obtained with __builtin_return_address, >>>>> which means that it points to the next instruction after the call. And >>>>> we need to obtain debug info associated with the call instruction. To >>>>> achieve that we subtract 1 from PC. All symbolization code that we've >>>>> seen is fine with PC pointing into a middle of an instruction. >>>>> >>>>> Now, if we print pc-1 in reports (do we?), then it's a bug. We need to >>>>> print unaltered PC in reports. >>>>> >>>>> Re hardware exceptions. This needs to be fixed. A trivial change would >>>>> be to add 1 to PCs pointing to faulting instruction. Then >>>>> GetPreviousInstructionPc will offset this and we get correct debug >>>>> info. However, then we will print incorrect PC in report. So a proper >>>&g
Re: GetPreviousInstructionPc question
On Thu, Apr 20, 2017 at 10:20 AM, 'Dmitry Vyukov' via address-sanitizer wrote: > On Thu, Apr 20, 2017 at 11:11 AM, evgeny777 wrote: >> Thanks for clarifying it, Dmitry. >> >> Here is piece of report I get: >> >> ==18244==ERROR: AddressSanitizer: heap-buffer-overflow on address >> 0x6020001a at pc 0x005a9cad bp 0x7ffc10528760 sp 0x7ffc10528740 >> WRITE of size 1 at 0x6020001a thread T0 >> #0 0x5a9cac (/home/evgeny/work/linker_scripts/asan/asan+0x5a9cac) >> #1 0x7f310488082f (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) >> #2 0x419498 (/home/evgeny/work/linker_scripts/asan/asan+0x419498) >> >> >> >> Below is the piece of disassembly of main : >> >> . >> 0x5a9ca8 <+136>: callq 0x56d9d0 ; >> ::__asan_report_store1(__sanitizer::uptr) at asan_rtl.cc:136 >> 0x5a9cad <+141>: xorl %eax, %eax >> . >> >> As you may noticed 0x5a9cac == (0x5a9cad - 1) > > > I think tsan prints unmodified PC and we should do the same in asan. > This also reliefs us from figuring out correct instruction length on > ARM/thumb/etc as nobody sees the modified PC. Hm, the unmodified PC will make symbolized stacktraces less readable. What's the problem with "-1"? Addr2line and other bintools work fine with it. >> On Thursday, April 20, 2017 at 12:01:25 PM UTC+3, Dmitry Vyukov wrote: >>> >>> On Thu, Apr 20, 2017 at 10:44 AM, evgeny777 wrote: >>> > I noticed that GetPreviousInstructionPc() function returns 'pc - 1' for >>> > both >>> > arm32 and arm64. >>> > This causes odd addresses to appear in stack traces, which is nonsense, >>> > as >>> > both arm32/64 instructions >>> > have 4 byte size and alignment. >>> > >>> > The x86 and x86_64 cases are even more confusing, because instruction >>> > length >>> > is not constant. What exactly this 'pc - 1' is expected to return? >>> > >>> > But even if one is able to get previous instruction address correctly he >>> > may >>> > still get confusing results. In case some instruction triggers >>> > hardware exception, its address will go to ASAN stack trace (via >>> > SlowUnwindStackWithContext). Returning address of previous instruction >>> > in such case can be extremely confusing. >>> > >>> > Is there any point in using this function? >>> >>> Hi, >>> >>> Yes, there is a very bold point in using this function. >>> Typically top frame PC is obtained with __builtin_return_address, >>> which means that it points to the next instruction after the call. And >>> we need to obtain debug info associated with the call instruction. To >>> achieve that we subtract 1 from PC. All symbolization code that we've >>> seen is fine with PC pointing into a middle of an instruction. >>> >>> Now, if we print pc-1 in reports (do we?), then it's a bug. We need to >>> print unaltered PC in reports. >>> >>> Re hardware exceptions. This needs to be fixed. A trivial change would >>> be to add 1 to PCs pointing to faulting instruction. Then >>> GetPreviousInstructionPc will offset this and we get correct debug >>> info. However, then we will print incorrect PC in report. So a proper >>> fix would be to augment all stack traces with a flag saying if top PC >>> needs to be adjusted during symbolization or not. >> >> -- >> 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.
Re: GetPreviousInstructionPc question
On Thu, Apr 20, 2017 at 9:44 AM, evgeny777 wrote: > I noticed that GetPreviousInstructionPc() function returns 'pc - 1' for both > arm32 and arm64. > This causes odd addresses to appear in stack traces, which is nonsense, as > both arm32/64 instructions > have 4 byte size and alignment. Thumb instructions may have 2 byte size. Parsing instruction to determine size may not justify complexity. -I -- 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.
Re: ASN for MIPS with either clang or gcc
On Wed, Dec 14, 2016 at 12:15 PM, Maxim Ostapenko wrote: > Hi, > > 2016-12-14 10:23 GMT+03:00 Park Kit : >> >> Hi Maxim, >> >> Sorry for a slow response since I took some time to check ASAN's working >> on a target platform. Thanks to your help, have managed to build ASAN with >> uclibc and builds fine. However, gets a seg fault when runs it on a target: >> >> #1 0x2aabf414 in __pthread_initialize_minimal_internal () from >> /home/xxx/asan/mips-libs-from-build/libpthread.so.0 >> #2 0x2ab36874 in __uClibc_init () from >> /home/xxx/asan/mips-libs-from-build/libc.so.0 >> >> Tried different uclibc version but no luck yet. Will try more and keep you >> updated on that. >> > > Hm, I don't know whether anyone tried to use ASan with uclibc before (AFAIK > sanitizer runtime quite tightly connected to Glibc internals). I suggest you > to use Glibc. If this isn't an option for you, then... good luck! Supporting other libcs is interesting for embedded targets but I'd not recommend to start with this until you have Glibc working. As Max pointed out porting to new libc may be a lot of work (especially thread-local storage internals, etc.). >> Many thanks and >> >> Щастлива Коледа > > > Merry Christmas! :) > > -Maxim > >> >> >> >> Kit >> >> >> >> Many thanks, >> Kit >> https://kitpark.slack.com/ >> -- >> Sorry for a terse reply or typo as sent from a mobile. >> >> 2016-11-28 15:46 GMT+00:00 Park Kit : >>> >>> Ah, sorry for that since I have missed that. Will give it try and update >>> you on that. >>> >>> Many thanks, >>> Kit >>> https://kitpark.slack.com/ >>> -- >>> Sorry for a terse reply or typo as sent from a mobile. >>> >>> 2016-11-28 14:42 GMT+00:00 Maxim Ostapenko : 2016-11-28 17:38 GMT+03:00 Park Kit : > > Hi Maxim, > > Once done 3) make - j12 from step 3, run 'make install' which is > different from step 2 in the reference. Have set rpath to dismiss link > errors: > > > /home/NDS-UK/kyoupark/asn/install-4.8.2/bin/../lib/gcc/mips-linux/4.8.2/../../../../mips-linux/bin/ld: > warning: libpthread.so.0, needed by > /home/NDS-UK/kyoupark/asn/install-4.8.2/bin/../lib/gcc/mips-linux/4. > 8.2/../../../../mips-linux/lib/libasan.so, not found (try using -rpath > or -rpath-link) > > /home/NDS-UK/kyoupark/asn/install-4.8.2/bin/../lib/gcc/mips-linux/4.8.2/../../../../mips-linux/bin/ld: > warning: libdl.so.2, needed by > /home/NDS-UK/kyoupark/asn/install-4.8.2/bin/../lib/gcc/mips-linux/4.8.2/. > ./../../../mips-linux/lib/libasan.so, not found (try using -rpath or > -rpath-link) > > /home/NDS-UK/kyoupark/asn/install-4.8.2/bin/../lib/gcc/mips-linux/4.8.2/../../../../mips-linux/bin/ld: > warning: libstdc++.so.6, needed by > /home/NDS-UK/kyoupark/asn/install-4.8.2/bin/../lib/gcc/mips-linux/4.8 > .2/../../../../mips-linux/lib/libasan.so, not found (try using -rpath > or -rpath-link) > > /home/NDS-UK/kyoupark/asn/install-4.8.2/bin/../lib/gcc/mips-linux/4.8.2/../../../../mips-linux/bin/ld: > warning: libm.so.6, needed by > /home/NDS-UK/kyoupark/asn/install-4.8.2/bin/../lib/gcc/mips-linux/4.8.2/.. > /../../../mips-linux/lib/libasan.so, not found (try using -rpath or > -rpath-link) > > /home/NDS-UK/kyoupark/asn/install-4.8.2/bin/../lib/gcc/mips-linux/4.8.2/../../../../mips-linux/lib/libasan.so: > undefined reference to `pthread_attr_getstack@GLIBC_2.2' > > /home/NDS-UK/kyoupark/asn/install-4.8.2/bin/../lib/gcc/mips-linux/4.8.2/../../../../mips-linux/lib/libasan.so: > undefined reference to `pthread_setspecific@GLIBC_2.0' > > /home/NDS-UK/kyoupark/asn/install-4.8.2/bin/../lib/gcc/mips-linux/4.8.2/../../../../mips-linux/lib/libasan.so: > undefined reference to `dlsym@GLIBC_2.0' > > /home/NDS-UK/kyoupark/asn/install-4.8.2/bin/../lib/gcc/mips-linux/4.8.2/../../../../mips-linux/lib/libasan.so: > undefined reference to `pthread_key_create@GLIBC_2.0' > > /home/NDS-UK/kyoupark/asn/install-4.8.2/bin/../lib/gcc/mips-linux/4.8.2/../../../../mips-linux/lib/libasan.so: > undefined reference to `pthread_getspecific@GLIBC_2.0' > > /home/NDS-UK/kyoupark/asn/install-4.8.2/bin/../lib/gcc/mips-linux/4.8.2/../../../../mips-linux/lib/libasan.so: > undefined reference to `pthread_getattr_np@GLIBC_2.2.3' > collect2: error: ld returned 1 exit status > > However, still gets this when do: > > $ ./bin/mips-linux-gcc-4.8.2 -fsanitize=address > -Wl,-rpath=/home/NDS-UK/kyoupark/asn/install-4.8.2/mips-linux/lib > ~/asn/x.c > /home/nds-uk/kyoupark/asn/x.c:1:0: warning: -fsanitize=address not > supported for this target [enabled by default] > #include > ^ > $ Yes, as I mentioned earlier in mail just add -fstack-protector flag: > This is weird, but for some reason GCC folks use this flag to control > FRAME_GROWS_DOWNWARD macro om MIPS. > GCC's ASan doesn't s
Re: Proposal to add support for structure inner elements in Asan
Just curious, why did you chose to break ABI rather than reuse natural padding? As for complexity - was it caused by user code relying on implementation details (e.g. exact struct layout) or something else? On Fri, Dec 2, 2016 at 8:18 AM, Konstantin Serebryany wrote: > This is much harder than it sounds. > I've made an attempt ~2 years ago and it almost, but not quite entirely, > worked > https://github.com/google/sanitizers/wiki/AddressSanitizerIntraObjectOverflow > (Only for non POD objects in C++, so it won't directly apply to C at all) > > And I totally agree that this is a large missing piece in asan. > > --kcc > > On Thu, Dec 1, 2016 at 9:31 PM, Yuri Gribov wrote: >> >> On Fri, Dec 2, 2016 at 7:22 AM, Yuri Gribov wrote: >> > On Fri, Dec 2, 2016 at 6:35 AM, Maxim Ostapenko >> > wrote: >> >> Hi, >> >> >> >> 02 Дек 2016 г. 7:30 пользователь "steven shi" >> >> написал: >> >>> >> >>> Hello, >> >>> With the experts' help in this community, I've enabled the Asan for >> >>> global >> >>> and stack buffer in my bare-mental platform firmware, thanks a lot. >> >>> But I find the current Asan doesn't support to protect the structure >> >>> inner >> >>> elements, E.g. the global_array[11] in below code. Unfortunately, most >> >>> of >> >>> important data are defined through structure in my firmware, and if >> >>> the Asan >> >>> doesn't support to protect structure inner elements, most of my data >> >>> memory >> >>> access will not be protected by Asan. So, could we let Asan support >> >>> structure inner elements? >> >>> >> >>> Well, I understand it is not safe to just instrument red-zone between >> >>> structure inner elements like current Asan does on global variable. >> >>> We also >> >>> need to handle the sizeof(), offsetof() macro, the alignment pragma, >> >>> and >> >>> maybe others. Could we extend Asan scope beyond IR to Clang front-end >> >>> to do >> >>> some source-to-source conversion to handle these issue? E.g. for no >> >>> alignment enforced structure, replace the structure inner elements >> >>> with >> >>> red-zone instrumented version, and let the sizeof() be-aware of the >> >>> size >> >>> change. Is it possible? >> >> >> >> Won't this break separate sanitization? E.g. if I have libfoo.so that >> >> has >> >> struct Foo as part of its ABI and I want to test it with ASan, I'll >> >> need to >> >> recompile not only libfoo.so, but all dependent libraries too to make >> >> sure >> >> they caught up the changed layout of struct Foo. This sounds like a bad >> >> idea >> >> for me. >> >> Or maybe I've just missed something? >> > >> > I think Steven's code is self-contained so he does not care. Also note >> > that you can get away without breaking ABI but just poisoning natural >> > padding in structures. I guess the main problem with sanitizing >> > structs is that they are often passed to "low-level" >> > memcmp/memcpy/memset/etc. functions which would result in spurious >> > errors. >> >> Also in C you don't get type information as easily as with C++'s new >> operator. Structs are allocated as untyped memory buffers via malloc >> and then casted to appropriate type. Compiler will have to figure out >> that newly allocated char*-pointer is meant to point to struct (which >> is not always possible e.g. if malloc happens in a different function >> in separate translation unit). >> >> -I >> >> -- >> 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.
Re: Proposal to add support for structure inner elements in Asan
On Fri, Dec 2, 2016 at 7:22 AM, Yuri Gribov wrote: > On Fri, Dec 2, 2016 at 6:35 AM, Maxim Ostapenko wrote: >> Hi, >> >> 02 Дек 2016 г. 7:30 пользователь "steven shi" >> написал: >>> >>> Hello, >>> With the experts' help in this community, I've enabled the Asan for global >>> and stack buffer in my bare-mental platform firmware, thanks a lot. >>> But I find the current Asan doesn't support to protect the structure inner >>> elements, E.g. the global_array[11] in below code. Unfortunately, most of >>> important data are defined through structure in my firmware, and if the Asan >>> doesn't support to protect structure inner elements, most of my data memory >>> access will not be protected by Asan. So, could we let Asan support >>> structure inner elements? >>> >>> Well, I understand it is not safe to just instrument red-zone between >>> structure inner elements like current Asan does on global variable. We also >>> need to handle the sizeof(), offsetof() macro, the alignment pragma, and >>> maybe others. Could we extend Asan scope beyond IR to Clang front-end to do >>> some source-to-source conversion to handle these issue? E.g. for no >>> alignment enforced structure, replace the structure inner elements with >>> red-zone instrumented version, and let the sizeof() be-aware of the size >>> change. Is it possible? >> >> Won't this break separate sanitization? E.g. if I have libfoo.so that has >> struct Foo as part of its ABI and I want to test it with ASan, I'll need to >> recompile not only libfoo.so, but all dependent libraries too to make sure >> they caught up the changed layout of struct Foo. This sounds like a bad idea >> for me. >> Or maybe I've just missed something? > > I think Steven's code is self-contained so he does not care. Also note > that you can get away without breaking ABI but just poisoning natural > padding in structures. I guess the main problem with sanitizing > structs is that they are often passed to "low-level" > memcmp/memcpy/memset/etc. functions which would result in spurious > errors. Also in C you don't get type information as easily as with C++'s new operator. Structs are allocated as untyped memory buffers via malloc and then casted to appropriate type. Compiler will have to figure out that newly allocated char*-pointer is meant to point to struct (which is not always possible e.g. if malloc happens in a different function in separate translation unit). -I -- 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.
Re: Proposal to add support for structure inner elements in Asan
On Fri, Dec 2, 2016 at 6:35 AM, Maxim Ostapenko wrote: > Hi, > > 02 Дек 2016 г. 7:30 пользователь "steven shi" > написал: >> >> Hello, >> With the experts' help in this community, I've enabled the Asan for global >> and stack buffer in my bare-mental platform firmware, thanks a lot. >> But I find the current Asan doesn't support to protect the structure inner >> elements, E.g. the global_array[11] in below code. Unfortunately, most of >> important data are defined through structure in my firmware, and if the Asan >> doesn't support to protect structure inner elements, most of my data memory >> access will not be protected by Asan. So, could we let Asan support >> structure inner elements? >> >> Well, I understand it is not safe to just instrument red-zone between >> structure inner elements like current Asan does on global variable. We also >> need to handle the sizeof(), offsetof() macro, the alignment pragma, and >> maybe others. Could we extend Asan scope beyond IR to Clang front-end to do >> some source-to-source conversion to handle these issue? E.g. for no >> alignment enforced structure, replace the structure inner elements with >> red-zone instrumented version, and let the sizeof() be-aware of the size >> change. Is it possible? > > Won't this break separate sanitization? E.g. if I have libfoo.so that has > struct Foo as part of its ABI and I want to test it with ASan, I'll need to > recompile not only libfoo.so, but all dependent libraries too to make sure > they caught up the changed layout of struct Foo. This sounds like a bad idea > for me. > Or maybe I've just missed something? I think Steven's code is self-contained so he does not care. Also note that you can get away without breaking ABI but just poisoning natural padding in structures. I guess the main problem with sanitizing structs is that they are often passed to "low-level" memcmp/memcpy/memset/etc. functions which would result in spurious errors. -- 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.
Re: ASAN without pthread support
FYI there have been many attempts in applying ASan to bare-metal and at least some were successful. E.g. http://events.linuxfoundation.org/sites/events/files/slides/Alexander_Popov-KASan_in_a_Bare-Metal_Hypervisor_0.pdf and also grep for "bare-metal" and similar stuff in this group. Given that this has been asked many times already, maybe makes sense to add a note to FAQ? On Fri, Oct 21, 2016 at 9:37 PM, Konstantin Serebryany wrote: > Out of the box we don't have support for your use case. > The easiest for you would be to rip off everything you don't have and > rebuild the asan run-time. > > --kcc > > On Fri, Oct 21, 2016 at 7:47 AM, Nikhil Gupta wrote: >> >> Hi, >> >> I'm working on a project that uses ASAN on embedded arm devices. The >> operating system environment is a bare-metal OS with no pthread (TLS) >> support and no POSIX syscalls. >> >> I was wondering if I can >> >> 1) Get ASAN to build without pthreads (It has been discussed before, but >> there was no explanation on how its being done) - Will i have to change the >> sources to get rid of all the thread code, or is there just a switch that I >> can add while building? >> >> 2) Build ASAN for aarch64 but without posix syscalls => some methods like >> 'abort' and 'syslog' do exist, but I certainly don't have features like >> 'dlsym'. >> >> Thank you in advance! >> >> -Nikhil >> >> -- >> 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.
Re: Any way to make ASAN/UBSAN continue after the first error?
UBSan should behave like this by default and for ASan you'll need -fsanitize-recover=address (see the very first question in FAQ at https://github.com/google/sanitizers/wiki/AddressSanitizer for details). Note that you'll need recent GCC and Clang as the feature is quite new. On Mon, Sep 12, 2016 at 5:33 PM, David Barto wrote: > I've got a complex database application and we have enough problems with it > that one of the team members would like to know if it is possible to > continue after ASAN/UBSAN detects an error. Mostly for overnight testing so > we can gather all the errors and the proceed to fix them in one swat. > > David > > -- > 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.
Re: [Asan] undefined reference to runtime function
Pierre,
In this case it seems that you need to do some additional actions to
export your new symbol from runtime library. I remember that it hides
(i.e. does not export) most of it's symbols by default so you need to
whitelist your new function somewhere.
On Fri, May 27, 2016 at 3:51 PM, Pierre Gagelin
wrote:
> Hi,
>
> I am trying to implement a runtime to an existant LLVM FunctionPass. I
> followed your design and instrumented the code with call to a runtime
> function but this function seems to be undefined. Let me be more specific:
>
> - I added a function in asan_rtl.cc with quite nothing in it (I am not even
> sure what Report does but I though it might print something... the point is
> to call this function with instrumentation):
>
> void __bounds_init() {
> Report("Runtime Library accessed!");
> }
>
> - I added an doInitialization function to my FunctionPass in order to
> retrieve a pointer to the __bounds_init function:
>
> bool BoundsChecking::doInitialization(Module &M) {
> if (runTimeEnabled) return false;
> runTimeEnabled = true;
> errs() << "Initialization of the FunctionPass...\n";
> std::tie(ctor_func, init_func) =
> createSanitizerCtorAndInitFunctions(
> M, "", "__bounds_init",
> /*InitArgTypes=*/{}, /*InitArgs=*/{}, "check_v1");
> if(init_func) errs() << "Initialization succeded!\n";
> return true;
> }
> Maybe the call to createSanitizerCtorAndInitFunctions isn't correctly done?
> It seems that the function only needs a init name. As I don't need a
> constructor I let the name empty... I didn't know what to put into the check
> version argument so I put a random name "check_v1"
>
> - Then I made the call generation with the following for each function just
> to try:
>
> IRBuilder<> IRB(&F.front(), F.front().begin());
> IRB.CreateCall(init_func, {});
>
> I got no errors when building LLVM with thoses changes but when I generate
> the executable with clang -fsanitize=bounds (this is the way to call
> BoundsChecking) the linker (so, after optimizations) fails and gives several
> " undefined reference to `__bounds_init' ".
>
> I suppose I missed something but I dont know what. I looked at the IR
> generated with -S -emit-llvm, and there are several calls to __bounds_init
> and a declaration but no define:
>
> call void @__bounds_init() #3
> declare void @__bounds_init()
>
> Anyone knows how I should do to be able to link the function created in
> asan_rtl.cc to the code being created? Or where to look in asan sources to
> find an answer? Feel free to ask me details, it's possible I am not being
> clear in what I exposed to you?
>
> Thanks a lot for you time,
> Pierre
>
> --
> 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.
Re: UBSan suppressions on embedded system
On Mon, May 9, 2016 at 10:35 AM, 'Ilya' via address-sanitizer wrote: > >> Worst case you could wrap problematic code in #ifdef >> __SANITIZE_UNDEFINED__ and provide dedicated implementation. What's >> the problem with packed stuff though? > > > Yep, but I'd like to avoid that if possible :) Yeah... > The packed structures cause "misaligned pointer access". Hm, now that sounds as a bug in implementation. Could you file it (with repro) to GCC BZ? > -- > 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.
Re: UBSan suppressions on embedded system
On Tue, May 3, 2016 at 8:49 PM, Konstantin Serebryany
wrote:
>
>
> On Tue, May 3, 2016 at 1:03 AM, 'Ilya' via address-sanitizer
> wrote:
>>
>> Hello everybody,
>> first of all: thanks for reading. I have questions regarding the
>> UndefinedBehaviourSanitizer and didn't know where else to post them.
>
>
> Usually, ubsan-related questions get answered at llvm-...@lists.llvm.org,
> we we can reply too :)
>
>
>>
>>
>> I am currently working on an embedded system project, porting the UBSan
>> RTL (GCC) to work with our stuff. After lots of ripping out this works, with
>> a few side effects though (for example no support for flags in the RTL
>> (yet)). To make this work in a long perspective I'd like to get rid of all
>> current ubs. However, since low-level stuff is low-level, we have some
>> occurrences of ub which are to be accepted and will last (a few null pointer
>> dereferences, packed structures, etc..).
Worst case you could wrap problematic code in #ifdef
__SANITIZE_UNDEFINED__ and provide dedicated implementation. What's
the problem with packed stuff though?
>> I figured out how to get rid of
>> some warnings (function-wise attributes),
>
>
> You mean, __attribute__((no_sanitizer("your-but-type"))), right?
> That's the best.
>
>>
>> but this won't help with for example the packed structures.
>>
>> So I want to suppress the warnings in a few occasions. I however can't
>> figure out, how exactly issue suppression (other than function-wise via
>> attributes) works in the UBSan. I do see the suppression context being
>> created, with the file being parsed. However the only usage of that in the
>> UBSan I can find is the "IsVptrCheckSuppressed" function.
>>
>> So, main questions:
>> Which file described in the Clang documentation is being parsed into the
>> suppression context? (fsanitize-blacklist, or
>> UBSAN_OPTIONS=suppressions=MyUBSan.supp ?)
>
>
> fsanitize-blacklist is a compile-time suppression mechanism -- the code in
> the blacklist is not instrumented.
> This would have been preferable, but AFIACT, gcc does not support this flag.
> (correct me if I am wrong).
>
>
>>
>> Is the suppression context used in another way that I don't see?
>>
>> And how is the other file used then?
>
>
> I am not sure I understand your question about
> UBSAN_OPTIONS=suppressions=MyUBSan.supp
> If you can provide a small example where something does not work as expected
> (with the fresh clang) we can take a look.
> Note that UBSAN_OPTIONS=suppressions=... is a run-time option and if you hit
> the bug you are going to suppress very often
> the suppression will slow down the run significantly.
>
> --kcc
>>
>>
>> Thank you, for taking the time and the great tools,
>> Ilya
>>
>> --
>> 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.
Re: glibc, asan and libfuzzer
On Wed, Feb 17, 2016 at 10:52 PM, Konstantin Serebryany
wrote:
>
>
> On Wed, Feb 17, 2016 at 11:50 AM, Yuri Gribov wrote:
>>
>> On Wed, Feb 17, 2016 at 5:45 PM, Konstantin Serebryany
>> wrote:
>> > +Roland
>> >
>> > The only good solution is to have the upstream glibc fixed and
>> > maintained in
>> > this state.
>> > (We need to make it build with clang+asan and have the bots that verify
>> > it
>> > still works on every commit).
>>
>> Why not sanitize it with GCC though?
>
>
> You can, it's not much simpler. I've tried.
> You will avoid the clang-specific problems, but you still can not build the
> entire thing with asan.
> But if you want to fuzz glibc, you'll need the coverage instrumentation.
> GCC has the one that we use in the kernel, but not the one we use with
> libFuzzer.
I guess it would be much easier to port coverage to GCC than to build
Glibc and convince maintainers to take Clang-specific patches ;)
>> > Roland wanted to try doing that; not sure what's the current state.
>> > Anyway, I think this should be discussed at libc-al...@sourceware.org
>> >
>> >
>> > On Wed, Feb 17, 2016 at 3:21 AM, Hanno Böck wrote:
>> >>
>> >> Hi,
>> >>
>> >> I thought given the current issues with glibc I'd bring that up.
>> >>
>> >> A while ago I had a conversation with Kostya about building glibc with
>> >> asan. I think it can be summed up as "it's possible, but requires lots
>> >> of manual work and is complicated".
>> >>
>> >> The publicly available documentation is currently a wiki page listing
>> >> problems trying to build glibc with clang
>> >> https://sourceware.org/glibc/wiki/GlibcMeetsClang
>> >> and some reports about fuzzing done with libfuzzer
>> >> https://sourceware.org/glibc/wiki/FuzzingLibc
>> >>
>> >> As far as I can see there is currently no public documentation how one
>> >> would compile glibc with asan (and/or libfuzzer).
>> >
>> >
>> > True. My current instructions are pretty involved.
>> > Let me dump them here FTR (last checked 1 month ago).
>> >
>> > First, build glibc in a usual way:
>> >
>> > wget http://ftp.gnu.org/gnu/glibc/glibc-2.22.tar.bz2
>> > tar xf glibc-2.22.tar.bz2
>> > (
>> > mkdir glibc_build_plain
>> > cd glibc_build_plain/
>> > ../glibc-2.22/configure --prefix=`pwd`/../glibc_inst_plain && make -j &&
>> > make install
>> > )
>> >
>> > Grab fresh clang.
>> > Revert clang r255371, or apply this patch. Then rebuild clang.
>> > (This is a long and sad story... Hopefully Roland will fix it)
>> >
>> > --- llvm/tools/clang/lib/Sema/SemaDecl.cpp (revision 257672)
>> > +++ llvm/tools/clang/lib/Sema/SemaDecl.cpp (working copy)
>> > @@ -2381,7 +2381,7 @@
>> >// Attributes declared post-definition are currently ignored.
>> >checkNewAttributesAfterDef(*this, New, Old);
>> >
>> > - if (AsmLabelAttr *NewA = New->getAttr()) {
>> > + if (0) if (AsmLabelAttr *NewA = New->getAttr()) {
>> > if (AsmLabelAttr *OldA = Old->getAttr()) {
>> >if (OldA->getLabel() != NewA->getLabel()) {
>> > // This redeclaration changes __asm__ label.
>> >
>> >
>> > Now, download the attached clang-gcc-wrapper.py and put it into ./
>> >
>> > Build using clang-gcc-wrapper.py instead of gcc:
>> > (
>> > mkdir glibc_build_clang # name is important for clang-gcc-wrapper.py
>> > cd glibc_build_clang
>> > CC=`pwd`/../clang-gcc-wrapper.py ../glibc-2.22/configure
>> > --prefix=`pwd`/../glibc_inst_clang
>> > make -k # -j
>> > )
>> >
>> > The build will fail to complete (thus -k), but it will produce all
>> > needed
>> > .so
>> > files.
>> > Now, copy .so files to glibc_build_plain/:
>> >
>> > for f in librt libdl libresolv libpthread libcrypt libm; do cp -v
>> > glibc_build_clang/*/$f.so glibc_inst_plain/lib/$f-2.22.so; done
>> > cp glibc_build_clang/libc.so glibc_inst_plain/lib/libc-2.22.so
>> >
>> > Note: if you are building version other than 22, change the names.
>> >
>> >
>> > Now, verify that you have proper instrumentation.
>> >
>> > % cat use-after-free-on-gethostbyname.c
>> > #includ
Re: glibc, asan and libfuzzer
On Wed, Feb 17, 2016 at 5:45 PM, Konstantin Serebryany
wrote:
> +Roland
>
> The only good solution is to have the upstream glibc fixed and maintained in
> this state.
> (We need to make it build with clang+asan and have the bots that verify it
> still works on every commit).
Why not sanitize it with GCC though?
> Roland wanted to try doing that; not sure what's the current state.
> Anyway, I think this should be discussed at libc-al...@sourceware.org
>
>
> On Wed, Feb 17, 2016 at 3:21 AM, Hanno Böck wrote:
>>
>> Hi,
>>
>> I thought given the current issues with glibc I'd bring that up.
>>
>> A while ago I had a conversation with Kostya about building glibc with
>> asan. I think it can be summed up as "it's possible, but requires lots
>> of manual work and is complicated".
>>
>> The publicly available documentation is currently a wiki page listing
>> problems trying to build glibc with clang
>> https://sourceware.org/glibc/wiki/GlibcMeetsClang
>> and some reports about fuzzing done with libfuzzer
>> https://sourceware.org/glibc/wiki/FuzzingLibc
>>
>> As far as I can see there is currently no public documentation how one
>> would compile glibc with asan (and/or libfuzzer).
>
>
> True. My current instructions are pretty involved.
> Let me dump them here FTR (last checked 1 month ago).
>
> First, build glibc in a usual way:
>
> wget http://ftp.gnu.org/gnu/glibc/glibc-2.22.tar.bz2
> tar xf glibc-2.22.tar.bz2
> (
> mkdir glibc_build_plain
> cd glibc_build_plain/
> ../glibc-2.22/configure --prefix=`pwd`/../glibc_inst_plain && make -j &&
> make install
> )
>
> Grab fresh clang.
> Revert clang r255371, or apply this patch. Then rebuild clang.
> (This is a long and sad story... Hopefully Roland will fix it)
>
> --- llvm/tools/clang/lib/Sema/SemaDecl.cpp (revision 257672)
> +++ llvm/tools/clang/lib/Sema/SemaDecl.cpp (working copy)
> @@ -2381,7 +2381,7 @@
>// Attributes declared post-definition are currently ignored.
>checkNewAttributesAfterDef(*this, New, Old);
>
> - if (AsmLabelAttr *NewA = New->getAttr()) {
> + if (0) if (AsmLabelAttr *NewA = New->getAttr()) {
> if (AsmLabelAttr *OldA = Old->getAttr()) {
>if (OldA->getLabel() != NewA->getLabel()) {
> // This redeclaration changes __asm__ label.
>
>
> Now, download the attached clang-gcc-wrapper.py and put it into ./
>
> Build using clang-gcc-wrapper.py instead of gcc:
> (
> mkdir glibc_build_clang # name is important for clang-gcc-wrapper.py
> cd glibc_build_clang
> CC=`pwd`/../clang-gcc-wrapper.py ../glibc-2.22/configure
> --prefix=`pwd`/../glibc_inst_clang
> make -k # -j
> )
>
> The build will fail to complete (thus -k), but it will produce all needed
> .so
> files.
> Now, copy .so files to glibc_build_plain/:
>
> for f in librt libdl libresolv libpthread libcrypt libm; do cp -v
> glibc_build_clang/*/$f.so glibc_inst_plain/lib/$f-2.22.so; done
> cp glibc_build_clang/libc.so glibc_inst_plain/lib/libc-2.22.so
>
> Note: if you are building version other than 22, change the names.
>
>
> Now, verify that you have proper instrumentation.
>
> % cat use-after-free-on-gethostbyname.c
> #include
> #include
> int main() {
> char *x = (char*)malloc(10);
> free(x);
> gethostbyname(x);
> }
>
> % export SYSROOT=`pwd`/glibc_inst_plain/
> % clang -g -fsanitize=address use-after-free-on-gethostbyname.c \
> -Wl,-rpath=$SYSROOT/lib -Wl,-dynamic-linker=$SYSROOT/lib/ld-2.22.so
> % ASAN_OPTIONS=replace_str=0 ./a.out
>
> You should get
>
> ==25426==ERROR: AddressSanitizer: heap-use-after-free on address
> 0x6020eff0
> at pc 0x7f65db399e2d bp 0x7ffe902a0c50 sp 0x7ffe902a0c48
> READ of size 1 at 0x6020eff0 thread T0
> #0 0x7f65db399e2c in __GI___libc_res_nsearch
> glibc-2.22/resolv/res_query.c:356:18
>
>
> NOTE: you should get the first frame inside the glibc code, not inside asan
> interceptor. Compare to running w/o ASAN_OPTIONS=replace_str=0:
>
> #0 0x49a490 in index
> llvm/projects/compiler-rt/lib/asan/asan_interceptors.cc:470:5
>
> Finally, have a look at clang-gcc-wrapper.py to make sure you instrument all
> the
> code you need:
>
> asan_whitelist = [#"posix",
> "string", "wcsmbs", "wctype", "stdio-common", "time",
> "resolv"]
>
> Some parts of glibc still don't build with clang, so we are using a
> whitelist.
>
>
> --kcc
>
>>
>>
>> I think it is a major drawback of security analysis of glibc that many
>> common tools don't work on it and it'd be great if this area could be
>> improved. So the question is: How realistic would it be to make this
>> stuff more easily accessible?
>>
>> --
>> Hanno Böck
>> https://hboeck.de/
>>
>> mail/jabber: ha...@hboeck.de
>> GPG: BBB51E42
>>
>> --
>> 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 receiv
Re: configure scripts, pthread detection and asan
On Wed, Jan 20, 2016 at 8:44 PM, Konstantin Serebryany wrote: > > > On Wed, Jan 20, 2016 at 9:40 AM, Hanno Böck wrote: >> >> On Wed, 20 Jan 2016 09:14:53 -0800 >> Konstantin Serebryany wrote: >> >> > Are you talking about gcc or clang? >> >> gcc in this case. >> >> > In gcc looks like this does not happen. >> > (I'd say this needs to be fixed in gcc, just for compatibility, at >> > least) >> >> Okay, so should we open a bug report for gcc? > > > It won't hurt. I don't know what the gcc folks think about this, > but once we file a bug we'll know. :) > >> >> Anyway, given that the gcc-deployment-to-distro process is taking quite >> a while I wonder if corresponding configure changes should be attempted >> anyway. > > > As Dmitry suggested, if you always use "-fsanitize=address -lpthread" it > will work with both clang and gcc. Or rther s/-lpthread/-pthread/ > So it might be the simplest fix (no need to change the config scripts) > Just document it that -lpthread is there due to the gcc bug/feature. > >> >> >> -- >> Hanno Böck >> http://hboeck.de/ >> >> mail/jabber: ha...@hboeck.de >> GPG: BBB51E42 >> >> -- >> 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.
Re: Stack oob not detected with -O2
On Sun, Jan 17, 2016 at 11:56 AM, John Regehr wrote:
> Would it be possible to add an option specifying that the asan
> instrumentation is done before running any optimizers? Presumably this would
> offer an interesting tradeoff where there transparent bugs aren't missed but
> performance is still much better than -O0.
This isn't so easy with GCC which tends to start "optimizing" code
long before GIMPLE. AFAIR in my case erroneous memory access was
removed during parsing.
> On Friday, January 15, 2016 at 5:58:36 PM UTC+1, kcc wrote:
>>
>> +john
>>
>> Yea, if optimizations get rid of the buggy code before asan gets a chance
>> to instrument it -- the bug will be missed.
>> We've seen it before in many *trivial* examples.
>> It's unclear how many bugs we miss this way; some for sure.
>>
>> On Fri, Jan 15, 2016 at 8:51 AM, Hanno Böck wrote:
>>>
>>> Hi,
>>>
>>> I just saw this tweet by John Regehr:
>>> https://twitter.com/johnregehr/status/688033344580399104
>>>
>>> He found a code example with a pretty obvious out of bounds stack read
>>> that asan doesn't catch with -O or -O2 (equivalent). I checked this
>>> with both current gcc and clang.
>>>
>>> This is a stripped down example:
>>> int main() {
>>> int b[1] = {0};
>>> int a=-1;
>>> printf("%i\n", b[a]);
>>> }
>>>
>>>
>>> I am a bit surprised, because this looks like a poster child example of
>>> the kind of bug asan can find. But somehow the optimization
>>> seems to break the asan check here.
>>>
>>> I now wonder how many bugs keep being hidden because of this, as -O2 is
>>> a pretty common default setting for compilations.
>>>
>>>
>>> --
>>> Hanno Böck
>>> http://hboeck.de/
>>>
>>> mail/jabber: ha...@hboeck.de
>>> GPG: BBB51E42
>>>
>>> --
>>> 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.
Re: Stack oob not detected with -O2
It's in ASan FAQ btw.
On Fri, Jan 15, 2016 at 7:58 PM, Konstantin Serebryany
wrote:
> +john
>
> Yea, if optimizations get rid of the buggy code before asan gets a chance to
> instrument it -- the bug will be missed.
> We've seen it before in many *trivial* examples.
> It's unclear how many bugs we miss this way; some for sure.
>
> On Fri, Jan 15, 2016 at 8:51 AM, Hanno Böck wrote:
>>
>> Hi,
>>
>> I just saw this tweet by John Regehr:
>> https://twitter.com/johnregehr/status/688033344580399104
>>
>> He found a code example with a pretty obvious out of bounds stack read
>> that asan doesn't catch with -O or -O2 (equivalent). I checked this
>> with both current gcc and clang.
>>
>> This is a stripped down example:
>> int main() {
>> int b[1] = {0};
>> int a=-1;
>> printf("%i\n", b[a]);
>> }
>>
>>
>> I am a bit surprised, because this looks like a poster child example of
>> the kind of bug asan can find. But somehow the optimization
>> seems to break the asan check here.
>>
>> I now wonder how many bugs keep being hidden because of this, as -O2 is
>> a pretty common default setting for compilations.
>>
>>
>> --
>> Hanno Böck
>> http://hboeck.de/
>>
>> mail/jabber: ha...@hboeck.de
>> GPG: BBB51E42
>>
>> --
>> 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.
Re: Experimental detection of usage on an uninitialized memory
On Thu, Jan 14, 2016 at 11:45 PM, Konstantin Serebryany
wrote:
>
>
> On Thu, Jan 14, 2016 at 12:17 PM, Yuri Gribov wrote:
>>
>> Hi Martin,
>>
>> On Thu, Jan 14, 2016 at 3:17 PM, Martin Liška
>> wrote:
>> > Hello.
>> >
>> > Let me firstly give you big compliment for address sanitizer
>> > infrastructure!
>> > I've been currently working as GCC developer and I find two potential
>> > interesting use-cases for the sanitizer:
>> >
>> > 1) use of uninitialized memory
>> >
>> > GCC started to annotate all class ctors and dtors with memory clobber
>> > store:
>> > -flifetime-store
>> >
>> > https://gcc.gnu.org/onlinedocs/gcc-5.3.0/gcc/Optimize-Options.html#Optimize-Options
>> >
>> > Looks Firefox suffers from many of these errors and segfaults during
>> > startup
>> > with latest GCC and link-time optimization.
>> > Let's assume following example:
>> >
>> > #include
>> > #include
>> > #include
>> > #include
>> >
>> > struct A
>> > {
>> > char i[100];
>> > A() {}
>> > ~A() {}
>> > };
>> >
>> > int get_value (int *a, int i)
>> > {
>> > return a[i];
>> > }
>> >
>> > int main()
>> > {
>> > int *ar = (int *)malloc (111);
>> > *ar = 123;
>> > fprintf (stderr, "memory: %p\n", ar);
>> >
>> > A* ap = new(ar) A;
>> > ap->~A();
>> >
>> > get_value (ar, 10); // use of uninitialized memory
>> >
>> > return 0;
>> > }
>> >
>> > As you can see, calling get_value is an invalid operation. However, e.g.
>> > valgrind tool is unable to catch these as the value is initialized.
>> > I came with an experimental patch to address sanitizer that annotates
>> > every
>> > memory clobber to call memory poisoning. On the other hand,
>> > every memory store must unpoison the memory.
>>
>> This has been brought up before in
>> https://github.com/google/sanitizers/issues/73 but guys decided to
>> firstly do this in MSan. I guess adding this to ASan as an option
>> would be cool because it's much easier to integrate (I'm not an owner
>> or maintainer though so speaking for myself here).
>
>
> Correct. In msan this feature is already implemented:
> http://clang.llvm.org/docs/MemorySanitizer.html#use-after-destruction-detection
> I frankly don't know how to correctly implement it in asan
> because asan's shadow does not distinguish between reads and writes.
>
>>
>>
>> > Sample output from patched GCC & sanitizer:
>> >
>> > ==12358==ERROR: AddressSanitizer: heap-clobbered-memory-read on address
>> > 0x60b0afb8 at pc 0x00400ad1 bp 0x7fffdca0 sp 0x7fffdc98
>> > READ of size 4 at 0x60b0afb8 thread T0
>> > #0 0x400ad0 in get_value(int*, int) (/tmp/a.out+0x400ad0)
>> > #1 0x400bca in main (/tmp/a.out+0x400bca)
>> > #2 0x7621960f in __libc_start_main (/lib64/libc.so.6+0x2060f)
>> > #3 0x4009a8 in _start (/tmp/a.out+0x4009a8)
>> >
>> > 0x60b0afb8 is located 40 bytes inside of 111-byte region
>> > [0x60b0af90,0x60b0afff)
>> > allocated by thread T0 here:
>> > #0 0x76f02128 in __interceptor_malloc
>> > ../../../../libsanitizer/asan/asan_malloc_linux.cc:38
>> > #1 0x400ae9 in main (/tmp/a.out+0x400ae9)
>> > #2 0x7621960f in __libc_start_main (/lib64/libc.so.6+0x2060f)
>> >
>> > SUMMARY: AddressSanitizer: heap-clobbered-memory-read
>> > (/tmp/a.out+0x400ad0)
>> > in get_value(int*, int)
>> > Shadow bytes around the buggy address:
>> > 0x0c167fff95a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>> > 0x0c167fff95b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>> > 0x0c167fff95c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>> > 0x0c167fff95d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>> > 0x0c167fff95e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>> > =>0x0c167fff95f0: fa fa f0 f0 f0 f0 f0[f0]f0 f0 f0 f0 f0 f0 00 07
>> > 0x0c167fff9600: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>> > 0x0c167fff9610: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>> > 0x0c167fff9620: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>> > 0x0c167fff9630: fa fa fa fa fa fa fa fa fa fa fa fa fa
Re: Experimental detection of usage on an uninitialized memory
Hi Martin,
On Thu, Jan 14, 2016 at 3:17 PM, Martin Liška wrote:
> Hello.
>
> Let me firstly give you big compliment for address sanitizer infrastructure!
> I've been currently working as GCC developer and I find two potential
> interesting use-cases for the sanitizer:
>
> 1) use of uninitialized memory
>
> GCC started to annotate all class ctors and dtors with memory clobber store:
> -flifetime-store
> https://gcc.gnu.org/onlinedocs/gcc-5.3.0/gcc/Optimize-Options.html#Optimize-Options
>
> Looks Firefox suffers from many of these errors and segfaults during startup
> with latest GCC and link-time optimization.
> Let's assume following example:
>
> #include
> #include
> #include
> #include
>
> struct A
> {
> char i[100];
> A() {}
> ~A() {}
> };
>
> int get_value (int *a, int i)
> {
> return a[i];
> }
>
> int main()
> {
> int *ar = (int *)malloc (111);
> *ar = 123;
> fprintf (stderr, "memory: %p\n", ar);
>
> A* ap = new(ar) A;
> ap->~A();
>
> get_value (ar, 10); // use of uninitialized memory
>
> return 0;
> }
>
> As you can see, calling get_value is an invalid operation. However, e.g.
> valgrind tool is unable to catch these as the value is initialized.
> I came with an experimental patch to address sanitizer that annotates every
> memory clobber to call memory poisoning. On the other hand,
> every memory store must unpoison the memory.
This has been brought up before in
https://github.com/google/sanitizers/issues/73 but guys decided to
firstly do this in MSan. I guess adding this to ASan as an option
would be cool because it's much easier to integrate (I'm not an owner
or maintainer though so speaking for myself here).
> Sample output from patched GCC & sanitizer:
>
> ==12358==ERROR: AddressSanitizer: heap-clobbered-memory-read on address
> 0x60b0afb8 at pc 0x00400ad1 bp 0x7fffdca0 sp 0x7fffdc98
> READ of size 4 at 0x60b0afb8 thread T0
> #0 0x400ad0 in get_value(int*, int) (/tmp/a.out+0x400ad0)
> #1 0x400bca in main (/tmp/a.out+0x400bca)
> #2 0x7621960f in __libc_start_main (/lib64/libc.so.6+0x2060f)
> #3 0x4009a8 in _start (/tmp/a.out+0x4009a8)
>
> 0x60b0afb8 is located 40 bytes inside of 111-byte region
> [0x60b0af90,0x60b0afff)
> allocated by thread T0 here:
> #0 0x76f02128 in __interceptor_malloc
> ../../../../libsanitizer/asan/asan_malloc_linux.cc:38
> #1 0x400ae9 in main (/tmp/a.out+0x400ae9)
> #2 0x7621960f in __libc_start_main (/lib64/libc.so.6+0x2060f)
>
> SUMMARY: AddressSanitizer: heap-clobbered-memory-read (/tmp/a.out+0x400ad0)
> in get_value(int*, int)
> Shadow bytes around the buggy address:
> 0x0c167fff95a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> 0x0c167fff95b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> 0x0c167fff95c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> 0x0c167fff95d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> 0x0c167fff95e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> =>0x0c167fff95f0: fa fa f0 f0 f0 f0 f0[f0]f0 f0 f0 f0 f0 f0 00 07
> 0x0c167fff9600: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> 0x0c167fff9610: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> 0x0c167fff9620: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> 0x0c167fff9630: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> 0x0c167fff9640: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> Shadow byte legend (one shadow byte represents 8 application bytes):
> Addressable: 00
> Partially addressable: 01 02 03 04 05 06 07
> Heap left redzone: fa
> Heap right redzone: fb
> Heap clobbered memoryf0
>
> Well, the implementation currently has granularity equal to 8 bytes and
> every clobber/store must be considered conservatively. Ideally, I would like
> to be able to clobber (mark store)
> of every byte. Another issues is that I am unable to clear clobber shadow
> byte for stack memory after a frame is unwinded, not sure where to find a
> place where stacks are prepared?
Current implementation only unpoisons stack redzones on exit from
function (see calls to asan_clear_shadow in
asan_emit_stack_protection). You'll probably have to change this to
unpoison the entire frame (if it contains C++ objects with non-trivial
dtors).
> 2) memory access checks based on TBAA
>
> Every memory access in compiler is connected to an alias set and these sets
> can be compared in runtime if the access is valid.
> Such check would require to assign 4B information (alias set number) for
> every byte (I know huge memory footprint), but it can provide interesting
> informations.
Sounds very interesting. Wouldn't it be possible to round objects to 8
bytes (same way as ASan does) to decrease the overhead? BTW note that
you'll have to take care of generating unique alias set numbers across
all compilation units which may not be easy (unless you plan to use
LTO).
> Well, as I've briefly described my use-cases, I have couple of questions:
> a) Are the
Re: "check_initialization_order=true" command line option?
On Thu, Jan 14, 2016 at 6:59 AM, wrote:
>
>> >> If you want to bake in some options at compile time, there are a few
>> >> ways
>> >> to do it. -DASAN_DEFAULT_OPTIONS=check_initialization_order=true will
>> >> work,
>> >> or you can define the __asan_default_options function somewhere in the
>> >> binary like this:
>> >>
>> >
>> > Thanks, we are not compiling the compiler.
>>
>> You don't need to - just define this function somewhere in your exe
>> and libasan will automatically find it and take it's return value as
>> default option string. To control the string from cmdline you'll just
>> need to return a cmdline-controlled macro from it.
>
>
> Ah, OK, thanks.
>
> So I'm clear, I need to add the following:
>
> #ifdef MYLIB_ASAN_CHECK_CXX_ORDER
> bool check_initialization_order
> {
> reutn true;
> }
> #endif
>
> And then the following when building for the sanitizer:
>
> export CXX=clang++
> export CXXF:AGS+"-g3 -O2 -DMYLIB_ASAN_CHECK_CXX_ORDER"
> make
>
> Is that correct?
I thought more like
export CXXFLAGS=-DASAN_FLAGS='check_initialization_order=1'
and then in your source code
#define STR(x) STR2(x)
#define STR2(x) #x
#ifdef ASAN_FLAGS
const char *__asan_default_options() {
return STR(ASAN_FLAGS);
}
#endif
> My last question is, how can I detect when initializer order checking is
> available? We currently use the following in our test script to detect when
> Address Sanitzer is available:
>
> $CXX -x c++ -fsanitize=address adhoc.cpp.proto -c -o $TMP/adhoc >
> /dev/null 2>&1
> if [ "$?" -eq "0" ] && [ "$IS_X86" -ne "0" ]; then
> HAVE_ASAN=1
> else
> HAVE_ASAN=0
> fi
>
> But its not clear to me how to determine when this particular feature is
> available.
I personally don't know a good answer to this. Perhaps just check
compiler version?
> Thanks again for the help.
>
> Jeff
>
> --
> 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.
Re: "check_initialization_order=true" command line option?
BTW could someone mention __asan_default_options in https://github.com/google/sanitizers/wiki/AddressSanitizerFlags ? Can't do this from my home email. On Tue, Jan 12, 2016 at 8:01 PM, Yuri Gribov wrote: > On Tue, Jan 12, 2016 at 7:57 PM, wrote: >> >> >> On Monday, January 11, 2016 at 1:51:58 PM UTC-5, Reid Kleckner wrote: >>> >>> Which command line are you referring to, the compiler command line or the >>> application command line? >> >> >> When we invoke the compiler, we want to ensure the option is in effect. For >> example: >> >> clang++ -fsanitze=address -fcheck_initialization_order=true -c foo.cxx >> >>> >>> If you want to bake in some options at compile time, there are a few ways >>> to do it. -DASAN_DEFAULT_OPTIONS=check_initialization_order=true will work, >>> or you can define the __asan_default_options function somewhere in the >>> binary like this: >>> >> >> Thanks, we are not compiling the compiler. > > You don't need to - just define this function somewhere in your exe > and libasan will automatically find it and take it's return value as > default option string. To control the string from cmdline you'll just > need to return a cmdline-controlled macro from it. > >> >> Jeff >> >> -- >> 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.
Re: "check_initialization_order=true" command line option?
On Tue, Jan 12, 2016 at 7:57 PM, wrote: > > > On Monday, January 11, 2016 at 1:51:58 PM UTC-5, Reid Kleckner wrote: >> >> Which command line are you referring to, the compiler command line or the >> application command line? > > > When we invoke the compiler, we want to ensure the option is in effect. For > example: > > clang++ -fsanitze=address -fcheck_initialization_order=true -c foo.cxx > >> >> If you want to bake in some options at compile time, there are a few ways >> to do it. -DASAN_DEFAULT_OPTIONS=check_initialization_order=true will work, >> or you can define the __asan_default_options function somewhere in the >> binary like this: >> > > Thanks, we are not compiling the compiler. You don't need to - just define this function somewhere in your exe and libasan will automatically find it and take it's return value as default option string. To control the string from cmdline you'll just need to return a cmdline-controlled macro from it. > > Jeff > > -- > 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.
Re: ASAN_OPTIONS and other docs disappeared with google code shutdown
On Fri, Oct 30, 2015 at 10:02 PM, Hanno Böck wrote: > Hi, > > With the shutdown of google code it seems several docs for asan have > disappeared. > E.g. there was a doc about the various ASAN_OPTIONS variants here: > https://code.google.com/p/address-sanitizer/wiki/Flags What about https://github.com/google/sanitizers/wiki/AddressSanitizerFlags ? Quite frankly I never liked this page as it duplicated ASAN_OPTIONS=help=1 and was frequently out-of-synch with reality. > (also let me say that I think in general asan could definitely need > more publicity - maybe have a reasonably nice webpage on its own domain > would be a good idea?) > +1 I think this is one of the reasons for relatively scarce adoption of sanitizers. -Y -- 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.
Re: unknown-crash with __asan_memset
On Fri, Jun 5, 2015 at 9:32 PM, Yuri Gribov wrote: > On Fri, Jun 5, 2015 at 9:12 PM, 'Alexey Samsonov' via address-sanitizer < > address-sanitizer@googlegroups.com> wrote: > >> Looks like the position of Java heap (0xdfff8000) interferes with ASan >> shadow memory mappings. >> See memory layout in projects/compiler-rt/lib/asan/asan_mapping.h. >> >> __asan_region_is_poisoned arguments seem to be a red herring - it's >> possible that debug info is incorrect. >> > > Indeed, they would cause a segfault if they were real, contrary to the > original error report (unknown-crash at 0xdfff8000). It seems that > someone (JVM?) spoils ASan shadow memory which later drives ASan crazy. > > @Dima: ASan should have printed shadow memory contents after the > backtrace, could you post it as well? > If ASan intecepted mmap, it could detect errors like this. -Y -- 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.
Re: unknown-crash with __asan_memset
On Fri, Jun 5, 2015 at 9:12 PM, 'Alexey Samsonov' via address-sanitizer < address-sanitizer@googlegroups.com> wrote: > Looks like the position of Java heap (0xdfff8000) interferes with ASan > shadow memory mappings. > See memory layout in projects/compiler-rt/lib/asan/asan_mapping.h. > > __asan_region_is_poisoned arguments seem to be a red herring - it's > possible that debug info is incorrect. > Indeed, they would cause a segfault if they were real, contrary to the original error report (unknown-crash at 0xdfff8000). It seems that someone (JVM?) spoils ASan shadow memory which later drives ASan crazy. @Dima: ASan should have printed shadow memory contents after the backtrace, could you post it as well? -Y -- 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.
Re: Failure on large allocation
On Fri, Jun 5, 2015 at 9:21 PM, 'Alexey Samsonov' via address-sanitizer < address-sanitizer@googlegroups.com> wrote: > Wow, the world of 1Tb RAM machines is here. > 1) You can try to allocate 156Gb of memory with mmap() instead of malloc(). > 2) 64Gb is a hard limit on allocation size in ASan runtime. You can try to > bump this limit (kMaxAllowedMallocSize in lib/asan/asan_allocator.cc) and > rebuilt it from source. > Perhaps it makes sense to print a hint to user? -Y -- 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.
Re: unknown-crash with __asan_memset
On Wed, May 27, 2015 at 1:52 PM, Dmitriy - wrote: > Hello all. > I try using ASan for debug jvm. > > All .so library in jvm instrumented with ASan. > But, I have some error here: > > LD_PRELOAD=/usr/lib/libclang_rt.asan-x86_64.so > LD_LIBRARY_PATH=./dist/jdk_7/debug/open/jdk/jre/lib/amd64/drlvm/ > ./dist/jdk_7/debug/open/jdk/jre/bin/java -XX:-UseG1GC -version > = > ==24418==ERROR: AddressSanitizer: unknown-crash on address 0xdfff8000 > at pc 0x7f6c2e9ab3d9 bp 0x7f6c28773960 sp 0x7f6c28773110 > WRITE of size 4194304 at 0xdfff8000 thread T1 > #0 0x7f6c2e9ab3d8 in __asan_memset > /home/dbezheckov/waratek/tests/asan/sources/llvm/projects/compiler-rt/lib/asan/asan_interceptors.cc:431 > #1 0x7f6c12fbd7d5 in lspace_initialize(GC*, void*, unsigned long) > /home/dbezheckov/waratek/harmony-custom/drlvm/vm/gc_gen/src/los/lspace.cpp:44:5 > #2 0x7f6c12f9fc8c in gc_los_initialize(GC_Gen*, void*, unsigned long) > /home/dbezheckov/waratek/harmony-custom/drlvm/vm/gc_gen/src/gen/gen.cpp:476:24 > #3 0x7f6c12f9f63f in gc_gen_initialize(GC_Gen*, unsigned long, > unsigned long) > /home/dbezheckov/waratek/harmony-custom/drlvm/vm/gc_gen/src/gen/gen.cpp:313:5 > #4 0x7f6c12f848eb in gc_init > /home/dbezheckov/waratek/harmony-custom/drlvm/vm/gc_gen/src/common/gc_for_vm.cpp:104:5 > #5 0x7f6c29cc9623 in vm_init1(JavaVM_Internal*, JavaVMInitArgs*, > JNIEnv_External**) > /home/dbezheckov/waratek/harmony-custom/drlvm/vm/vmcore/src/init/vm_init.cpp:796:14 > #6 0x7f6c29b27f2c in JNI_CreateJavaVM > /home/dbezheckov/waratek/harmony-custom/drlvm/vm/vmcore/src/jni/jni.cpp:436:19 > #7 0x7f6c29b286b4 in CVMI_CreateJavaVM > /home/dbezheckov/waratek/harmony-custom/drlvm/vm/vmcore/src/jni/jni.cpp:526:12 > #8 0x7f6c2abd0634 in JNI_CreateJavaVM > /home/dbezheckov/waratek/harmony-custom/drlvm/vm/openjdk/src/openjdk.cpp:90:12 > #9 0x7f6c2e6fdb47 > > (/home/dbezheckov/waratek/harmony-custom/dist/jdk_7/debug/open/jdk/jre/bin/../lib/amd64/jli/libjli.so+0x2b47) > #10 0x7f6c2df1c181 in start_thread > /build/buildd/eglibc-2.19/nptl/pthread_create.c:312 > #11 0x7f6c2e43047c in clone > /build/buildd/eglibc-2.19/misc/../sysdeps/unix/sysv/linux/x86_64/clone.S:111 > I don't think this rings any bells. Do you could try to analyze backtrace with gdb? You could use sleep_before_dying to attach to process on error. -Y -- 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.
Re: Android L arm address sanitizer problem
On Wed, May 6, 2015 at 10:57 PM, 'Evgeniy Stepanov' via address-sanitizer wrote: > Again, sorry for the delayed response. > > There were lots of ASan-related changes both in LLVM repo and in AOSP > in the last two weeks. You were right, ASan in AOSP was limited to > ARM, and it still is, but we plan to add AArch64 and probably X86 soon > (in fact it might work already if you update the #if guards). Other > than that, ASan works out-of-the-box on AOSP master branch (we tested > on Nexus 5). While at it, do you have plans to enable it in GCC? -Y -- 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.
Re: [PINGv2][PATCH] Ignore alignment by option
On Thu, Dec 4, 2014 at 8:06 PM, 'Dmitry Vyukov' via address-sanitizer wrote: > You answered your own question about user space :) Yeah, I hoped someone would rush to overpersuade me... -Y -- 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.
Re: Issue 330 in address-sanitizer: Support re-exec of sanitized executable with preloading libasan on Linux and Android
On Sat, Nov 1, 2014 at 8:39 AM, 'Evgeniy Stepanov' via address-sanitizer wrote: > Maybe we could go back to the idea of late initialization? You mean making all interceptors respect asan_inited flag? > Late shadow mapping seems to work OK in most cases, you could hack the loader > to reserve this region for you. If I were to hack loader, I'd just update it to automatically preload libasan.so when necessary (i.e. in case any of the DSOs depends on it) and also make sure __asan_init is the first ctor to be called. I think I'd prefer to live with another local patch though. -Y -- 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.
Re: Small improvements to run_spec_clang_asan.sh
Cool! Could someone apply this then?
On Wed, Oct 1, 2014 at 2:18 PM, 'Evgeniy Stepanov' via
address-sanitizer wrote:
> Sorry, my bad, missed the "$" sign.
>
>
> On Wed, Oct 1, 2014 at 2:03 PM, Yuri Gribov wrote:
>> On Wed, Oct 1, 2014 at 1:56 PM, 'Evgeniy Stepanov' via
>> address-sanitizer wrote:
>>>> CLANGXX=${CLANGXX:-$(echo $CLANG | sed -e 's/gcc$/g++/')}
>>> What if there is more than one "gcc" in the compiler path?
>>
>> Sorry, don't understand... I'm just replacing trailing gcc with g++ so
>> e.g. path/to/my/cross-gcc becomes path/to/my/cross-g++.
>>
>> -Y
>>
>> --
>> 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.
Re: Small improvements to run_spec_clang_asan.sh
On Wed, Oct 1, 2014 at 1:56 PM, 'Evgeniy Stepanov' via
address-sanitizer wrote:
>> CLANGXX=${CLANGXX:-$(echo $CLANG | sed -e 's/gcc$/g++/')}
> What if there is more than one "gcc" in the compiler path?
Sorry, don't understand... I'm just replacing trailing gcc with g++ so
e.g. path/to/my/cross-gcc becomes path/to/my/cross-g++.
-Y
--
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.
Re: Small improvements to run_spec_clang_asan.sh
On Fri, Sep 19, 2014 at 11:13 PM, Yuri Gribov wrote:
> Will test and resend on Monday.
Ok, I've fallen ill and then completely forgot about this. Here's an
updated version.
>> CLANG=${CLANG:-clang}
> You probably need the same for CLANGXX
I'm doing this below depending on whether CLANG is really clang or gcc.
> Why are you disabling leak detection? It is on by default, which means
> you are benchmarking not the same thing that users run.
> At least make it an option.
I've kept the detect_leaks=0 because as kcc mentioned lots of tests
have leaks. If you desperately want this cluttered stderr you can
remove the detect_leaks=0 part from final patch (or I can do it
myself).
> I don't understand this LD_LIBRARY_PATH magic, what's its for?
Fixed. This now allows user to override default script's ASAN_OPTIONS.
@Evgeniy: you can just remove detect_leaks=0 if you desperately want
this stderr clutter in runner's output.
-Y
--
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.
Index: run_spec_clang_asan.sh
===
--- run_spec_clang_asan.sh (revision 2196)
+++ run_spec_clang_asan.sh (working copy)
@@ -3,31 +3,63 @@
# Simple script to run CPU2006 with AddressSanitizer.
# Make sure to use spec version 1.2 (SPEC_CPU2006v1.2).
# Run this script like this:
-# $./run_spec_clang_asan.sh TAG [test|train|ref] benchmarks
+# $./run_spec_clang_asan.sh TAG size benchmarks...
# TAG is any word. If you use different TAGS you can runs several builds in
# parallel.
-# test is a small data set, train is medium, ref is large.
-# To run all C use all_c, for C++ use all_cpp
+# size can be test, train or ref. test is a small data set, train is medium,
+# ref is large.
+# To run all C tests use all_c, for C++ use all_cpp. To run integer tests
+# use int, for floating point use fp.
name=$1
shift
size=$1
shift
+me=$(basename $0)
+
+usage() {
+ echo >&2 "Usage: $me TAG size bmarks"
+ exit 1
+}
+
+if test -z "$name"; then
+ usage
+fi
+
+case "$size" in
+ test|train|ref)
+;;
+ *)
+echo >&2 "$me: unexpected size: $size"
+usage
+;;
+esac
+
+if [ ! -f ./shrc ]; then
+ echo >&2 "$me: script must be run from SPEC2006 folder"
+ exit 1
+fi
+
ulimit -s 8092 # stack
SPEC_J=${SPEC_J:-20}
NUM_RUNS=${NUM_RUNS:-1}
-F_ASAN=-fsanitize=address
CLANG=${CLANG:-clang}
BIT=${BIT:-64}
OPT_LEVEL=${OPT_LEVEL:-"-O2"}
-
+if $CLANG --version 2>&1 | grep -q clang; then
+ F_ASAN=-fsanitize=address
+ CLANGXX=${CLANGXX:-$CLANG++}
+else
+ F_ASAN='-fsanitize=address -static-libasan'
+ CLANGXX=${CLANGXX:-$(echo $CLANG | sed -e 's/gcc$/g++/')}
+fi
rm -rf config/$name.*
COMMON_FLAGS="$F_ASAN -m$BIT -g"
-CC="$CLANG -std=gnu89 $COMMON_FLAGS"
-CXX="${CLANG}++ $COMMON_FLAGS"
+CC="$CLANG-std=gnu89 $COMMON_FLAGS"
+CXX="$CLANGXX$COMMON_FLAGS"
cat << EOF > config/$name.cfg
monitor_wrapper = $SPEC_WRAPPER \$command
@@ -48,8 +80,8 @@
FC = echo
default=base=default=default:
-COPTIMIZE = $OPT_LEVEL
-CXXOPTIMIZE = $OPT_LEVEL
+COPTIMIZE = $OPT_LEVEL
+CXXOPTIMIZE = $OPT_LEVEL
default=base=default=default:
PORTABILITY = -DSPEC_CPU_LP64
@@ -67,7 +99,7 @@
CXXPORTABILITY= -include string.h -include stdlib.h -include cstddef
EOF
-# Don't report alloc-dealloc-mismatch bugs (there is on in 471.omnetpp)
-export ASAN_OPTIONS=alloc_dealloc_mismatch=0
+# Don't report alloc-dealloc-mismatch bugs (there is on in 471.omnetpp) and
leaks
+export
ASAN_OPTIONS=alloc_dealloc_mismatch=0:detect_leaks=0${ASAN_OPTIONS:+:$ASAN_OPTIONS}
. shrc
runspec -c $name -a run -I -l --size $size -n $NUM_RUNS $@
Re: AddressSanitizer's allocator
On Fri, Sep 26, 2014 at 4:08 PM, Jonas Wagner wrote: > Also, this might be very interesting for the stack, too. I think even a > slightly randomized stack layout (through random redzone sizes or variable > reordering) could make it harder to write exploits. I know ASan is a > debugging tool more than a security hardening tool, but I'd still find this > interesting. AFAIK KAsan people experimented with something like this to get cheap probabilistic UAR detection. -Y -- 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.
Re: Small improvements to run_spec_clang_asan.sh
On Fri, Sep 19, 2014 at 9:02 PM, Yuri Gribov wrote:
>> I don't understand this LD_LIBRARY_PATH magic, what's its for?
>
> Snap, believe it or not but that's a typo. It should be ASAN_OPTIONS
> and the weird expression optionally inserts : in front of added
> options (so that user can provide his own ASAN_OPTIONS).
I meant to say
export
ASAN_OPTIONS=alloc_dealloc_mismatch=0:detect_leaks=0${ASAN_OPTIONS:+:$ASAN_OPTIONS}
Will test and resend on Monday.
-Y
--
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.
Re: Small improvements to run_spec_clang_asan.sh
On Fri, Sep 19, 2014 at 4:13 PM, 'Evgeniy Stepanov' via
address-sanitizer wrote:
>> CLANG=${CLANG:-clang}
> You probably need the same for CLANGXX
I do this in the next block (autodetection is different clang and gcc
are different).
> Why are you disabling leak detection? It is on by default, which means
> you are benchmarking not the same thing that users run.
> At least make it an option.
As Kostya mentioned there are numerous leaks in benchmarks which make
analysis harder. I can remove it if necessary.
> I don't understand this LD_LIBRARY_PATH magic, what's its for?
Snap, believe it or not but that's a typo. It should be ASAN_OPTIONS
and the weird expression optionally inserts : in front of added
options (so that user can provide his own ASAN_OPTIONS).
-Y
--
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.
Small improvements to run_spec_clang_asan.sh
Hi all,
Here is a small patch for
https://code.google.com/p/address-sanitizer/source/browse/trunk/spec/run_spec_clang_asan.sh
which
* updates docs
* adds some option verification
* adds GCC support
* disables leak detection
Does the change look sane?
-Y
--
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.
Index: spec/run_spec_clang_asan.sh
===
--- spec/run_spec_clang_asan.sh (revision 2196)
+++ spec/run_spec_clang_asan.sh (working copy)
@@ -3,31 +3,63 @@
# Simple script to run CPU2006 with AddressSanitizer.
# Make sure to use spec version 1.2 (SPEC_CPU2006v1.2).
# Run this script like this:
-# $./run_spec_clang_asan.sh TAG [test|train|ref] benchmarks
+# $./run_spec_clang_asan.sh TAG size benchmarks...
# TAG is any word. If you use different TAGS you can runs several builds in
# parallel.
-# test is a small data set, train is medium, ref is large.
-# To run all C use all_c, for C++ use all_cpp
+# size can be test, train or ref. test is a small data set, train is medium,
+# ref is large.
+# To run all C use all_c, for C++ use all_cpp. To run integer tests use int,
+# for floating point use fp.
name=$1
shift
size=$1
shift
+me=$(basename $0)
+
+usage() {
+ echo >&2 "Usage: $me TAG size bmarks"
+ exit 1
+}
+
+if test -z "$name"; then
+ usage
+fi
+
+case "$size" in
+ test|train|ref)
+;;
+ *)
+echo >&2 "$me: unexpected size: $size"
+usage
+;;
+esac
+
+if [ ! -f ./shrc ]; then
+ echo >&2 "$me: script must be run from SPEC2006 folder"
+ exit 1
+fi
+
ulimit -s 8092 # stack
SPEC_J=${SPEC_J:-20}
NUM_RUNS=${NUM_RUNS:-1}
-F_ASAN=-fsanitize=address
CLANG=${CLANG:-clang}
BIT=${BIT:-64}
OPT_LEVEL=${OPT_LEVEL:-"-O2"}
-
+if $CLANG --version 2>&1 | grep -q clang; then
+ F_ASAN=-fsanitize=address
+ CLANGXX=${CLANGXX:-$CLANG++}
+else
+ F_ASAN='-fsanitize=address -static-libasan'
+ CLANGXX=${CLANGXX:-$(echo $CLANG | sed -e 's/gcc$/g++/')}
+fi
rm -rf config/$name.*
COMMON_FLAGS="$F_ASAN -m$BIT -g"
-CC="$CLANG -std=gnu89 $COMMON_FLAGS"
-CXX="${CLANG}++ $COMMON_FLAGS"
+CC="$CLANG-std=gnu89 $COMMON_FLAGS"
+CXX="$CLANGXX$COMMON_FLAGS"
cat << EOF > config/$name.cfg
monitor_wrapper = $SPEC_WRAPPER \$command
@@ -48,7 +80,7 @@
FC = echo
default=base=default=default:
-COPTIMIZE = $OPT_LEVEL
+COPTIMIZE= $OPT_LEVEL
CXXOPTIMIZE = $OPT_LEVEL
default=base=default=default:
@@ -67,7 +99,7 @@
CXXPORTABILITY= -include string.h -include stdlib.h -include cstddef
EOF
-# Don't report alloc-dealloc-mismatch bugs (there is on in 471.omnetpp)
-export ASAN_OPTIONS=alloc_dealloc_mismatch=0
+# Don't report alloc-dealloc-mismatch bugs (there is on in 471.omnetpp) and
leaks
+export
ASAN_OPTIONS=${ASAN_OPTIONS:-}${LD_LIBRARY_PATH:+:}alloc_dealloc_mismatch=0:detect_leaks=0
. shrc
runspec -c $name -a run -I -l --size $size -n $NUM_RUNS $@
Re: GCC Asan report some unexpected log when an error detected, anyone explain me why?
On Wed, Aug 13, 2014 at 6:06 AM, ji wang wrote: > Hi, Yuri > After I used LD_PRELOAD=libasan.so.1 before the process started, those > errors at the top post I mentioned gone. A little confused, do we have to > use LD_PRELOAD to preload libasan.so before the process start even I've used > Gcc Asan compiled the lib of this process? And why? You are on Android, right? Unfortunately I'm not familiar with this OS, perhaps Evgeny could comment. -Y -- 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.
Re: GCC Asan report some unexpected log when an error detected, anyone explain me why?
> libasan.so.1 is ahead of libc.so, > And I think the other libs couldn't link the libasan.so.1 except this > recompiled one, > so the interceptors not work for them. Am I right? No, that's not how symbol resolution works on Linux systems. As I mentioned, interception is done globally. You'll probably want to check Drepper's article on this (https://software.intel.com/sites/default/files/m/a/1/e/dsohowto.pdf). -Y -- 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.
Re: GCC Asan report some unexpected log when an error detected, anyone explain me why?
> I think those interceptors means that we define the same name functions as > libc, like memset, and preload it before libc, so the instrumented code call > the asan memset not the libc memset. Right. > So the preload decides whether call asan memset or not, and Gcc Asan only > preload the libasan.so for the instrumented lib not using LD_PRELOAD for the > entire process, so a little confused, am I wrong? No, LD_PRELOAD setting is "global" i.e. it affects executable and all loaded libraries. -Y -- 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.
Re: GCC Asan report some unexpected log when an error detected, anyone explain me why?
> I used Gcc Asan recomplied only one shared lib, and I think the interceptors > only works for this lib, why the other could call those asan interceptors? No-no, that's not how interceptors work on Linux. They shadow libc definitions globally. -Y -- 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.
Re: GCC Asan report some unexpected log when an error detected, anyone explain me why?
Ji,
This happens when uninstrumented code calls glibc functions that are
intercepted by Asan (e.g. memset).
On Thu, Aug 7, 2014 at 2:39 PM, ji wang wrote:
> There is one more question, kcc
> Accroding to my test result, Asan report some error at non-instrumented
> code, which means the stacks asan reported lead to the non-instrumented
> code, why this happened?
>
>
> ==2415==ERROR: AddressSanitizer: attempting double-free on 0xb4c28b20 in
> thread T16777215:
> ==2415==AddressSanitizer CHECK failed:
> ../../../.././../gcc/gcc-4.9/libsanitizer/asan/asan_report.cc:586
> "((free_stack->size)) > ((0))" (0x0, 0x0)
> #0 0xb67af94f (/system/lib/libasan.so.1+0x3f94f)
> #1 0xb67b2f8b (/system/lib/libasan.so.1+0x42f8b)
> #2 0xb67ae137 (/system/lib/libasan.so.1+0x3e137)
> #3 0xb6785bff (/system/lib/libasan.so.1+0x15bff)
> #4 0xb67aab63 (/system/lib/libasan.so.1+0x3ab63)
> #5 0xb6ec0cbf (/system/lib/libc.so+0xdcbf)
> #6 0xb6cf0369 (/system/lib/libbinder.so+0x20369)
> #7 0xb6cf041b (/system/lib/libbinder.so+0x2041b)
> #8 0xb6ced789 (/system/lib/libbinder.so+0x1d789)
> #9 0xb6cedabd (/system/lib/libbinder.so+0x1dabd)
> #10 0xb6cedb33 (/system/lib/libbinder.so+0x1db33)
> #11 0xb6cf1983 (/system/lib/libbinder.so+0x21983)
> #12 0xb6e00a11 (/system/lib/libutils.so+0xea11)
> #13 0xb6e00543 (/system/lib/libutils.so+0xe543)
> #14 0xb6ec0223 (/system/lib/libc.so+0xd223)
> #15 0xb6ec03bb (/system/lib/libc.so+0xd3bb)
>
>
> 在 2014年8月6日星期三UTC+8下午5时49分35秒，kcc写道：
>>
>> On Wed, Aug 6, 2014 at 1:45 PM, ji wang wrote:
>> >> (it is possible if e.g. you have
>> >>uninstrumented code).
>> > Do you mean if we want to test a single process, we must recomplied all
>> > the
>> > source code that the process using? In my part, an excutable using lots
>> > of
>> > shared lib when it runs as a single process, do we need recompiled all
>> > those
>> > shared lib and the excutable code？
>>
>>
>> There is no "must" here. But if the non-instrumented code has a bug
>> which leads to memory corruption asan will not report it
>> and may itself die due to that memory corruption.
>>
>> >
>> >
>> >>Hard to tell more w/o reproducer.
>> > I can reproduce those errors using my device now at my hands, but it
>> > maybe
>> > diffcult for anybody else to reproduce those errors.
>> >
>> > 在 2014年8月6日星期三UTC+8下午4时52分29秒，kcc写道：
>> >>
>> >> The first one (((free_stack->size)) > ((0))" (0x0, 0x0)) looks like
>> >> asan could not find the stack trace where the first free() happened.
>> >> The second one ("((id)) != (0)" (0x0, 0x0)) is something similar --
>> >> asan fails to find the allocation stack trace.
>> >> In either case this looks like some bug in asan, or maybe a memory
>> >> corruption that asan has missed (it is possible if e.g. you have
>> >> uninstrumented code).
>> >> Hard to tell more w/o reproducer.
>> >>
>> >> On Wed, Aug 6, 2014 at 12:40 PM, ji wang wrote:
>> >> > Hi, kcc
>> >> > Thanks,again haha:)
>> >> > I just simple want to know what thoes errors means, so I can correct
>> >> > it
>> >> > , as
>> >> > to my GCC and asan runtime lib was compiled by myself base on Gcc4.9
>> >> > source
>> >> > code maybe something went wrong.I think those not right print, may
>> >> > happen on
>> >> > muti-thread program? Or any other advices?
>> >> > And PS, Those occurs on my Android device, I've mentioned in other
>> >> > posts,Using asan enable GCC android toolchain to test
>> >> > libstagefright.so
>> >> > on
>> >> > my android device, push this recompiled lib and then run monkey test,
>> >> > got
>> >> > errors like above.
>> >> >
>> >> >
>> >> > 在 2014年8月6日星期三UTC+8下午2时15分03秒，kcc写道：
>> >> >>
>> >> >> Do you have a reproducer?
>> >> >>
>> >> >> On Wed, Aug 6, 2014 at 6:04 AM, ji wang wrote:
>> >> >> > First: Double Free
>> >> >> > =
>> >> >> > ==2415==ERROR: AddressSanitizer: attempting double-free on
>> >> >> > 0xb4c28b20
>> >> >> > in
>> >> >> > thread T16777215:
>> >> >> > ==2415==AddressSanitizer CHECK failed:
>> >> >> > ../../../.././../gcc/gcc-4.9/libsanitizer/asan/asan_report.cc:586
>> >> >> > "((free_stack->size)) > ((0))" (0x0, 0x0)
>> >> >> > #0 0xb67af94f (/system/lib/libasan.so.1+0x3f94f)
>> >> >> > #1 0xb67b2f8b (/system/lib/libasan.so.1+0x42f8b)
>> >> >> > #2 0xb67ae137 (/system/lib/libasan.so.1+0x3e137
>> >> >> > ...
>> >> >> > ... ...
>> >> >> > According to the asan code, free_stack maybe should not be
>> >> >> > empty,
>> >> >> > should
>> >> >> > print something like “freed by thread T0 here:... ...previously
>> >> >> > allocated by
>> >> >> > thread T0 here:... ..."
>> >> >> > And of cource It's important, for what reason we may lose this
>> >> >> > part
>> >> >> > log
>> >> >> > print or somethine went wrong on my asan?
>> >> >> >
>> >> >> > Second: UseAfterFree
>> >> >> > =
>> >> >> > ==4782==ERROR: AddressSanitizer:
Re: Does anyone can post a Manual of the usage of Asan in GCC4.9(arm, x86, etc) here? For testing excutable and shared liberary,thanks.
On Wed, Jul 30, 2014 at 12:30 PM, ji wang wrote: >>FYI I'm getting the same link sequence if I link hello-world with GCC >>4.10 x86 and ARM Linux toolchains (and they both match your results >>for x86). > Yuri, Do you know where your GCC4.10 organize this link order? Or how to > insert the -lasan and libasan_preinit.o to the linker? I think this lives in gcc/config/gnu-user.h. You could also link libs manually by passing options directly to linker via -Wl but I guess this is unsupported by Asan team. > And I've found the reason why > -lc -lstdc++ -lm is ahead of my -fsanitize=address -lasan now. > Because in Android build system, defined a default order of loading some > libs, PRIVATE_ALL_SHARED_LIBRARIES macro is the libc.so libstdc++.so loader, > and it been placed ahead of my LDFLAGS. I changed this order, went ok. Hope > no side effects. Ah, ok. This _might_ work but as Evgeny said you are on no man's land here: GCC Asan does not really support Android as of now. Patches to fix this are welcome though. -Y -- 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.
Re: Does anyone can post a Manual of the usage of Asan in GCC4.9(arm, x86, etc) here? For testing excutable and shared liberary,thanks.
On Wed, Jul 30, 2014 at 5:49 AM, ji wang wrote: > And Here is an output of GCC on X86 to compare with FYI I'm getting the same link sequence if I link hello-world with GCC 4.10 x86 and ARM Linux toolchains (and they both match your results for x86). As for Android, link options look rather unexpected (and probably incorrect). Is GCC called directly (with -fsanitize=address) or via ndk-build magic? -Y -- 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.
Re: Does anyone can post a Manual of the usage of Asan in GCC4.9(arm, x86, etc) here? For testing excutable and shared liberary,thanks.
Ji, I think Evgeny needs output for final gcc link invocation with -v appended to CFLAGS. On Tue, Jul 29, 2014 at 3:05 PM, ji wang wrote: > Here is the detail below, and I can't find the -l flags to the linker, where > is it? > And is there any way to put libasan.so.1 ahead of libc.so in this gcc ld > order? > arm-linux-androideabi-gcc -v > Using built-in specs. > COLLECT_GCC=arm-linux-androideabi-gcc > COLLECT_LTO_WRAPPER=/home/star/codes/icos_debug_ci_line/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.9/bin/../libexec/gcc/arm-linux-androideabi/4.9/lto-wrapper > Target: arm-linux-androideabi > Configured with: .././../gcc/gcc-4.9/configure > --prefix=/home/star/codes/android-toolchain-src/prefix > --target=arm-linux-androideabi --host=x86_64-linux-gnu > --build=x86_64-linux-gnu --with-gnu-as --with-gnu-ld > --enable-languages=c,c++ > --with-gmp=/home/star/codes/android-toolchain-src/prefix > --with-mpfr=/home/star/codes/android-toolchain-src/prefix > --with-mpc=/home/star/codes/android-toolchain-src/prefix > --with-cloog=/home/star/codes/android-toolchain-src/prefix > --with-isl=/home/star/codes/android-toolchain-src/prefix > --with-ppl=/home/star/codes/android-toolchain-src/prefix > --disable-ppl-version-check --disable-cloog-version-check > --disable-isl-version-check --enable-cloog-backend=isl > --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' > --disable-libssp --enable-threads --disable-nls --disable-libmudflap > --disable-libgomp --enable-libstdc__-v3 --disable-sjlj-exceptions > --disable-shared --disable-tls --disable-libitm --with-float=soft > --with-fpu=vfp --with-arch=armv5te --enable-target-optspace > --with-gcc-version=4.9 --disable-ppl-version-check > --disable-cloog-version-check --disable-isl-version-check > --enable-cloog-backend=isl --with-host-libstdcxx='-static-libgcc > -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --enable-libstdc__-v3 > --enable-initfini-array > --with-sysroot=/home/star/codes/android-toolchain-src/build/sysroot > --with-binutils-version=2.23 --with-mpfr-version=3.1.1 > --with-mpc-version=1.0.1 --with-gmp-version=5.0.5 --with-gdb-version=7.6 > --disable-bootstrap --disable-libquadmath --enable-plugins --enable-libgomp > --enable-libsanitizer --enable-shared --enable-gold --enable-graphite=yes > --with-cloog-version=0.18.0 --with-isl-version=0.11.1 > --enable-eh-frame-hdr-for-static --with-arch=armv5te --enable-gold > --prefix=/home/star/codes/android-toolchain-src/prefix > --program-transform-name='s&^&arm-linux-androideabi-&' --enable-gold=default > Thread model: posix > gcc version 4.9 20140514 (prerelease) (GCC) > > 在 2014年7月29日星期二UTC+8下午6时05分56秒，Evgeniy Stepanov写道： >> >> gcc >> >> On Tue, Jul 29, 2014 at 1:10 PM, ji wang wrote: >> > Ah,I am sorry. Run what with -v? I am not much familiar about this. >> > >> > >> > 在 2014年7月29日星期二UTC+8下午4时55分46秒，Evgeniy Stepanov写道： >> >> >> >> Run it with -v and check the order of -l flags to the linker, which >> >> determines the order of DT_NEEDED entries. >> >> >> >> On Tue, Jul 29, 2014 at 12:41 PM, ji wang wrote: >> >> >>I could not make static runtime work on older android versions, but >> >> >>now I don't see any issues with it. Perhaps something with dlopen-ed >> >> >>libraries? >> >> > I prefer use shared Asan lib now :), because I've found some issues >> >> > like >> >> > when I use static one to check two libs the sametime: >> >> > "Shadow memory range interleaves with an existing memory mapping." >> >> > >> >> > And Yuri said the GCC Asan android toolchain which I am using now, >> >> > when >> >> > we >> >> > pass -fsanitize=address to the LD_FLAGS, >> >> > the GCC can arrange proper lib order during link using libasan.so.1 >> >> > ahead of >> >> > libc.so, Is that right? Or some difference on Android? >> >> > >> >> > >> >> > 在 2014年7月29日星期二UTC+8下午4时00分05秒，Evgeniy Stepanov写道： >> >> >> >> >> >> I could not make static runtime work on older android versions, but >> >> >> now I don't see any issues with it. Perhaps something with dlopen-ed >> >> >> libraries? >> >> >> And you need shared runtime for zygote anyway, unless you build your >> >> >> own system image. >> >> >> >> >> >> On Mon, Jul 28, 2014 at 6:49 PM, ji wang >> >> >> wrote: >> >> >> > How about use static asan runtime? Do the interceptors work with >> >> >> > the >> >> >> > static >> >> >> > runtime? >> >> >> > Like libasan.a those static lib could compiled into the executable >> >> >> > and >> >> >> > the >> >> >> > test shared lib. >> >> >> > >> >> >> > -- >> >> >> > 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 >> >>
Re: Does anyone can post a Manual of the usage of Asan in GCC4.9(arm, x86, etc) here? For testing excutable and shared liberary,thanks.
On Tue, Jul 29, 2014 at 10:34 AM, ji wang wrote: >>Do you mean Android? ARM Linux should be 100% similar to x86 Linux. > Yes, I mean Android. I am using Asan enabled GCC android toolchain now. >From Evgeny's words it seems that GCC Asan and LLVM Asan work differently on Android. And GCC Asan is not quite usable on Android (it seems to work by accident). >>GCC arranges library order for you when you link with >>-fsanitize=address. > Does this mean when I use Asan enabled GCC android toolchain, pass > -fsanitize=address > to the LD_FLAGS, the GCC can arranges lib order for me? Right, both GCC and Clang will arrange proper lib order during link. -Y -- 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.
Re: Does anyone can post a Manual of the usage of Asan in GCC4.9(arm, x86, etc) here? For testing excutable and shared liberary,thanks.
On Tue, Jul 29, 2014 at 4:58 AM, ji wang wrote: > Why the asan runtime lib libasan.so.0 is needed before libc.so.6, does linux > have any special env settings? Like Evgeny mentioned above, you want libasan _before_ libc to be sure that public symbols (malloc, memset, etc.) are properly intercepted by Asan. GCC arranges library order for you when you link with -fsanitize=address. > And on arm platfrom, Do you mean Android? ARM Linux should be 100% similar to x86 Linux. -Y -- 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.
Re: Does anyone can post a Manual of the usage of Asan in GCC4.9(arm, x86, etc) here? For testing excutable and shared liberary,thanks.
Compiler might have inlined call to memcmp.
On Mon, Jul 28, 2014 at 4:30 PM, ji wang wrote:
>
>> >You lose detection of libc usage errors (like strchr() on an
>> >unaddressable buffer, etc).
>
>
> This explain seems reasonable, but I tested libsqlite.so with asan just now,
> got an Asan error that about memcmp, see below, strange... It should not be
> detected, Why this happen?
>
> ~/codes/gcc-linaro-arm-linux-gnueabihf-4.8-2014.04_linux/bin/arm-linux-gnueabihf-ldd
> --root=/home/ libsqlite.so
> libdl.so not found
> liblog.so not found
> libicuuc.so not found
> libicui18n.so not found
> libutils.so not found
>
> libc.so not found
> libstdc++.so not found
> libm.so not found
> libasan.so.1 not found
>
> ==2722==ERROR: AddressSanitizer: global-buffer-overflow on address
> 0x409e32a9 at pc 0x409ccc59 bp 0xbed53abc sp 0xbed53ab4
> READ of size 1 at 0x409e32a9 thread T0
> #0 0x409ccc57 (/system/lib/libsqlite.so+0xd5c57)
> #1 0x409684db (/system/lib/libsqlite.so+0x714db)
> ...
> ... ...
> 0x409e32a9 is located 55 bytes to the left of global variable '*.LC1241'
> from 'external/sqlite/dist/sqlite3.c' (0x409e32e0) of size 10
> '*.LC1241' is ascii string 'unix-none'
> 0x409e32a9 is located 4 bytes to the right of global variable '*.LC1240'
> from 'external/sqlite/dist/sqlite3.c' (0x409e32a0) of size 5
> '*.LC1240' is ascii string 'unix'
>
> The error code is in the sqlite3.c:
> if( memcmp(pVfs->zName,"unix-excl",10)==0 ){
> pNew->ctrlFlags |= UNIXFILE_EXCL;
> }
>
> --
> 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.
Re: Problem about using LLVM Asan for checking android shared lib like libhwui.so...
On Wed, Jul 23, 2014 at 3:55 PM, 'Evgeniy Stepanov' via address-sanitizer wrote: > Yes. In fact, to all platforms that need LD_PRELOAD-style hacks. Yeah, this would be a useful feature. I see if we can implement this. -Y -- 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.
Re: Problem about using LLVM Asan for checking android shared lib like libhwui.so...
On Wed, Jul 23, 2014 at 3:23 PM, 'Evgeniy Stepanov' via address-sanitizer wrote: > There is an idea that I > always wanted to implement for ASan applications to re-exec themselves > if they are run with asanwrapper (i.e. without ASan runtime library in > LD_PRELOAD list). In that case ASan would add itself to LD_PRELOAD and > call exec() on itself. You mean porting the Mac's reexec hack to other platforms as well? -Y -- 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.
Re: Reverse poisoning
> one ring buffer for all frame sizes Ok, this was nonsense. I actually had in mind a per-thread buffer for fake stack frames. -Y -- 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.
Re: Reverse poisoning
> This is somewhat harder to do in user-space, because we don't > necessary know when a stack is mapped, when it's unmapped and what's > its size (on linux, windows and mac). We could re-use fake stack for this but make it slimmer e.g. have just one ring buffer for all frame sizes. -Y -- 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.
Re: Reverse poisoning
On Wed, Jul 16, 2014 at 7:59 PM, 'Dmitry Vyukov' via address-sanitizer wrote: > Also I am not sure what it will give us. For malloc it already works > in the best possible way. For other memory it will only verify asan's > guessing of what memory is OK to access. This can become a constant > pain point w/o any benefits. My colleagues from kernel team pointed out that forced poisoning of stack frames could serve as a poor man's UAR detector (especially if frames could be interspersed with randomly sized poisoned areas). -Y -- 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.
Re: Stack instrumentation for kernel.
Dmitry,
> Yes, -fsanitize=kernel-address is highly desirable asap. Because
> current scheme is incompatible with inline instrumentation for kernel.
> So we need to start telling people to use -fsanitize=kernel-address as
> early as possible.
Could you check the attached patch which implements
-fsanitize=kernel-address on top of userspace Asan? It worked for us
here. I'm going to send it for GCC upstream review if it works for
you.
-Y
--
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.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index a83f6c6..70f9c2b 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -5376,6 +5376,11 @@ more details. The run-time behavior can be influenced
using the
@url{https://code.google.com/p/address-sanitizer/wiki/Flags#Run-time_flags} for
a list of supported options.
+@item -fsanitize=kernel-address
+@opindex fsanitize=kernel-address
+Enable AddressSanitizer for Linux kernel.
+See
@uref{http://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel}
for more details.
+
@item -fsanitize=thread
@opindex fsanitize=thread
Enable ThreadSanitizer, a fast data race detector.
diff --git a/gcc/flag-types.h b/gcc/flag-types.h
index 2849455..04038f6 100644
--- a/gcc/flag-types.h
+++ b/gcc/flag-types.h
@@ -231,6 +231,7 @@ enum sanitize_code {
SANITIZE_FLOAT_DIVIDE = 1 << 12,
SANITIZE_FLOAT_CAST = 1 << 13,
SANITIZE_BOUNDS = 1 << 14,
+ SANITIZE_KERNEL_ADDRESS = 1 << 15,
SANITIZE_UNDEFINED = SANITIZE_SHIFT | SANITIZE_DIVIDE | SANITIZE_UNREACHABLE
| SANITIZE_VLA | SANITIZE_NULL | SANITIZE_RETURN
| SANITIZE_SI_OVERFLOW | SANITIZE_BOOL | SANITIZE_ENUM
diff --git a/gcc/opts.c b/gcc/opts.c
index 419a074..42fef36 100644
--- a/gcc/opts.c
+++ b/gcc/opts.c
@@ -1475,6 +1475,7 @@ common_handle_option (struct gcc_options *opts,
{ "float-cast-overflow", SANITIZE_FLOAT_CAST,
sizeof "float-cast-overflow" - 1 },
{ "bounds", SANITIZE_BOUNDS, sizeof "bounds" - 1 },
+ { "kernel-address", SANITIZE_KERNEL_ADDRESS, sizeof
"kernel-address" - 1 },
{ NULL, 0, 0 }
};
const char *comma;
@@ -1520,6 +1521,25 @@ common_handle_option (struct gcc_options *opts,
the null pointer checks. */
if (flag_sanitize & SANITIZE_NULL)
opts->x_flag_delete_null_pointer_checks = 0;
+
+ /* Kernel ASan implies normal ASan but does not yet support
+ all features. */
+ if (flag_sanitize & SANITIZE_KERNEL_ADDRESS)
+ {
+ flag_sanitize |= SANITIZE_ADDRESS;
+ maybe_set_param_value
(PARAM_ASAN_INSTRUMENTATION_WITH_CALL_THRESHOLD, 0,
+ opts->x_param_values,
+ opts_set->x_param_values);
+ maybe_set_param_value (PARAM_ASAN_GLOBALS, 0,
+ opts->x_param_values,
+ opts_set->x_param_values);
+ maybe_set_param_value (PARAM_ASAN_STACK, 0,
+ opts->x_param_values,
+ opts_set->x_param_values);
+ maybe_set_param_value (PARAM_ASAN_USE_AFTER_RETURN, 0,
+ opts->x_param_values,
+ opts_set->x_param_values);
+ }
break;
}
Re: Stack instrumentation for kernel.
On Tue, Jul 8, 2014 at 5:16 PM, Alexey Preobrazhensky wrote:
>
>
> On Friday, June 20, 2014 6:26:37 PM UTC+4, Yuri Gribov wrote:
>>
>> On Fri, Jun 20, 2014 at 4:50 PM, Andrey Ryabinin
>> wrote:
>> > --param asan-memintrin=0 --param asan-fixed-shadow-offset=0
>>
>> This wasn't yet upstreamed.
>
>
> Can you share remaining patches with us?
Sure, attached. The patch is somewhat ugly: asan-fixed-shadow-offset
is only supported for stack prologues/epilogues (memory accesses still
use constant shadow offset) because I only needed to make it work for
Kasan. I can further improve this patch (and probably upstream it) if
people find it useful.
-Y
--
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.
commit 220af201fe980065f5ee6f74a46380b93744c68f
Author: Yury Gribov
Date: Tue Jun 3 12:11:15 2014 +0400
2014-05-27 Yury Gribov
gcc/ChangeLog:
* asan.c (asan_emit_stack_protection): Support non-fixed shadow
offset.
* params.def (PARAM_ASAN_FIXED_SHADOW_OFFSET): New parameter.
* params.h: Likewise.
libsanitizer/ChangeLog:
* asan/asan_rtl.cc (__asan_get_shadow_ptr): New function.
diff --git a/gcc/asan.c b/gcc/asan.c
index 667a662..0b897d9 100644
--- a/gcc/asan.c
+++ b/gcc/asan.c
@@ -952,6 +952,7 @@ asan_emit_stack_protection (rtx base, rtx pbase, unsigned
int alignb,
HOST_WIDE_INT *offsets, tree *decls, int length)
{
rtx shadow_base, shadow_mem, ret, mem, orig_base, lab;
+ rtx shadow_start, shadow_start_lab = NULL_RTX, shadow_start_lab2 = NULL_RTX;
char buf[30];
unsigned char shadow_bytes[4];
HOST_WIDE_INT base_offset = offsets[length - 1];
@@ -1047,7 +1048,7 @@ asan_emit_stack_protection (rtx base, rtx pbase, unsigned
int alignb,
use_after_return_class);
ret = init_one_libfunc (buf);
rtx addr = convert_memory_address (ptr_mode, base);
- ret = emit_library_call_value (ret, NULL_RTX, LCT_NORMAL, ptr_mode, 2,
+ ret = emit_library_call_value (ret, NULL_RTX, LCT_PURE, ptr_mode, 2,
GEN_INT (asan_frame_size
+ base_align_bias),
TYPE_MODE (pointer_sized_int_node),
@@ -1085,10 +1086,27 @@ asan_emit_stack_protection (rtx base, rtx pbase,
unsigned int alignb,
shadow_base = expand_binop (Pmode, lshr_optab, base,
GEN_INT (ASAN_SHADOW_SHIFT),
NULL_RTX, 1, OPTAB_DIRECT);
- shadow_base
-= plus_constant (Pmode, shadow_base,
-targetm.asan_shadow_offset ()
-+ (base_align_bias >> ASAN_SHADOW_SHIFT));
+ if (ASAN_FIXED_SHADOW_OFFSET)
+{
+ shadow_base
+= plus_constant (Pmode, shadow_base,
+targetm.asan_shadow_offset ()
++ (base_align_bias >> ASAN_SHADOW_SHIFT));
+}
+ else
+{
+ ret = init_one_libfunc ("__asan_get_shadow_ptr");
+ shadow_start = gen_reg_rtx (ptr_mode);
+ emit_library_call_value (ret, shadow_start, LCT_NORMAL, ptr_mode, 0);
+ shadow_start_lab = gen_label_rtx ();
+ int very_unlikely = REG_BR_PROB_BASE / 100 - 1;
+ emit_cmp_and_jump_insns (shadow_start, const0_rtx, EQ, NULL_RTX,
+ VOIDmode, 0, shadow_start_lab, very_unlikely);
+
+ shadow_base
+= expand_binop (Pmode, add_optab, shadow_base, shadow_start, NULL_RTX,
1, OPTAB_DIRECT);
+ shadow_base = plus_constant (Pmode, shadow_base, (base_align_bias >>
ASAN_SHADOW_SHIFT));
+}
gcc_assert (asan_shadow_set != -1
&& (ASAN_RED_ZONE_SIZE >> ASAN_SHADOW_SHIFT) == 4);
shadow_mem = gen_rtx_MEM (SImode, shadow_base);
@@ -1137,6 +1155,8 @@ asan_emit_stack_protection (rtx base, rtx pbase, unsigned
int alignb,
cur_shadow_byte = ASAN_STACK_MAGIC_MIDDLE;
}
do_pending_stack_adjust ();
+ if (shadow_start_lab != NULL_RTX)
+emit_label (shadow_start_lab);
/* Construct epilogue sequence. */
start_sequence ();
@@ -1182,6 +1202,16 @@ asan_emit_stack_protection (rtx base, rtx pbase,
unsigned int alignb,
emit_label (lab2);
}
+ if (!ASAN_FIXED_SHADOW_OFFSET)
+{
+// ret = init_one_libfunc ("__asan_get_shadow_ptr");
+// shadow_start = emit_library_call_value (ret, NULL_RTX, LCT_NORMAL,
ptr_mode, 0);
+ shadow_start_lab2 = gen_label_rtx ();
+ int very_unlikely = REG_BR_PROB_BASE / 100 - 1;
+ emit_cmp_and_jump_insns (shadow_start, const0_rtx, EQ, NULL_RTX,
+ VOIDmode, 0, shad
Re: Dontneeding dead fake frames
> Most of the fake frames are less than page size > so madvise can only > be applied to large fake frames and there are just a few of them. I may be missing something but I thought that sum of small frames may grow large in e.g. message-driven apps. > Also, madvise is a syscall so we will trade RAM for CPU. Yeah but we don't have to call madvise on every stack deallocation. -Y -- 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.
Dontneeding dead fake frames
All, Has anyone considered doing madvise(DONTNEED) on dead fake frames to save RAM? -Y -- 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.
Re: Stack instrumentation for kernel.
On Fri, Jun 20, 2014 at 4:50 PM, Andrey Ryabinin wrote: > --param asan-memintrin=0 --param asan-fixed-shadow-offset=0 This wasn't yet upstreamed. > And with --param asan-stack=1 it also works now. This requires asan-fixed-shaw-offset=0. -Y -- 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.
Re: Stack instrumentation for kernel.
All, FYI it should now be possible to replace existing Kasan implementation (which abuses TSan) with stock userspace Asan. We (well, Andrew) have successfully sanitized kernel with CFLAGS = -fsanitize=address --param asan-stack=0 --param asan-globals=0 --param use-after-return=0 --param asan-instrumentation-with-call-threshold=0. As Dmitry pointed out, we could hide all these --param's under -fsanitize=kernel-address. @Andrey: did I miss anything in CFLAGS? -Y -- 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.
Re: Future of -fsanitize-recover
> there are downsides: one bug may trigger another report Doesn't UBSan have the same problem? > the user will spend time investigating more reports than needed. True but that would be a concious trade-off. >>> It will create more problems to users and developers than it will solve. >> >> Agreed, it may cause false positives, duplicated reports, etc. But it >> does not have to be enabled by default. > > These, and many more. Just FYI this works quite well for us in practice (we use patched gcc). E.g. I was able to detect and fix a dozen of bugs in large app in 3 or 4 iterations instead of 10. > I remain unconvinced... I was expecting this :) -Y -- 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.
Re: Future of -fsanitize-recover
> What are your reasons? Collect more memory errors from a single run. E.g. I have an "embedded" system at hand which requires at least 20m for typical fix-compile-run cycle (and some steps like reflashing the device are manual). Being able to fix more than one error at once would significantly reduce debugging time. > It will create more problems to users and developers than it will solve. Agreed, it may cause false positives, duplicated reports, etc. But it does not have to be enabled by default. -Y -- 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.
Future of -fsanitize-recover
All, Are there plans to extend -fsanitize-recover beyond UBSan? It seems that adding this functionality to e.g. ASan would be trivial. -Y -- 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.
Re: Stack instrumentation for kernel.
>>> I propose to add -fsanitize=kernel-address when the first patch is >>> committed. Now it will just enable "-fsanitize=address >>> -asan-instrumentation-with-call-threshold=-1" internally. But later we >>> will be able to change instrumentation for kernel under the hood w/o >>> disturbing users. >> >> Yup, sounds right. Note that this will (unfortunately) be >> --param asan-instrumentation-with-call-threshold=0 (not -1) >> because GCC developers don't want to allow negative parameters. > > If it all happens under the covers of -fsanitize=kernel-address, it > does not matter much, right? Sure. -Y -- 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.
Re: Stack instrumentation for kernel.
Dmitry, > I propose to add -fsanitize=kernel-address when the first patch is > committed. Now it will just enable "-fsanitize=address > -asan-instrumentation-with-call-threshold=-1" internally. But later we > will be able to change instrumentation for kernel under the hood w/o > disturbing users. Yup, sounds right. Note that this will (unfortunately) be --param asan-instrumentation-with-call-threshold=0 (not -1) because GCC developers don't want to allow negative parameters. > As for __kasan vs __asan prefixes, I don't care too much. > __asan will work for us. Ok. Or we could throw in a some __attribute__((alias))'es. > Also, does gcc asan pass emit ctors into every translation unit? It > was not working for us a year ago in kernel. Do you plan to disable > them in kernel instrumentation mode? We had some discussion with Andrey but haven't yet fleshed anything out. For now we will disable them with --param asan-globals=0. -Y -- 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.
Re: Stack instrumentation for kernel.
> alternative to __kasan_instrument_stack is to implement > __asan_get_shadow_ptr(addr) and then reuse the existing inline stack > instrumentation. This would be even easier. -Y -- 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.
Re: Stack instrumentation for kernel.
On Mon, May 26, 2014 at 7:57 PM, 'Dmitry Vyukov' via address-sanitizer wrote: > What exactly do you want to write? We need to coordinate. >From compiler's side we'll probably start experimenting with stack instrumentation. Provided that we stick with function calls, I like the frame metadata approach most (i.e. insert calls to __kasan_instrument_stack/__kasan_uninstrument_stack at start/end of function). -- 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.
Re: Stack instrumentation for kernel.
> Actually I advanced much further than just building and booting. I did > some work on the basis of existing > implementation from https://github.com/xairy/linux. First of all I > removed all x86 specific hacks, so it's > cross-platform now (currently I'm running sanitized kernel on ARM board). > Also added SLUB and buddy allocator support. > There are some other minor improvements, like proper integration with > kbuild instead of nasty gcc.py script... We also sent outline instrumentation patches to GCC (https://gcc.gnu.org/ml/gcc-patches/2014-05/msg02194.html) so perhaps Kasan would soon be usable with mainline compiler. -Y -- 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.
Re: Asan DSO check overly strict
>>> So, I think we should either fix the check or remove it.
>>
>> After spending too much time debugging symbol resolution conflicts,
>> I'd try my best to have _some_ checking in runtime.
>>
>> One option (proposed by Jakub) would be to check that libasan precedes
>> libc.so, libpthread.so, etc.
>> The code is going to be somewhat ugly though...
> Let's try and see the code?
I had something like this in mind.
-Y
--
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.
Index: test/asan/TestCases/Linux/asan_dlopen_test.cc
===
--- test/asan/TestCases/Linux/asan_dlopen_test.cc (revision 209499)
+++ test/asan/TestCases/Linux/asan_dlopen_test.cc (working copy)
@@ -11,4 +11,4 @@
return 0;
}
-// CHECK: ASan runtime does not come first in initial library list
+// CHECK: ASan runtime does not precede
Index: lib/asan/asan_linux.cc
===
--- lib/asan/asan_linux.cc (revision 209499)
+++ lib/asan/asan_linux.cc (working copy)
@@ -85,19 +85,43 @@
void AsanCheckDynamicRTPrereqs() {}
void AsanCheckIncompatibleRT() {}
#else
-static int FindFirstDSOCallback(struct dl_phdr_info *info, size_t size,
-void *data) {
- // Continue until the first dynamic library is found
+static bool IsDynamicRTName(const char *libname) {
+ return internal_strstr(libname, "libclang_rt.asan") ||
+internal_strstr(libname, "libasan.so");
+}
+
+static int VerifyDSOOrdering(struct dl_phdr_info *info, size_t size,
+void *) {
if (!info->dlpi_name || info->dlpi_name[0] == 0)
return 0;
- *(const char **)data = info->dlpi_name;
- return 1;
+ if (IsDynamicRTName(info->dlpi_name))
+return 1;
+
+ static const char *stdlibs[] = {
+"/libstdc++.so",
+"/libpthread.so",
+"/libdl.so",
+"/libm.so",
+"/libc.so",
+0
+ };
+
+ for (const char **lib = stdlibs; *lib; ++lib) {
+if (internal_strstr(info->dlpi_name, *lib)) {
+ Report("ASan runtime does not precede %s in initial library list; "
+ "you should either link runtime to your application or "
+ "manually preload it with LD_PRELOAD.\n", *lib);
+ Die();
+}
+ }
+
+ return 0;
}
-static bool IsDynamicRTName(const char *libname) {
- return internal_strstr(libname, "libclang_rt.asan") ||
-internal_strstr(libname, "libasan.so");
+void AsanCheckDynamicRTPrereqs() {
+ // Ensure that dynamic RT precedes libc in list of loaded DSOs
+ dl_iterate_phdr(VerifyDSOOrdering, 0);
}
static void ReportIncompatibleRT() {
@@ -105,18 +129,6 @@
Die();
}
-void AsanCheckDynamicRTPrereqs() {
- // Ensure that dynamic RT is the first DSO in the list
- const char *first_dso_name = 0;
- dl_iterate_phdr(FindFirstDSOCallback, &first_dso_name);
- if (first_dso_name && !IsDynamicRTName(first_dso_name)) {
-Report("ASan runtime does not come first in initial library list; "
- "you should either link runtime to your application or "
- "manually preload it with LD_PRELOAD.\n");
-Die();
- }
-}
-
void AsanCheckIncompatibleRT() {
if (ASAN_DYNAMIC) {
if (__asan_rt_version == ASAN_RT_VERSION_UNDEFINED) {
Re: Asan DSO check overly strict
>> The easiest solution is probably to hide current warning under verbosity > 0
>
> A check under verbosity > 0 is almost ("but not quite entirely")
> useless because verbosity > 0
> is not a normal mode of operation.
Well, Asan team typically asks users to provide verbose reports in
case of error.
If the check is there, we have a chance to detect it straight away
instead of guessing ("try LD_PRELOAD", "try instrumenting your
executable", "try -static-libasan").
> So, I think we should either fix the check or remove it.
After spending too much time debugging symbol resolution conflicts,
I'd try my best to have _some_ checking in runtime.
One option (proposed by Jakub) would be to check that libasan precedes
libc.so, libpthread.so, etc.
The code is going to be somewhat ugly though...
-Y
--
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.
Re: Stack instrumentation for kernel.
Kostya, >> I'm wondering, have you thought about implementing stack instrumentation for >> linux kernel? > Of course we did! This is in our near term plans. When do you think we can expect this feature? > We first need to prepare a reasonable patch to GCC that implements > kasan instrumentation (in progress). Could you provide some details about Kasan instrumentation plans? Are you going to keep function calls or do inline instrumentation similar to userspace Asan? > Then we are going to extend it to support stack overflow instrumentation. Can we help on compiler/kernel side? -Y -- 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.
Re: Out-of-line memory checks
> asan may still emit inlined checks for things like 'long double'
Is this intentional? How about replacing these with a call to
__asan_{load,store}N?
-Y
--
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.
Re: Out-of-line memory checks
>> GCC with it's default dynamic runtime would suffer quite a bit... > > Only if the out-line calls will be used (in clang, this is a > workaround for a bad compile-time, we'll use out-line functions only > when there are more than 1 checks in a function). Right, this may be enough for Clang's needs (pathalogical codes with thousands memory accesses) but will slow down my usecase quite a bit (I admit that I may be the only one who's interested though). I can probably get away with manually adding -lmy_private_asan_checks to CFLAGS to override default Asan callback implemenation with it's PLT overheads but IMHO making upstream implementation slower than necessary is questionable. > Hold on a bit here. First, my recent patches have a bug around > handling of memset&co, > second I am considering to competely replace memset&co calls with > another function call -- this will solve some other problems as well, > but it needs performance evaluation... Cool, ping us when it's in. -Y -- 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.
Re: Out-of-line memory checks
>> Solution here is obvious - throw in another static lib that would get >> linked into DSOs. But this would complicate driver of course. > > immensely GCC with it's default dynamic runtime would suffer quite a bit... -Y -- 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.
Re: Out-of-line memory checks
>> BTW note that we will suffer significant PLT penalty in sanitized shared >> libs. > > Don't use shared libs :) I don't ;) - it's all about the users. Solution here is obvious - throw in another static lib that would get linked into DSOs. But this would complicate driver of course. -Y -- 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.
Re: Out-of-line memory checks
> You call __asan_report_load8 directly. > This will only work if __asan_load8 does not have its own frame. You mean you don't want asan callbacks to be present in stacktraces? > My version lacked the UNLIKELY trick. fixed. Cool, upstream code seems to run really fast now: 16 sec. (vs my 17.8 sec.). Looks like outline overhead is only 300% now (compared to 200% for normal inline ASan) which is probably acceptable. And we'll have to work around ABI to improve further. Some suggestions: * can we move separate calls for begin/end for intrinsics (and larger memory accesses) into callbacks ? * can we remove check for size == 0 and perform it in callback instead ? I can submit a patch if you are ok with those. BTW note that we will suffer significant PLT penalty in sanitized shared libs. -Y -- 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.
Re: Out-of-line memory checks
Re-attaching updated implementation just in case.
On Mon, Apr 21, 2014 at 10:33 AM, Yuri Gribov wrote:
>>> So even though my implementation is slightly faster we're still
>>> getting a 70% perf hit.
>> interesting.
>>
>> can you show the assembly (objdump -d) for __asan_load8 in both variants?
>
> My disas:
>
> 004cf6a0 <__asan_load8>:
> 4cf6a0: 48 89 f8mov%rdi,%rax
> 4cf6a3: 48 c1 e8 03 shr$0x3,%rax
> 4cf6a7: 80 b8 00 80 ff 7f 00cmpb $0x0,0x7fff8000(%rax)
> 4cf6ae: 75 08 jne4cf6b8 <__asan_load8+0x18>
> 4cf6b0: f3 c3 repz retq
> 4cf6b2: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1)
> 4cf6b8: e9 f3 55 fc ff jmpq 494cb0 <__asan_report_load8>
> 4cf6bd: 0f 1f 00nopl (%rax)
>
> And here's the trunk version:
>
> 00493b00 <__asan_load8>:
> 493b00: 48 89 f8mov%rdi,%rax
> 493b03: 48 c1 e8 03 shr$0x3,%rax
> 493b07: 80 b8 00 80 ff 7f 00cmpb $0x0,0x7fff8000(%rax)
> 493b0e: 74 40 je 493b50 <__asan_load8+0x50>
> 493b10: 48 8b 05 51 83 26 00mov0x268351(%rip),%rax
># 6fbe68 <_DYNAMIC+0x13a0>
> 493b17: 48 8b 00mov(%rax),%rax
> 493b1a: 48 85 c0test %rax,%rax
> 493b1d: 74 09 je 493b28 <__asan_load8+0x28>
> 493b1f: 48 89 38mov%rdi,(%rax)
> 493b22: c3 retq
> 493b23: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
> 493b28: 55 push %rbp
> 493b29: 48 89 f9mov%rdi,%rcx
> 493b2c: 41 b9 08 00 00 00 mov$0x8,%r9d
> 493b32: 45 31 c0xor%r8d,%r8d
> 493b35: 48 89 e5mov%rsp,%rbp
> 493b38: 48 83 ec 10 sub$0x10,%rsp
> 493b3c: 48 8b 7d 08 mov0x8(%rbp),%rdi
> 493b40: 48 8d 55 f8 lea-0x8(%rbp),%rdx
> 493b44: 48 89 eemov%rbp,%rsi
> 493b47: e8 64 e3 ff ff callq 491eb0 <__asan_report_error>
> 493b4c: c9 leaveq
> 493b4d: 0f 1f 00nopl (%rax)
> 493b50: f3 c3 repz retq
> 493b52: 66 66 66 66 66 2e 0fdata32 data32 data32 data32
> nopw %cs:0x0(%rax,%rax,1)
> 493b59: 1f 84 00 00 00 00 00
>
>> If you want to rely on a custom ABI, you should implement in on both
>> callee and caller sides.
>
> Sure.
>
>> That might indeed improve the speed, but imho is not worth it here.
>
> I still think that most of the overhead comes from ABI overheads (IMHO
> x86/amd64 are particularly bad at this). E.g. removing _all_ code from
> callbacks results in 16 sec runtime (so callback code overhead is only
> (17.3 - 16)/(17.3 - 11) = 20%) so improving it further is practically
> worthless.
>
> -Y
--
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.
#include "asan_internal.h"
#include "asan_mapping.h"
// FIXME: add optimized implementation for ARM.
#define DEFINE_ASAN_CHECK(type, size) \
extern "C"\
void __asan_report_ ## type ## size(uptr addr); \
extern "C" INTERFACE_ATTRIBUTE\
void __asan_ ## type ## size(uptr addr); \
void __asan_ ## type ## size(uptr addr) { \
int shadow_val = *(s8 *)MEM_TO_SHADOW(addr);\
int last = (addr & 7) + size - 1; \
if (UNLIKELY(shadow_val && last >= shadow_val)) \
__asan_report_ ## type ## size(addr); \
}
DEFINE_ASAN_CHECK(load, 1)
DEFINE_ASAN_CHECK(load, 2)
DEFINE_ASAN_CHECK(load, 4)
DEFINE_ASAN_CHECK(store, 1)
DEFINE_ASAN_CHECK(store, 2)
DEFINE_ASAN_CHECK(store, 4)
#define DEFINE_ASAN_CHECK8(type)\
extern "C"\
void __asan_report_ ## type ## 8(uptr addr); \
extern "C" INTERFACE_ATTRIBUTE\
void __asan_ ## type ## 8(uptr addr); \
void __asan_ ## type ## 8(uptr addr) {\
int shadow_val = *(s8 *)MEM_TO_SHADOW(addr);\
if (UNLIKELY(shadow_val)) \
Re: Out-of-line memory checks
>> So even though my implementation is slightly faster we're still >> getting a 70% perf hit. > interesting. > > can you show the assembly (objdump -d) for __asan_load8 in both variants? My disas: 004cf6a0 <__asan_load8>: 4cf6a0: 48 89 f8mov%rdi,%rax 4cf6a3: 48 c1 e8 03 shr$0x3,%rax 4cf6a7: 80 b8 00 80 ff 7f 00cmpb $0x0,0x7fff8000(%rax) 4cf6ae: 75 08 jne4cf6b8 <__asan_load8+0x18> 4cf6b0: f3 c3 repz retq 4cf6b2: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1) 4cf6b8: e9 f3 55 fc ff jmpq 494cb0 <__asan_report_load8> 4cf6bd: 0f 1f 00nopl (%rax) And here's the trunk version: 00493b00 <__asan_load8>: 493b00: 48 89 f8mov%rdi,%rax 493b03: 48 c1 e8 03 shr$0x3,%rax 493b07: 80 b8 00 80 ff 7f 00cmpb $0x0,0x7fff8000(%rax) 493b0e: 74 40 je 493b50 <__asan_load8+0x50> 493b10: 48 8b 05 51 83 26 00mov0x268351(%rip),%rax # 6fbe68 <_DYNAMIC+0x13a0> 493b17: 48 8b 00mov(%rax),%rax 493b1a: 48 85 c0test %rax,%rax 493b1d: 74 09 je 493b28 <__asan_load8+0x28> 493b1f: 48 89 38mov%rdi,(%rax) 493b22: c3 retq 493b23: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1) 493b28: 55 push %rbp 493b29: 48 89 f9mov%rdi,%rcx 493b2c: 41 b9 08 00 00 00 mov$0x8,%r9d 493b32: 45 31 c0xor%r8d,%r8d 493b35: 48 89 e5mov%rsp,%rbp 493b38: 48 83 ec 10 sub$0x10,%rsp 493b3c: 48 8b 7d 08 mov0x8(%rbp),%rdi 493b40: 48 8d 55 f8 lea-0x8(%rbp),%rdx 493b44: 48 89 eemov%rbp,%rsi 493b47: e8 64 e3 ff ff callq 491eb0 <__asan_report_error> 493b4c: c9 leaveq 493b4d: 0f 1f 00nopl (%rax) 493b50: f3 c3 repz retq 493b52: 66 66 66 66 66 2e 0fdata32 data32 data32 data32 nopw %cs:0x0(%rax,%rax,1) 493b59: 1f 84 00 00 00 00 00 > If you want to rely on a custom ABI, you should implement in on both > callee and caller sides. Sure. > That might indeed improve the speed, but imho is not worth it here. I still think that most of the overhead comes from ABI overheads (IMHO x86/amd64 are particularly bad at this). E.g. removing _all_ code from callbacks results in 16 sec runtime (so callback code overhead is only (17.3 - 16)/(17.3 - 11) = 20%) so improving it further is practically worthless. -Y -- 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.
Re: Out-of-line memory checks
>> I wonder where such big difference is coming from. I'll examine perf
>> when I finally get my hands on SPEC2006.
>
> You don't need SPEC, just run something small like bzip2.
Ok, good to know. Here are my results for bunzipping a vmtouched 100M file:
gcc:
0m6.315s
clang:
0m5.570s
clang -fsanitize=address:
0m10.961s
clang -fsanitize=address -mllvm -asan-instrumentation-with-call-threshold=0:
0m21.988s
clang -fsanitize=address -mllvm -asan-outline-checks (my
implementation, see attach):
0m17.345s
So even though my implementation is slightly faster we're still
getting a 70% perf hit.
> regular asan instrumentation requires 1 load.
> a call, which itself does 1 load, costs two more loads (call and ret),
Well, these memory accesses are always cached so I wouldn't expect
them to hurt that much. May make sense to profile of course.
> besides the call puts more pressure on the reg allocator which causes more
> spills.
This sounds reasonable. I wonder if using custom ABI for these
callbacks would help - amd64 marks a lot registers (nine?)
caller-saved whereas checking callbacks only need 3-4 regs on the fast
path. Sadly GCC does not seem to provide generic infrastructure for
custom ABIs.
-Y
--
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.
#include "asan_internal.h"
#include "asan_mapping.h"
// FIXME: add optimized implementation for ARM.
#define DEFINE_ASAN_CHECK(type, size) \
extern "C"\
void __asan_report_ ## type ## size(uptr addr); \
extern "C" INTERFACE_ATTRIBUTE\
void __asan_ ## type ## size(uptr addr); \
void __asan_ ## type ## size(uptr addr) { \
int shadow_val = *(s8 *)MEM_TO_SHADOW(addr);\
int last = (addr & 7) + size - 1; \
if (UNLIKELY(shadow_val && last >= shadow_val)) \
__asan_report_ ## type ## size(addr); \
}
DEFINE_ASAN_CHECK(load, 1)
DEFINE_ASAN_CHECK(load, 2)
DEFINE_ASAN_CHECK(load, 4)
DEFINE_ASAN_CHECK(load, 8)
DEFINE_ASAN_CHECK(store, 1)
DEFINE_ASAN_CHECK(store, 2)
DEFINE_ASAN_CHECK(store, 4)
DEFINE_ASAN_CHECK(store, 8)
// FIXME: this relies on 3-bit shadow scaling
#define DEFINE_ASAN_CHECK16(type)\
extern "C" \
void __asan_report_ ## type ## 16(uptr addr); \
extern "C" INTERFACE_ATTRIBUTE \
void __asan_ ## type ## 16(uptr addr); \
void __asan_ ## type ## 16(uptr addr) {\
int shadow_val1 = *(s8 *)MEM_TO_SHADOW(addr);\
int shadow_val2 = *(s8 *)MEM_TO_SHADOW(addr + 8);\
int last = (addr & 7) + 16 - 1; \
if (UNLIKELY((shadow_val1 && last >= shadow_val1) || \
(shadow_val2 && last >= shadow_val2))) \
__asan_report_ ## type ## 16(addr);\
}
DEFINE_ASAN_CHECK16(load)
DEFINE_ASAN_CHECK16(store)
#define DEFINE_ASAN_CHECK_N(type) \
extern "C" \
void __asan_report_ ## type ## _n(uptr addr, uptr size);\
extern "C" INTERFACE_ATTRIBUTE \
uptr __asan_ ## type ## _n(uptr addr, uptr size); \
uptr __asan_ ## type ## _n(uptr addr, uptr size) { \
if (UNLIKELY(!size)) \
return addr;\
uptr addr_end = addr + size - 1; \
int shadow_val = *(s8 *)MEM_TO_SHADOW(addr); \
int shadow_val_end = *(s8 *)MEM_TO_SHADOW(addr_end); \
int last = addr & 7; \
int last_end = addr_end & 7; \
if (UNLIKELY((shadow_val && last >= shadow_val) ||\
(shadow_val_end && last_end >= shadow_val_end))) \
__asan_report_ ## type ## _n(addr, size); \
return addr; \
}
DEFINE_ASAN_CHECK_N(load)
DEFINE_ASAN_CHECK_N(store)
Re: Out-of-line memory checks
>> > btw, I've run SPEC (test data, C only) and it shows that out-of-line >> > instrumentation is 2x slower. >> >> I wonder whether this is due to PLT redirection. > > clang uses static asan-rt by default, no PLT. Agreed, this will only matter for sanitized shared libraries. I wonder where such big difference is coming from. I'll examine perf when I finally get my hands on SPEC2006. -Y -- 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.
Re: Out-of-line memory checks
>> Meanwhile we've made the first step for "Out-of-line memory checks". Looks like an effort duplication, I've been working on this for the last couple of days. > btw, I've run SPEC (test data, C only) and it shows that out-of-line > instrumentation is 2x slower. I wonder whether this is due to PLT redirection. -Y -- 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.
Re: /dev/byte8
> And unless the savings are really big I'd probably not want the change in > trunk Sure, I was just letting you guys know. This is a rather drastic and incompatible change. -Y -- 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.
Re: /dev/byte8
> More details?
Ok. So currently we initialize shadow memory via anonymous mmap which
effectively fills it with zeros. If we filled it with eights instead
(by mmapping /dev/byte8), we could simplify Asan check to a single
comparison:
byte *shadow_address = MemToShadow(address);
byte shadow_value = *shadow_address;
byte last_accessed_byte = (address & 7) + kAccessSize - 1;
if (last_accessed_byte >= shadow_value) {
ReportError(address, kAccessSize, kIsWrite);
}
-Y
--
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.
