This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: glibc 2.25 seems to have broken AddressSaniitzer Inbox x glibc x sanitizer x
On 02/22/2018 12:43 AM, Florian Weimer wrote:
> On 02/21/2018 10:57 PM, Adhemerval Zanella wrote:
>> My view off the ABI your proposed is for stack boundaries and
>> static TLS part it seems reasonable: both query functions initial
>> descriptions are straightforward and internal implementation should
>> require only reading some internal states.
>
> glibc does not know the stack boundaries, though. We do not require
> that applications use the glibc-allocated stack . (We do, however,
> require that applications use the glibc-allocated thread control
> block.)
We know it in many cases.
If you do not use the obsolete pthread_attr_setstackaddr(), and instead
use pthread_attr_setstack(), we know the start and end of the stack.
Likewise if you do use the obsolete API but also call
pthread_attr_setstacksize(), then we know both parameters (and we
validate the stack size in that case).
It could also be that there are additional pages beyond this that we
know nothing about, and which could be legitimately used by the
application.
We also know nothing about the size and location of the guard pages.
For the record Rust has all the same problems, namely that threads
with user-controlled stacks are not handled well by the runtime because
it cannot compute their boundaries.
--
Cheers,
Carlos.