From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14221 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: pengyuanhong Newsgroups: gmane.linux.lib.musl.general Subject: [proposal] Add detection of thread ID in pthread-related interfaces Date: Tue, 11 Jun 2019 11:36:59 +0000 Message-ID: <4CF320752F2B99449115298D4A06B22F34E3DD31@dggemm509-mbx.china.huawei.com> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="_000_4CF320752F2B99449115298D4A06B22F34E3DD31dggemm509mbxchi_" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="175222"; mail-complaints-to="usenet@blaine.gmane.org" Cc: helitao , "Huangqiang (H)" , Jinyongming , leijitang , "liuyutao (C)" , "Liyu (Marvin, Euler Dept)" , "Threefifteen Wang(Kunfeng)" , "Wudilong (Michael)" To: "musl@lists.openwall.com" Original-X-From: musl-return-14237-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jun 11 13:37:26 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1haf5h-000jRx-JI for gllmg-musl@m.gmane.org; Tue, 11 Jun 2019 13:37:25 +0200 Original-Received: (qmail 24556 invoked by uid 550); 11 Jun 2019 11:37:23 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 24522 invoked from network); 11 Jun 2019 11:37:22 -0000 Thread-Topic: [proposal] Add detection of thread ID in pthread-related interfaces Thread-Index: AdUgNlG7C3N+A2ztSByCDuzyqhrlYw== Accept-Language: zh-CN, en-US Content-Language: zh-CN x-originating-ip: [10.133.216.174] X-CFilter-Loop: Reflected Xref: news.gmane.org gmane.linux.lib.musl.general:14221 Archived-At: --_000_4CF320752F2B99449115298D4A06B22F34E3DD31dggemm509mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I find that all pthread-related interfaces directly access the input parameter `pthread_t` without any check. If I pass an invalid thread ID (e.g. an exited thread ID) to these interfaces, then segment fault happens. Both glibc and freebsd can do simple detection of thread ID(pthread_t) passed by user and return ESRCH when no thread can be found. They put all threads in a list or hash table, and update this list or table ever= y time a thread is created or exits. >From the user's point of view, segment fault is unbearable and is not * recoverable in most cases. Instead, returning an error of ESRCH * seems more acceptable. --_000_4CF320752F2B99449115298D4A06B22F34E3DD31dggemm509mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

I find that all pthread-related= interfaces directly access the input

parameter `pthread_t` without a= ny check. If I pass an invalid thread ID

(e.g. an exited thread ID) to t= hese interfaces, then segment fault

happens.

Both glibc and freebsd can do s= imple detection of thread ID(pthread_t)

passed by user and return ESRCH= when no thread can be found. They

put all threads in a list or ha= sh table, and update this list or table every

time a thread is created or exi= ts.

From the user's point of view, = segment fault is unbearable and is not

· &nbs= p; recoverable in most cas= es. Instead, returning an error of ESRCH=

· &nbs= p; seems more acceptable.

--_000_4CF320752F2B99449115298D4A06B22F34E3DD31dggemm509mbxchi_-- From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14222 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: [proposal] Add detection of thread ID in pthread-related interfaces Date: Tue, 11 Jun 2019 15:57:42 +0200 Message-ID: <20190611135741.GY16415@port70.net> References: <4CF320752F2B99449115298D4A06B22F34E3DD31@dggemm509-mbx.china.huawei.com> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="269322"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) Cc: helitao , "Huangqiang (H)" , Jinyongming , leijitang , "liuyutao (C)" , "Liyu (Marvin, Euler Dept)" , "Threefifteen Wang(Kunfeng)" , "Wudilong (Michael)" To: musl@lists.openwall.com Original-X-From: musl-return-14238-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jun 11 15:57:56 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1hahHg-0017xA-Hr for gllmg-musl@m.gmane.org; Tue, 11 Jun 2019 15:57:56 +0200 Original-Received: (qmail 5394 invoked by uid 550); 11 Jun 2019 13:57:54 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 5376 invoked from network); 11 Jun 2019 13:57:53 -0000 Mail-Followup-To: musl@lists.openwall.com, helitao , "Huangqiang (H)" , Jinyongming , leijitang , "liuyutao (C)" , "Liyu (Marvin, Euler Dept)" , "Threefifteen Wang(Kunfeng)" , "Wudilong (Michael)" Content-Disposition: inline In-Reply-To: <4CF320752F2B99449115298D4A06B22F34E3DD31@dggemm509-mbx.china.huawei.com> Xref: news.gmane.org gmane.linux.lib.musl.general:14222 Archived-At: * pengyuanhong [2019-06-11 11:36:59 +0000]: > I find that all pthread-related interfaces directly access the input > parameter `pthread_t` without any check. If I pass an invalid thread ID > (e.g. an exited thread ID) to these interfaces, then segment fault > happens. > > Both glibc and freebsd can do simple detection of thread ID(pthread_t) > passed by user and return ESRCH when no thread can be found. They that's a historical bug in posix: it required ESRCH which is not possible when the thread id is reused, so all such requirments were removed in posix 2008 https://collaboration.opengroup.org/austin/interps/documents/14366/AI-142.txt passing invalid id is simply undefined now, an implementation may still detect the condition and then posix recommends ESRCH in the rationale presumably for backward compatibility: http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_join.html but since applications must not rely on ESRCH, it has questionable value: the obvious safe and secure handling of ub is guaranteed immediate crash: the api contract got violated, the application is misbehaving so there is no reason to believe returning an error will make it non-misbehave. the only way forward is to fix the broken application code, the runtime and tooling can only help by providing better diagnostics about what went wrong. > put all threads in a list or hash table, and update this list or table every > time a thread is created or exits. > > >From the user's point of view, segment fault is unbearable and is not > * recoverable in most cases. Instead, returning an error of ESRCH > * seems more acceptable. From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14223 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [proposal] Add detection of thread ID in pthread-related interfaces Date: Tue, 11 Jun 2019 10:36:24 -0400 Message-ID: <20190611143624.GA1506@brightrain.aerifal.cx> References: <4CF320752F2B99449115298D4A06B22F34E3DD31@dggemm509-mbx.china.huawei.com> <20190611135741.GY16415@port70.net> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="182535"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.5.21 (2010-09-15) Cc: helitao , "Huangqiang (H)" , Jinyongming , leijitang , "liuyutao (C)" , "Liyu (Marvin, Euler Dept)" , "Threefifteen Wang(Kunfeng)" , "Wudilong (Michael)" To: musl@lists.openwall.com Original-X-From: musl-return-14239-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jun 11 16:36:40 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1hahtA-000lCj-E1 for gllmg-musl@m.gmane.org; Tue, 11 Jun 2019 16:36:40 +0200 Original-Received: (qmail 21582 invoked by uid 550); 11 Jun 2019 14:36:37 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 21559 invoked from network); 11 Jun 2019 14:36:37 -0000 Content-Disposition: inline In-Reply-To: <20190611135741.GY16415@port70.net> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:14223 Archived-At: On Tue, Jun 11, 2019 at 03:57:42PM +0200, Szabolcs Nagy wrote: > * pengyuanhong [2019-06-11 11:36:59 +0000]: > > I find that all pthread-related interfaces directly access the input > > parameter `pthread_t` without any check. If I pass an invalid thread ID > > (e.g. an exited thread ID) to these interfaces, then segment fault > > happens. > > > > Both glibc and freebsd can do simple detection of thread ID(pthread_t) > > passed by user and return ESRCH when no thread can be found. They > > that's a historical bug in posix: it required ESRCH > which is not possible when the thread id is reused, > so all such requirments were removed in posix 2008 > https://collaboration.opengroup.org/austin/interps/documents/14366/AI-142.txt > > passing invalid id is simply undefined now, an ^^^^ It was always undefined; the text stating that it's undefined was present in old POSIX too. The "shall fail" text in the ESRCH errors was if "the implementation has detected..." or similar, which oddly imposed a requirement to report something if it was detected, but didn't (and fundamentally couldn't, since it's undetectable with identifier reusage) impose a requirement to detect. The committee recognized that this made no sense and fixed it by removing the "shall fail" text. This was not a functional change, only a clarification, and thus didn't require a new version of the standard, just a TC. Rich From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14224 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Li Yu Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: [proposal] Add detection of thread ID in pthread-related interfaces Date: Tue, 11 Jun 2019 23:58:00 +0800 Message-ID: <2019061123563340760322@huawei.com> References: <4CF320752F2B99449115298D4A06B22F34E3DD31@dggemm509-mbx.china.huawei.com>, <20190611135741.GY16415@port70.net>, <20190611143624.GA1506@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="43410"; mail-complaints-to="usenet@blaine.gmane.org" Cc: helitao , "Huangqiang (H)" , Jinyongming , leijitang , "liuyutao (C)" , "Threefifteen Wang(Kunfeng)" , "Wudilong (Michael)" To: Rich Felker , "musl@lists.openwall.com" Original-X-From: musl-return-14240-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jun 11 18:02:43 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1hajER-000B9H-ID for gllmg-musl@m.gmane.org; Tue, 11 Jun 2019 18:02:43 +0200 Original-Received: (qmail 28069 invoked by uid 550); 11 Jun 2019 16:02:41 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 21899 invoked from network); 11 Jun 2019 15:59:02 -0000 X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.2.10.151[cn] X-Originating-IP: [10.130.164.199] X-CFilter-Loop: Reflected Xref: news.gmane.org gmane.linux.lib.musl.general:14224 Archived-At: ClRoYW5rcyBmb3IgeW91ciBxdWljayBhbmQgZGV0YWlsZWQgcmVwbGllcyBmaXJzdC4KCkFzIG91 ciBjb3B5IG9mIFBPU0lYIDIwMDMuMeKEoi0yMDE3LCBpdCBzYWlkIHN1Y2ggdGV4dHMgaW4gUkFU SU9OQUxFIHNlY3Rpb24gb2YgcHRocmVhZF9jYW5jZWwoKSBmZWF0dXJlLAoKJ0lmIGFuIGltcGxl bWVudGF0aW9uIGRldGVjdHMgdXNlIG9mIGEgdGhyZWFkIElEIGFmdGVyIHRoZSBlbmQgb2YgaXRz IGxpZmV0aW1lLCBpdCBpcyByZWNvbW1lbmRlZAp0aGF0IHRoZSBmdW5jdGlvbiBzaG91bGQgZmFp bCBhbmQgcmVwb3J0IGFuIFtFU1JDSF0gZXJyb3IuICcKCkkgdGhpbmsgdGhhdCBpdCBtYXkgYmUg YSByZWNvbW1lbmRlZCBiZWJoYXZpb3IgaW4gcmVjZW50IHJldmlzb24gb2YgUE9TSVggc3BlYy4K CkFub3RoZXIgc2lkZSwgaW4gcmVhbCB1c2UgY2FzZXMsIG1hbnkgYXBwbGljYXRpb25zIGFyZSB3 cm90ZSB1bmRlciBhIG1ham9yIGxpYmMgaW1wbGVtZW50YXRpb24gZmlyc3QsIGluc3RlYWQgb2Yg YmUgd3JvdGUgYWNjb3JkaW5nIHRvIFBPU0lYIHNwZWMgdGV4dHMsIHNvIEkgcGVyc29uYWxseSB0 aGluayB0aGF0IGNvbXBhdGlibGl0eSBvZiBsaWJjIGltcGxlbWVudGF0aW9uIGlzIGltcG9ydGFu dCB0aGFuIFBPU0lYIHNwZWMgdGV4dHMsIGFsd2F5cy4gSW4gZmFjdCwgd2UgZG9uJ3QgaGF2ZSB0 b28gbWFueSB3aWRlbHkgdXNhYmxlIFVOSVggdmFyaWFudHMgbm93LgoKTGFzdCwgwqBJIHRoaW5r IHRoYXQgZmVhdHVyZXMgb2YgdmFyaW91cyBsaWJjIGltcGxlbWVudGF0aW9ucyBhcmUgZGlmZmVy ZW50IGlzIGVhc3kgdG8gdW5kZXJzdGFuZCBhbmQgYWNjZXB0LCBob3dldmVyLCBzb21lb25lIGFy ZSBjcmFzaCBmb3Igc2FtZSBmZWF0dXJlIGlzIG5vdCB3ZWxjb21lIDopIElmIHdlIHdhbnRlZCB0 byB1c2UgbXVzbCBhcyBhIGNvcmUgbGliYyBpbiBhIG9wZW4gc3lzdGVtIHRvIHN1cHBvcnQgdmFy aW91cyBldmVuIHRoaXJkLXBhcnR5IGNsb3NlZC1zb3VyY2VzIGFwcGxpY2F0aW9ucywgdGhlIGV2 ZXJ5IG5ldyBjcmFzaCBhZnRlciBwb3J0aW5nIG5ldyBzeXN0ZW0gaXMgbm90IGEgZ29vZCBuZXdz LiBzbywgaXQgc2VlbSB0aGF0IGV2ZW55IHN1Y2ggb3BlbiBzeXN0ZW0gbmVlZCB0byBtYWludGFp biBhIGluLWhvdXNlIHBhdGNoIHNldCB0byBwcm92aWRlIGJldHRlciByb2J1c3RuZXNzLgoKRW4s IEkgc2VlLCBtYXkgYmUsIHRoZSBkZXNpZ24gZ29hbCBvZiBtdXNsIGlzIG5vdCBmb3Igb3BlbiBz eXN0ZW0gPwoKVGhhbmtzCgotLS0tLS0tLS0tLS0tLQpMaSBZdcKgCgoKPk9uIFR1ZSwgSnVuIDEx LCAyMDE5IGF0IDAzOjU3OjQyUE0gKzAyMDAsIFN6YWJvbGNzIE5hZ3kgd3JvdGU6Cj4+ICogcGVu Z3l1YW5ob25nIDxwZW5neXVhbmhvbmdAaHVhd2VpLmNvbT4gWzIwMTktMDYtMTEgMTE6MzY6NTkg KzAwMDBdOgo+PiA+IEkgZmluZCB0aGF0IGFsbCBwdGhyZWFkLXJlbGF0ZWQgaW50ZXJmYWNlcyBk aXJlY3RseSBhY2Nlc3MgdGhlIGlucHV0Cj4+ID4gcGFyYW1ldGVyIGBwdGhyZWFkX3RgIHdpdGhv dXQgYW55IGNoZWNrLiBJZiBJIHBhc3MgYW4gaW52YWxpZCB0aHJlYWQgSUQKPj4gPiAoZS5nLiBh biBleGl0ZWQgdGhyZWFkIElEKSB0byB0aGVzZSBpbnRlcmZhY2VzLCB0aGVuIHNlZ21lbnQgZmF1 bHQKPj4gPiBoYXBwZW5zLgo+PiA+Cj4+ID4gQm90aCBnbGliYyBhbmQgZnJlZWJzZCBjYW4gZG8g c2ltcGxlIGRldGVjdGlvbiBvZiB0aHJlYWQgSUQocHRocmVhZF90KQo+PiA+IHBhc3NlZCBieSB1 c2VyIGFuZCByZXR1cm4gRVNSQ0ggd2hlbiBubyB0aHJlYWQgY2FuIGJlIGZvdW5kLiBUaGV5Cj4+ Cj4+IHRoYXQncyBhIGhpc3RvcmljYWwgYnVnIGluIHBvc2l4OiBpdCByZXF1aXJlZCBFU1JDSAo+ PiB3aGljaCBpcyBub3QgcG9zc2libGUgd2hlbiB0aGUgdGhyZWFkIGlkIGlzIHJldXNlZCwKPj4g c28gYWxsIHN1Y2ggcmVxdWlybWVudHMgd2VyZSByZW1vdmVkIGluIHBvc2l4IDIwMDgKPj4gaHR0 cHM6Ly9jb2xsYWJvcmF0aW9uLm9wZW5ncm91cC5vcmcvYXVzdGluL2ludGVycHMvZG9jdW1lbnRz LzE0MzY2L0FJLTE0Mi50eHQKPj4KPj4gcGFzc2luZyBpbnZhbGlkIGlkIGlzIHNpbXBseSB1bmRl ZmluZWQgbm93LCBhbgo+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgXl5eXgo+Cj5JdCB3YXMgYWx3 YXlzIHVuZGVmaW5lZDsgdGhlIHRleHQgc3RhdGluZyB0aGF0IGl0J3MgdW5kZWZpbmVkIHdhcwo+ cHJlc2VudCBpbiBvbGQgUE9TSVggdG9vLiBUaGUgInNoYWxsIGZhaWwiIHRleHQgaW4gdGhlIEVT UkNIIGVycm9ycwo+d2FzIGlmICJ0aGUgaW1wbGVtZW50YXRpb24gaGFzIGRldGVjdGVkLi4uIiBv ciBzaW1pbGFyLCB3aGljaCBvZGRseQo+aW1wb3NlZCBhIHJlcXVpcmVtZW50IHRvIHJlcG9ydCBz b21ldGhpbmcgaWYgaXQgd2FzIGRldGVjdGVkLCBidXQKPmRpZG4ndCAoYW5kIGZ1bmRhbWVudGFs bHkgY291bGRuJ3QsIHNpbmNlIGl0J3MgdW5kZXRlY3RhYmxlIHdpdGgKPmlkZW50aWZpZXIgcmV1 c2FnZSkgaW1wb3NlIGEgcmVxdWlyZW1lbnQgdG8gZGV0ZWN0Lgo+Cj5UaGUgY29tbWl0dGVlIHJl Y29nbml6ZWQgdGhhdCB0aGlzIG1hZGUgbm8gc2Vuc2UgYW5kIGZpeGVkIGl0IGJ5Cj5yZW1vdmlu ZyB0aGUgInNoYWxsIGZhaWwiIHRleHQuIFRoaXMgd2FzIG5vdCBhIGZ1bmN0aW9uYWwgY2hhbmdl LCBvbmx5Cj5hIGNsYXJpZmljYXRpb24sIGFuZCB0aHVzIGRpZG4ndCByZXF1aXJlIGEgbmV3IHZl cnNpb24gb2YgdGhlCj5zdGFuZGFyZCwganVzdCBhIFRDLgo+Cj5SaWNoCj4= From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14225 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [proposal] Add detection of thread ID in pthread-related interfaces Date: Tue, 11 Jun 2019 12:09:31 -0400 Message-ID: <20190611160931.GD1506@brightrain.aerifal.cx> References: <4CF320752F2B99449115298D4A06B22F34E3DD31@dggemm509-mbx.china.huawei.com> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="88029"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "musl@lists.openwall.com" , helitao , "Huangqiang (H)" , Jinyongming , leijitang , "liuyutao (C)" , "Liyu (Marvin, Euler Dept)" , "Threefifteen Wang(Kunfeng)" , "Wudilong (Michael)" To: pengyuanhong Original-X-From: musl-return-14241-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jun 11 18:12:02 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1hajNS-000Mnl-4L for gllmg-musl@m.gmane.org; Tue, 11 Jun 2019 18:12:02 +0200 Original-Received: (qmail 8140 invoked by uid 550); 11 Jun 2019 16:11:59 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 8111 invoked from network); 11 Jun 2019 16:11:59 -0000 Content-Disposition: inline In-Reply-To: <4CF320752F2B99449115298D4A06B22F34E3DD31@dggemm509-mbx.china.huawei.com> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:14225 Archived-At: On Tue, Jun 11, 2019 at 11:36:59AM +0000, pengyuanhong wrote: > Hello, > > I find that all pthread-related interfaces directly access the input > parameter `pthread_t` without any check. If I pass an invalid thread ID > (e.g. an exited thread ID) to these interfaces, then segment fault > happens. > > Both glibc and freebsd can do simple detection of thread ID(pthread_t) > passed by user and return ESRCH when no thread can be found. They > put all threads in a list or hash table, and update this list or table every > time a thread is created or exits. This description of why glibc returns ESRCH is incorrect; it has nothing to do with keeping a list, which would require >O(1) lookup and global synchronization on each operation referring to a thread id. Rather, they just don't free exited threads, but keep the memory cached to reuse for future calls to pthread_create with a marker that it's not currently live. This allows trivial detection and reporting that the id is not currently valid, but also encourages rapid reuse of the same ids that were just freed, making use-after-free bugs with pthread_t's much more dangerous. Rich From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14226 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: [proposal] Add detection of thread ID in pthread-related interfaces Date: Tue, 11 Jun 2019 12:15:44 -0400 Message-ID: <20190611161544.GE1506@brightrain.aerifal.cx> References: <4CF320752F2B99449115298D4A06B22F34E3DD31@dggemm509-mbx.china.huawei.com> <20190611135741.GY16415@port70.net> <20190611143624.GA1506@brightrain.aerifal.cx> <2019061123563340760322@huawei.com> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="114808"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "musl@lists.openwall.com" , helitao , "Huangqiang (H)" , Jinyongming , leijitang , "liuyutao (C)" , "Threefifteen Wang(Kunfeng)" , "Wudilong (Michael)" To: Li Yu Original-X-From: musl-return-14242-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jun 11 18:18:14 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1hajTR-000Tjg-FX for gllmg-musl@m.gmane.org; Tue, 11 Jun 2019 18:18:13 +0200 Original-Received: (qmail 17504 invoked by uid 550); 11 Jun 2019 16:18:11 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 17486 invoked from network); 11 Jun 2019 16:18:11 -0000 Content-Disposition: inline In-Reply-To: <2019061123563340760322@huawei.com> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:14226 Archived-At: 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