Re: [PATCH] pthread_kill.3: Update to match POSIX.

[enh <enh@google.com>]

On Tue, Nov 12, 2019 at 2:28 PM Florian Weimer <fw@deneb.enyo.de> wrote:
>
> * enh:
>
> > but this is all about *invalid* threads, which obviously can't be
> > joinable. i'm really not sure what you're trying to say.
>
> Uhm, people try use pthread_kill to probe for thread termination.

yes, that's why i'm keen that we make it clearer that this doesn't work.

> Termintation of a non-detached thread doesn't make a thread
> non-joinable, so from a temporal memory safety perspective, that's
> totally fine.  Except that POSIX requires implementations to hide this
> information from callers.
>
> Maybe we are talking past each other, though.
>
> Let's look at what musl does:
>
> int pthread_kill(pthread_t t, int sig)
> {
>         int r;
>         LOCK(t->killlock);
>         r = t->tid ? -__syscall(SYS_tkill, t->tid, sig)
>                 : (sig+0U >= _NSIG ? EINVAL : 0);
>         UNLOCK(t->killlock);
>         return r;
> }
>
> The 0 could be ESRCH to support probing for termination.

no, because the C library has two choices when a thread exits:

1. unmap the thread.

2. keep the thread around for recycling.

if you choose 1 (optimizing for space, like Android), your dereference
is illegal.

if you choose 2 (optimizing for time, as i believe glibc does), your
dereference is fine and you read the zero that the kernel put there
... until the thread is reused. now you're actually looking at a
different thread than the one you think you're looking at. and as a
caller who by definition doesn't know the current state of the thread,
you've no idea whether it's been reused or not. (this is also strictly
the case on Android if ASLR has put a new thread's stack where the old
one used to be.)

there's more detail about this -- and some less unreliable options --
in the Android documentation i linked to in the commit message.