This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]