Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1360585447.9132.70.camel@eris.loria.fr>
Date: Mon, 11 Feb 2013 13:24:07 +0100
From: Jens Gustedt <jens.gustedt@...ia.fr>
To: musl@...ts.openwall.com
Subject: Re: [PATCH v3] move the definition of __pthread_tsd_main to
 the only compilation unit that references it

Am Montag, den 11.02.2013, 12:14 +0100 schrieb Szabolcs Nagy:
> * Jens Gustedt <Jens.Gustedt@...ia.fr> [2013-02-11 11:44:21 +0100]:
> >  - Avoids a const cast that doesn't seem to be very useful.
> >  - Remove unused __pthread_tsd_size
> > 
> 
> sorry i was wrong, __pthread_tsd_size is used in pthread_create
> (i haven't read all the mails yet)

oops, somehow I must have got my grep for it wrong then, sorry for the
noise.


> the logic is that it is 0 when pthread_key_create is not
> linked to your code so you avoid all the tsd stack overhead
> (which is reasonable: in small tools where size and memory
> usage matters most you don't often use thread specific data..
> especially now that c11 has tls)
> 
> same for pthread_self: you only want non-dummy tsd if
> pthread_key_create is used
> 
> with your change you break pthread_create (now __pthread_tsd_size
> is always 0 there) and pthread_create always pulls in the tsd buf

Ok, now I see the idea.

In case of dynamic linking, this sounds a bit dangerous to me. Suppose
I have a program that runs fine, without linking to the key stuff. Say
it launches a new thread which then has the key table invalid.

Then I dynamically load a module that uses keys. The thread that has
an invalid table jumps into a function of that module that calles
pthread_key_get() ?

In such a scenario everything would simply crash, wouldn't it?

Jens

-- 
:: INRIA Nancy Grand Est :: http://www.loria.fr/~gustedt/   ::
:: AlGorille ::::::::::::::: office Nancy : +33 383593090   ::
:: ICube :::::::::::::: office Strasbourg : +33 368854536   ::
:: ::::::::::::::::::::::::::: gsm France : +33 651400183   ::
:: :::::::::::::::::::: gsm international : +49 15737185122 ::




Download attachment "signature.asc" of type "application/pgp-signature" (199 bytes)

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.