[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 9 Jan 2018 16:24:06 -0600
From: William Pitcock <nenolod@...eferenced.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] track pthread stack guard sizes
Hi,
On Tue, Jan 9, 2018 at 11:22 AM, Rich Felker <dalias@...c.org> wrote:
> On Sat, Jan 06, 2018 at 04:44:43AM +0000, William Pitcock wrote:
>> some applications (rustc) are dependent on pthread_getattr_np() providing the guard size.
>> ---
>> src/internal/pthread_impl.h | 1 +
>> src/thread/pthread_create.c | 1 +
>> src/thread/pthread_getattr_np.c | 1 +
>> 3 files changed, 3 insertions(+)
>>
>> diff --git a/src/internal/pthread_impl.h b/src/internal/pthread_impl.h
>> index 56e19348..c2cafeaa 100644
>> --- a/src/internal/pthread_impl.h
>> +++ b/src/internal/pthread_impl.h
>> @@ -48,6 +48,7 @@ struct pthread {
>> void *stdio_locks;
>> uintptr_t canary_at_end;
>> void **dtv_copy;
>> + size_t guard_size;
>> };
>>
>> struct __timer {
>> diff --git a/src/thread/pthread_create.c b/src/thread/pthread_create.c
>> index 6cbf85b3..0faad765 100644
>> --- a/src/thread/pthread_create.c
>> +++ b/src/thread/pthread_create.c
>> @@ -265,6 +265,7 @@ int __pthread_create(pthread_t *restrict res, const pthread_attr_t *restrict att
>> new->map_size = size;
>> new->stack = stack;
>> new->stack_size = stack - stack_limit;
>> + new->guard_size = guard;
>> new->start = entry;
>> new->start_arg = arg;
>> new->self = new;
>> diff --git a/src/thread/pthread_getattr_np.c b/src/thread/pthread_getattr_np.c
>> index ae26a5ab..29a209bd 100644
>> --- a/src/thread/pthread_getattr_np.c
>> +++ b/src/thread/pthread_getattr_np.c
>> @@ -7,6 +7,7 @@ int pthread_getattr_np(pthread_t t, pthread_attr_t *a)
>> {
>> *a = (pthread_attr_t){0};
>> a->_a_detach = !!t->detached;
>> + a->_a_guardsize = t->guard_size;
>> if (t->stack) {
>> a->_a_stackaddr = (uintptr_t)t->stack;
>> a->_a_stacksize = t->stack_size;
>> --
>> 2.15.0
>
> I'm pretty sure there's another bug in this patch: the local variable
> guard is uninitialized where you use it if the application provided a
> stack and TLS was able to be allocated in the app-provided stack.
>
> The line guard = 0; above should probably just be moved down one line
> (and unindented one level).
>
> Does this sound right?
Yes, I would agree that guardsize should be 0 if the app provided a
sufficient stack.
The rustc error had to do with a libc-provided stack, so was trying to
fix it quickly for that case mostly.
William
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.
