Subject: Re: disabling PTHREAD_CONCURRENCY for 3.0
To: Chuck Silvers <email@example.com>
From: Garrett D'Amore <firstname.lastname@example.org>
Date: 12/13/2005 08:27:18
Chuck Silvers wrote:
>On Mon, Dec 12, 2005 at 08:18:49PM +0100, Manuel Bouyer wrote:
>>On Mon, Dec 12, 2005 at 09:09:24AM -0800, Chuck Silvers wrote:
>>>>If PTHREAD_CONCURRENCY > 1 can cause kernel panics, just removing it from
>>>>libpthread isn't enouth. The kernel has to be patched as well, otherwise a
>>>>local user could start an application linked with a bad libpthread and
>>>>cause a local DOS.
>>>I was more worried about us advertising a feature that crashes the system
>>>than a malicious user. but disabling the sa_setconcurrency() syscall
>>>as well is easy enough, I'll add that to the patch.
>>Maybe not disable it (possible backward compat issues ?) but return error
>>if the value is not 1.
>this setup is in pthread_init(), which returns void.
>this is called before main() as the constructor for the pthread library.
>"return an error" in this case would mean "cause the process to exit".
I think its easy enough to just ignore the environment variable that
Solaris pthreads have a function call to set the concurrency; if we had
that then it would make sense to return an error. But in our case just
silently ignoring the env. var (possibly logging a message?) would be
best, I think.
>what compatibility issue are you concerned about?
Can't imagine what it would be -- this isn't part of an official API
that I'm aware of.
Garrett D'Amore http://www.tadpolecomputer.com/
Sr. Staff Engineer Extending the Power of 64-bit UNIX Computing
Tadpole Computer, Inc. Phone: (951) 325-2134