[Bug sanitizer/66514] New: UBSAN: Add -fsanitize=lifetime

[Bug sanitizer/66514] New: UBSAN: Add -fsanitize=lifetime

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66514

            Bug ID: 66514
           Summary: UBSAN: Add -fsanitize=lifetime
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: sanitizer
          Assignee: unassigned at gcc dot gnu.org
          Reporter: marxin at gcc dot gnu.org
                CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
                    jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

As discussed in PR66487, C++ started to emit a clobber class contruction and
destruction. It would be really nice to have such support in UBSAN, where we
can catch all places which for instance access a member of a class after dtor
is called.

Ideas how to implement that?

Thanks,
Martin

[Bug sanitizer/66514] UBSAN: Add -fsanitize=lifetime

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66514

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
There is some minimal support in -fsanitize=vptr, but that catches only
destructed objects with virtual methods (by disabling the clobbers and clearing
the vptr).
Other than that, this is something that is more in line with the address
sanitizer (which also has very limited support for file scope objects, but only
makes the objects unavailable during construction of each TU, so catches
constructor ordering issues within a single TU).  Other than that, the concept
of making a chunk of memory available at certain point and unavailable at
another point is something -fsanitize=address is able to do.  The question is
what can be done with operator new, e.g. if you have a char buffer in some
class and construct something else at that spot, then destructing it; reading
those bytes afterwards is supposedly UB, but storing there something say with
memcpy shouldn't be invalid.

[Bug sanitizer/66514] UBSAN: Add -fsanitize=lifetime

[y.gribov at samsung dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66514

Yury Gribov <y.gribov at samsung dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |y.gribov at samsung dot com

--- Comment #2 from Yury Gribov <y.gribov at samsung dot com> ---
Related discussion in ASan tracker:
https://code.google.com/p/address-sanitizer/issues/detail?id=73&can=1&q=destructor&colspec=ID%20Type%20Status%20Priority%20OpSys%20Owner%20Summary

[Bug sanitizer/66514] UBSAN: Add -fsanitize=lifetime

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66514

--- Comment #3 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #1)
> There is some minimal support in -fsanitize=vptr, but that catches only
> destructed objects with virtual methods (by disabling the clobbers and
> clearing the vptr).

I see.

> Other than that, this is something that is more in line with the address
> sanitizer (which also has very limited support for file scope objects, but
> only makes the objects unavailable during construction of each TU, so
> catches constructor ordering issues within a single TU).  Other than that,
> the concept of making a chunk of memory available at certain point and
> unavailable at another point is something -fsanitize=address is able to do. 
> The question is what can be done with operator new, e.g. if you have a char
> buffer in some class and construct something else at that spot, then
> destructing it; reading those bytes afterwards is supposedly UB, but storing
> there something say with memcpy shouldn't be invalid.

Ok, after reading your caution and test-cases mentioned in the ASAN tracker, I
think emitting a poison memory call in a dtor for instances that does not use
placement new can be beneficial. However, I can't evaluate if getting such kind
of information in doable in GCC?
>From gcc-bugs-return-488993-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jun 15 11:38:29 2015
Return-Path: <gcc-bugs-return-488993-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 115818 invoked by alias); 15 Jun 2015 11:38:28 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 115757 invoked by uid 48); 15 Jun 2015 11:38:25 -0000
From: "thopre01 at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/66483] [4.9 Regression] ICE (in add_stores, at var-tracking.c:6000) on arm-linux-gnueabihf
Date: Mon, 15 Jun 2015 11:38:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.9.2
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: thopre01 at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.4
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-66483-4-FQAXU9bvpJ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66483-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66483-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-06/txt/msg01325.txt.bz2
Content-length: 277

https://gcc.gnu.org/bugzilla/show_bug.cgi?idf483

--- Comment #9 from Thomas Preud'homme <thopre01 at gcc dot gnu.org> ---
Patch can be backported without any changes and fixes the issue. I'll launch
regression testing tomorrow and ask for it to be committed on 4.9 branch.

[Bug sanitizer/66514] UBSAN: Add -fsanitize=lifetime

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66514

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The thing is that if you poison at the end of destructor, you need to unpoison
it again somewhere, except for file scope variables that when they are
destructed supposedly can't be constructed again.
For automatic variables I guess it depends on whether at runtime
use-after-return is enabled or not (if it is enabled, then the variables are
allocated in a heap object that is completely poisoned afterwards anyway, so
that would work too.  But if use-after-return is disabled, they are allocated
in the normal stack frame and we'd need to unpoison those objects (together
with unpoisoning the guards around them).  And of course we'd need to ensure
the stack space is not reused for other variables.
Then there are objects constructed/destructed in heap space, those are
supposedly fine too, at least I hope a free poisons the memory.  But what about
objects destructed in e.g. mmap allocated area?  And finally objects placement
new constructed in some other variable, there we'd need to unpoison on the
first store to that area (or placement new construction).  That is very much
non-trivial though, at least in the asan framework.

[Bug sanitizer/66514] UBSAN: Add -fsanitize=lifetime

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66514

--- Comment #6 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #5)
> The thing is that if you poison at the end of destructor, you need to
> unpoison it again somewhere, except for file scope variables that when they
> are destructed supposedly can't be constructed again.
> For automatic variables I guess it depends on whether at runtime
> use-after-return is enabled or not (if it is enabled, then the variables are
> allocated in a heap object that is completely poisoned afterwards anyway, so
> that would work too.  But if use-after-return is disabled, they are
> allocated in the normal stack frame and we'd need to unpoison those objects
> (together with unpoisoning the guards around them).  And of course we'd need
> to ensure the stack space is not reused for other variables.
> Then there are objects constructed/destructed in heap space, those are
> supposedly fine too, at least I hope a free poisons the memory.  But what
> about
> objects destructed in e.g. mmap allocated area?  And finally objects
> placement new constructed in some other variable, there we'd need to
> unpoison on the first store to that area (or placement new construction). 
> That is very much non-trivial though, at least in the asan framework.

I see the problem, what if we start with all cases that are safe because a
poisoned memory should not be reused? From the list of cases you described, we
should be able to catch heap-allocated instances. You are right that following
case is already covered by asan (heap-use-after-free):

#include <new>

struct A
{
  A (int _m): m(_m) {}
  int m;
};

int main()
{
  /* Test A */
  A *a = new A(12);
  delete a;

  return a->m == 234;
}

But we miss:
#include <new>

struct A
{
  A (int _m): m(_m) {}
  int m;
};

int main()
{
  /* Test A */
  A *a = new A(12);
  a->~A();

  return a->m == 234;
}

And second doable category should be file scope variables. The rest, including
automatic variables and all these placement new stuff, can be left for future?
What do you think?
Martin
>From gcc-bugs-return-489063-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jun 16 09:51:57 2015
Return-Path: <gcc-bugs-return-489063-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 125140 invoked by alias); 16 Jun 2015 09:51:56 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 125118 invoked by uid 48); 16 Jun 2015 09:51:53 -0000
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/66530] libstdc++ testsuite links to incorrect shared libstdc++ library
Date: Tue, 16 Jun 2015 09:51:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 6.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: minor
X-Bugzilla-Who: redi at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-66530-4-abAQMqhZiC@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66530-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66530-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-06/txt/msg01395.txt.bz2
Content-length: 665

https://gcc.gnu.org/bugzilla/show_bug.cgi?idf530

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Does this patch fix it?

--- a/libstdc++-v3/testsuite/lib/libstdc++.exp
+++ b/libstdc++-v3/testsuite/lib/libstdc++.exp
@@ -226,6 +226,11 @@ proc libstdc++_init { testfile } {
        if [info exists env(LD_LIBRARY_PATH)] {
          verbose -log "LD_LIBRARY_PATH = $env(LD_LIBRARY_PATH)"
        }
+
+        # Cygwin uses PATH not LD_LIBRARY_PATH, see
https://gcc.gnu.org/PR66530
+        if { [ishost "*-*-cygwin*"] } {
+          setenv PATH "$ld_library_path:$env(PATH)"
+        }
     } else {
        set compiler [transform "g++"]
     }