| Message ID | e0925c24-323c-8ce4-1a73-cacdbc5a6fb9@suse.cz |
|---|---|
| State | New |
| Headers | show |
Hi Martin, On 25/01/17 14:54, Martin Liška wrote: > Hello. > > Following patch documents new option -fsanitize-address-use-after-scope which was done for upcoming GCC 7.1. > > Thanks for feedback, > Martin + <li>Using -O2 optimization level (and above) rewrites variables of a GIMPLE + type that are rewritten into SSA. This removes shadow memory usage and + results in faster code.</li> I believe the changes page is targeted towards end users rather than GCC developers and the above description wouldn't make much sense to them. Maybe better to say: "Using -O2 optimization level and above improves shadow memory usage over LLVM" ? Kyrill
On Wed, Jan 25, 2017 at 03:00:19PM +0000, Kyrill Tkachov wrote: > Hi Martin, > > On 25/01/17 14:54, Martin Liška wrote: > > Hello. > > > > Following patch documents new option -fsanitize-address-use-after-scope which was done for upcoming GCC 7.1. > > > > Thanks for feedback, > > Martin > > + <li>Using -O2 optimization level (and above) rewrites variables of a GIMPLE > + type that are rewritten into SSA. This removes shadow memory usage and > + results in faster code.</li> > > I believe the changes page is targeted towards end users rather than GCC developers > and the above description wouldn't make much sense to them. Maybe better to say: > "Using -O2 optimization level and above improves shadow memory usage over LLVM" ? It isn't even correct, we only rewrite vars into SSA that aren't address taken except for the implicit address taking by ASAN_MARK. It is just an implementation detail, I think we just should leave it out, it is up to users to compare our and LLVM -fsanitize=address performance and what it can report if they want. What you should mention is that -fsanitize-address-use-after-scope is on by default if -fsanitize=address and not when -fsanitize=kernel-address. Jakub
--- /tmp/wwwdocs/htdocs/gcc-7/changes.html 2017-01-25 11:10:56.000000000 +0100 +++ htdocs/gcc-7/changes.html 2017-01-25 15:44:54.441943930 +0100 @@ -47,6 +47,55 @@ It can be enabled by using the <code>-fstore-merging</code> option and is enabled by default at <code>-Os</code> and the <code>-O2</code> optimization level or higher.</li> + <li>AddressSanitizer gained a new sanitization option, <code>-fsanitize-address-use-after-scope</code>, + which enables sanitization of variables whose address is taken and used after a scope where the + variable is defined: + <blockquote><pre> +int +main (int argc, char **argv) +{ + char *ptr; + { + char my_char; + ptr = &my_char; + } + + *ptr = 123; + return *ptr; +} + +==28882==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7fffb8dba990 at pc 0x0000004006d5 bp 0x7fffb8dba960 sp 0x7fffb8dba958 +WRITE of size 1 at 0x7fffb8dba990 thread T0 + #0 0x4006d4 in main /tmp/use-after-scope-1.c:10 + #1 0x7f9c71943290 in __libc_start_main (/lib64/libc.so.6+0x20290) + #2 0x400739 in _start (/tmp/a.out+0x400739) + +Address 0x7fffb8dba990 is located in stack of thread T0 at offset 32 in frame + #0 0x40067f in main /tmp/use-after-scope-1.c:3 + + This frame has 1 object(s): + [32, 33) 'my_char' <== Memory access at offset 32 is inside this variable + </pre></blockquote> + + Compared to the LLVM compiler, where the option already exists, + the implementation in the GCC compiler has couple of improvements and advantages: + <ul> + <li>A complex usage of gotos and case labels are properly handled and should not + report any false positive or false negatives. + </li> + <li>Shadow memory poisoning (and unpoisoning) is optimized out in common situations + where the call is not needed. + </li> + <li>C++ temporaries are sanitized.</li> + <li>Using -O2 optimization level (and above) rewrites variables of a GIMPLE + type that are rewritten into SSA. This removes shadow memory usage and + results in faster code.</li> + <li>Sanitization can handle invalid memory stores that are optimized out + by the LLVM compiler when using an optimization level.</li> + </ul> + + </li> + </ul> <!-- .................................................................. -->