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 <stdio.h> #include <stdlib.h> #include <string.h> #include <new> 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. Sample output from patched GCC & sanitizer: ==12358==ERROR: AddressSanitizer: heap-clobbered-memory-read on address 0x60b00000afb8 at pc 0x000000400ad1 bp 0x7fffffffdca0 sp 0x7fffffffdc98 READ of size 4 at 0x60b00000afb8 thread T0 #0 0x400ad0 in get_value(int*, int) (/tmp/a.out+0x400ad0) #1 0x400bca in main (/tmp/a.out+0x400bca) #2 0x7ffff621960f in __libc_start_main (/lib64/libc.so.6+0x2060f) #3 0x4009a8 in _start (/tmp/a.out+0x4009a8) 0x60b00000afb8 is located 40 bytes inside of 111-byte region [0x60b00000af90,0x60b00000afff) allocated by thread T0 here: #0 0x7ffff6f02128 in __interceptor_malloc ../../../../libsanitizer/asan/asan_malloc_linux.cc:38 #1 0x400ae9 in main (/tmp/a.out+0x400ae9) #2 0x7ffff621960f 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 memory f0 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? *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. Well, as I've briefly described my use-cases, I have couple of questions: a) Are these optimizations interesting enough to be eventually merged as part of sanitizer? b) I see need to create a separate shadow regions for different usages, maybe current shadow memory implementation can be generalized? Thank you for any suggestions, ides. Martin -- You received this message because you are subscribed to the Google Groups "address-sanitizer" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
