[Bug nptl/19430] New: __reclaim_stacks is bogus

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

[Bug nptl/19430] New: __reclaim_stacks is bogus

glaubitz at physik dot fu-berlin.de
https://sourceware.org/bugzilla/show_bug.cgi?id=19430

            Bug ID: 19430
           Summary: __reclaim_stacks is bogus
           Product: glibc
           Version: 2.23
            Status: NEW
          Severity: normal
          Priority: P2
         Component: nptl
          Assignee: unassigned at sourceware dot org
          Reporter: fweimer at redhat dot com
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---

If I read the __reclaim_stacks code correctly, it frees the stack of all other
threads after a fork.  This is not a safe thing to do because pointers to
on-stack data may have been written to global variables or shared with the
current thread by other means, and those objects have to be remain valid after
fork.

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug nptl/19430] __reclaim_stacks is bogus

glaubitz at physik dot fu-berlin.de
https://sourceware.org/bugzilla/show_bug.cgi?id=19430

Torvald Riegel <triegel at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |triegel at redhat dot com

--- Comment #1 from Torvald Riegel <triegel at redhat dot com> ---
I don't think it is required to preserve objects on the stack of threads that
have not been re-created in the child after fork().  POSIX states that only one
thread will exist in the forked child.  This seems equivalent to saying that
all threads are duplicated in the child, but all child but the one that is the
duplicate of the parent thread that called fork() are terminated before that
remaining child thread continues execution.  Given that objects on stacks of
terminated threads are not required to be preserved either, I think this is not
a bug. Please close this bug if you agree with this reasoning.

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug nptl/19430] __reclaim_stacks is bogus

glaubitz at physik dot fu-berlin.de
In reply to this post by glaubitz at physik dot fu-berlin.de
https://sourceware.org/bugzilla/show_bug.cgi?id=19430

--- Comment #2 from Florian Weimer <fweimer at redhat dot com> ---
POSIX says:

“If a multi-threaded process calls fork(), the new process shall contain a
replica of the calling thread and its entire address space”

This suggests to me that other thread stacks and TLS variables need to be
preserved because they are part of the address space as well (at least if the
addresses of these objects have been taken and published in some way to the
current thread).

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug nptl/19430] __reclaim_stacks is bogus

glaubitz at physik dot fu-berlin.de
In reply to this post by glaubitz at physik dot fu-berlin.de
https://sourceware.org/bugzilla/show_bug.cgi?id=19430

--- Comment #3 from Torvald Riegel <triegel at redhat dot com> ---
I think we need a clarification by the Austin Group.

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug nptl/19430] __reclaim_stacks is bogus

glaubitz at physik dot fu-berlin.de
In reply to this post by glaubitz at physik dot fu-berlin.de
https://sourceware.org/bugzilla/show_bug.cgi?id=19430

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |http://austingroupbugs.net/
                   |                            |view.php?id=1114

--- Comment #4 from Florian Weimer <fweimer at redhat dot com> ---
Filed as: http://austingroupbugs.net/view.php?id=1114

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug nptl/19430] __reclaim_stacks is bogus

glaubitz at physik dot fu-berlin.de
In reply to this post by glaubitz at physik dot fu-berlin.de
https://sourceware.org/bugzilla/show_bug.cgi?id=19430

Ralph Böhme <slow at samba dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |slow at samba dot org

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug nptl/19430] __reclaim_stacks is bogus

glaubitz at physik dot fu-berlin.de
In reply to this post by glaubitz at physik dot fu-berlin.de
https://sourceware.org/bugzilla/show_bug.cgi?id=19430

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #5 from Florian Weimer <fweimer at redhat dot com> ---
POSIX thinks this is acceptable.

We will have to see how this interacts with libraries that put references to
thread-local data into global data structures. I suppose those would have to
use an indirection, storing the shared data on the heap, and only a pointer to
that in TLS.

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug nptl/19430] __reclaim_stacks is bogus

glaubitz at physik dot fu-berlin.de
In reply to this post by glaubitz at physik dot fu-berlin.de
https://sourceware.org/bugzilla/show_bug.cgi?id=19430

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at sourceware dot org   |fweimer at redhat dot com
              Flags|                            |security-

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug nptl/19430] __reclaim_stacks is bogus

Sourceware - glibc-bugs mailing list
In reply to this post by glaubitz at physik dot fu-berlin.de
https://sourceware.org/bugzilla/show_bug.cgi?id=19430

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fweimer at redhat dot com

--- Comment #6 from Florian Weimer <fweimer at redhat dot com> ---
C11 says this:


The result of attempting to indirectly access an object with thread storage
duration from a thread other than the one with which the object is associated
is implementation-defined.


So we can say that accessing TLS data after fork is undefined.

--
You are receiving this mail because:
You are on the CC list for the bug.