[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20190611161544.GE1506@brightrain.aerifal.cx>
Date: Tue, 11 Jun 2019 12:15:44 -0400
From: Rich Felker <dalias@...c.org>
To: Li Yu <marvin.tms@...wei.com>
Cc: "musl@...ts.openwall.com" <musl@...ts.openwall.com>,
helitao <helitao@...wei.com>,
"Huangqiang (H)" <h.huangqiang@...wei.com>,
Jinyongming <jinyongming@...wei.com>,
leijitang <leijitang@...wei.com>,
"liuyutao (C)" <liuyutao2@...wei.com>,
"Threefifteen Wang(Kunfeng)" <threefifteen.wangkunfeng@...wei.com>,
"Wudilong (Michael)" <wudilong@...wei.com>
Subject: Re: Re: [proposal] Add detection of thread ID in
pthread-related interfaces
On Tue, Jun 11, 2019 at 11:58:00PM +0800, Li Yu wrote:
>
> Thanks for your quick and detailed replies first.
>
> As our copy of POSIX 2003.1™-2017, it said such texts in RATIONALE section of pthread_cancel() feature,
>
> 'If an implementation detects use of a thread ID after the end of its lifetime, it is recommended
> that the function should fail and report an [ESRCH] error. '
>
> I think that it may be a recommended bebhavior in recent revison of POSIX spec.
>
> Another side, in real use cases, many applications are wrote under a
> major libc implementation first, instead of be wrote according to
> POSIX spec texts, so I personally think that compatiblity of libc
> implementation is important than POSIX spec texts, always. In fact,
> we don't have too many widely usable UNIX variants now.
If it was written to glibc and relies on this behavior, you have an
extremely dangerous use-after-free bug that was not caught. Under
slightly different usage patterns, you could very well end up not
getting an error, but instead cancelling, sending a signal to,
detaching, or joining an unrelated thread that was created later. This
has all of the cascading fault problems inherent in use-after-free,
fd-use-after-close, etc.
By crashing immediately, musl has alerted you to the issue and ensured
that it gets fixed before something blows up in production.
I've advocated a lot on this issue, and glibc has also adopted this
convention based on text I wrote:
https://sourceware.org/glibc/wiki/Style_and_Conventions#Invalid_pointers
> Last, I think that features of various libc implementations are
> different is easy to understand and accept, however, someone are
> crash for same feature is not welcome :) If we wanted to use musl as
> a core libc in a open system to support various even third-party
> closed-sources applications, the every new crash after porting new
> system is not a good news. so, it seem that eveny such open system
> need to maintain a in-house patch set to provide better robustness.
You're looking at this backwards. You've gained the ability to
immediately catch your dangerous bugs before you ship them rather than
having them only show up when a particular race is hit.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
