[Bug libc/16291] feature request: provide simpler ways to compute stack and tls boundaries

["carlos at redhat dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=16291

Carlos O'Donell <carlos at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |carlos at redhat dot com

--- Comment #13 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Kostya Serebryany from comment #0)
> This is both a feature request and a request for a suggestion. 
> We are developing dynamic testing tools like AddressSanitizer and
> ThreadSanitizer
> which are now part of both LLVM and GCC distributions. 
> The tools have a run-time library that needs to compute thread's stack and 
> tls boundaries. Right now it is done with a series of ugly hacks.

This is something I think we can help with by providing implementation
symbols internally that ASAN and other tools can rely upon as part of
an agreement we have with those tools.

> For non-main threads we get the stack boundaries by querying
> pthread_getattr_np and pthread_attr_getstack. This works, 
> but is problematic because pthread_getattr_np calls malloc and we intercept
> malloc. 

OK.

> For the main thread we get the stack boundaries by querying 
> getrlimit, /proc/self/maps, and an address of a local variable because at
> the point when we need the info libpthread might not have initialized
> itself. 

OK.

> Getting TLS boundaries is even more involved. 
> Today we use the glibc's private symbol _dl_get_tls_static_info
> and then subtract a magic constant (size of the glibc's thread descriptor).

That's ugly, and we could do better there.

However, you're only talking about static TLS there.

There is dynamic TLS also that is not within the static tls block.

Do you need information about that? Such information is racy, prone to
change as libraries are loaded and unloaded etc.

> This works for us on a system we are testing (Ubuntu 12.04),
> but this is very fragile and is often broken on older Linux distros. 

Understood.

> Is it possible to compute the stack and tls boundaries more reliably today?

It is possible to compute at least one end of the main thread stack.

It is possible to compute the boundaries of the non-main thread stack easily.

It is also possible to know the boundaries of static tls for all threads.

It is harder to know the boundaries of dynamic tls for all threads, but
potentially possible. The information once you have it though could
immediately become stale (given the dynamic nature).

Perhaps we can start by addressing the first three in a reliable way.

> If not, would it be possible to add some new functions to do that?

Could you suggest an API?

> For every thread (including the main one) we need to know its stack and tls
> boundaries and the functions that compute it for us should not call malloc
> or any other public library functions. For the main thread, these functions
> should
> work reliably very early (in pre_init functions)

Understood.

As I said, if you designed an API for this, we could look at it and say
if it's possible to fill it in from our end?

You also need to think about what security implications there are about
such an API, if any.

Stability of the API, etc.

-- 
You are receiving this mail because:
You are on the CC list for the bug.