Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 6 Mar 2020 10:13:52 -0800
From: enh <>
To: Szabolcs Nagy <>
Cc:, Florian Weimer <>,
Subject: Re:

interestingly, i was made aware of some prior art...


lsan usage:

On Fri, Mar 6, 2020 at 6:09 AM Szabolcs Nagy <> wrote:
> On 06/03/2020 09:05, Florian Weimer wrote:
> > * enh:
> >
> >> is anyone else looking at implementing
> >> ? we're starting
> >> to look at this for Android now, and i was wondering whether anyone
> >> had any implementation experience.
> >
> > I've been discussing TLS-related issues with quite a few people
> > recently.  Lack of transparency when it comes to TLS layout is one
> > aspect.
> >
> > I must say I do not particularly like the proposed callbacks (which
> > are not implemented in glibc).  Conceptually, an audit module
> > (LD_AUDIT or DT_AUDIT) would be a better fit.  With an audit module,
> > it's probably easier to avoid some of the strange loops inherent to
> > such low-level callbacks, although what code can do from them will
> > always be severely limited.
> >
> > The callbacks do not look expressive enough for tools like valgrind
> > that might benefit from knowing the boundaries between TLS variables.
> yes, to me it was unclear why is it a 'dynamic tls allocation'
> callback and not just an 'as-safe allocation' callback.
> the libc may not need as-safe allocation for dynamic tls and
> dynamic tls may be allocated together with lot of other stuff
> (e.g. stack and tls for currently loaded dsos can be allocated
> together at thread creation time, or dso related bookkeeping
> and tls for current threads can be allocated together at dlopen
> time)
> if there is a semantic distinction between normal allocations
> and dynamic tls then it likely needs more info (e.g. tls for
> specific thread+dso or boundaries per tls variable).
> >
> > The callbacks could also over-constrain the implementation.  It's hard
> > to predict the future, but one aspect is that the static TLS
> > boundaries are not actually fixed by the ABI.  You cannot move the TLS
> > data, but you can grow the area in one direction.

this is one reason why i'm not even sure it makes much sense to try to
have _an_ API.

> > I forgot that the “Callback for thread exit” aspect of the proposal,
> > otherwise I would referenced it in my TLS initarray message.  I would
> > expect this to be quite widely used, by different libraries.  With the
> > proposal, people would have to remember to chain callbacks using
> > RTLD_NEXT, which is neither clean nor efficient.
> i think running callbacks while signals are blocked
> and the thread is no longer in a state where user
> code should run is a bit tricky to specify.
> but i see that it can be useful.

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.