This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Specific Linux syscalls for glibc API
- From: Rich Felker <dalias at libc dot org>
- To: libc-alpha at sourceware dot org
- Date: Thu, 19 Nov 2015 10:28:34 -0500
- Subject: Re: Specific Linux syscalls for glibc API
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 10 dot 1511171606330 dot 14808 at digraph dot polyomino dot org dot uk> <564C4DCA dot 3010607 at redhat dot com> <20151118163229 dot GO3818 at brightrain dot aerifal dot cx> <6D83E89737156549AEA25EF9ED712C5D168EDF at DEFTHW99EK1MSX dot ww902 dot siemens dot net>
On Thu, Nov 19, 2015 at 07:21:13AM +0000, Warlich, Christof wrote:
> On 18-11-2015 14:32, Rich Felker wrote:
>
> > It should be noted that there are some serious caveats to using tids
> > directly. Unlike pthread_t, a tid is immediately freed and available
> > for reuse as soon as the thread exits. This means additional
> > synchronization with the target thread's exit is required to avoid
> > TOCTOU races when use them.
>
> I'm not sure if I really got your point here. While there is no doubt that
> synchronization _is_ needed if a tid must never be used after it has become
> invalid (due to the exit of its related thread), I don't see much of a risk
> that a tid value might be reused by a newly created thread any time soon:
> AFAIK, newly allocated tids are, like pids, always incremented. Thus, a
> tid reuse can only happen after wrapping around.
It's easy to force rapid tid reuse just by exhausting the tid/pid
namespace. Applications that assume this does not happen are
vulnerable to attacker-created situations where it does without
further hardening against the issue at the system level.
Rich