On 01/25/2017 04:06 PM, Jakub Jelinek wrote:
> 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
>
Thank for feedback, fixed in second version. Should I wait for an explicit
acknowledge or
is it somehow more relaxed in case of changes.html docs?
Martin
Martin
>From 3684be26af7c74e9971d07f72c146e887a208fa6 Mon Sep 17 00:00:00 2001
From: marxin <mli...@suse.cz>
Date: Thu, 26 Jan 2017 14:02:00 +0100
Subject: [PATCH] Second version
---
htdocs/gcc-7/changes.html | 48 +++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 48 insertions(+)
diff --git a/htdocs/gcc-7/changes.html b/htdocs/gcc-7/changes.html
index 0df6f16..9bb1f92 100644
--- a/htdocs/gcc-7/changes.html
+++ b/htdocs/gcc-7/changes.html
@@ -47,6 +47,54 @@ a work-in-progress.</h2>
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>
+
+ The option is enabled with <code>-fsanitize=address</code> and disabled
+ with <code>-fsanitize=kernel-address</code>.
+ 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>Sanitization can handle invalid memory stores that are optimized out
+ by the LLVM compiler when using an optimization level.</li>
+ </ul>
+
+ </li>
+
</ul>
<!-- .................................................................. -->
--
2.11.0
