[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <dc9ff861-1893-10fe-07d9-333310fc56bc@gmail.com>
Date: Fri, 20 Jan 2017 11:45:09 -0800
From: Eric Hassold <hassold@...il.com>
To: "musl@...ts.openwall.com" <musl@...ts.openwall.com>
Subject: Fix pthread_create on some devices failing to initialize guard area
Hi All,
While deploying test static executable across farm of different embedded systems, found out that pthread_create() is failing systematically on some (very few) arm-linux devices whenever non null stack guard is enabled (that is, also when calling pthread_create with default - i.e. null - attributes since default is a one page of guard). One of those device is for example a Marvell Armada 375 running Linux 3.10.39. Same test code, built with alternative libc implementations (glibc, uClibc) works as expected on those devices.
Issue
This occurs because of call to mprotect() in pthread_create fails. In current implementation, if guard size is non null, memory for (guard + stack + ...) is first allocated (mmap'ed) with no accessibility (PROT_NONE), then mprotect() is called to re-enable read/write access to (memory + guardsize). Since call to mprotect() systematically fails in this scenario (returning error code EINVAL), it is impossible to create thread.
Patch
In proposed patch (attached below), memory for (guard + stack + ...) is first mmap'ed with read/write accessibility, then guard area is protected by calling mprotect() with PROT_NONE on guardsize first bytes of returned memory. This call to mprotect() to remove all accessibility on guard area, with guard area being at beginning of previously mmap'ed memory, works correctly on those platforms having issue with current implementation. Incidentally, this makes the logic more concise to handle both cases (with or without guard) is a more consistent way, and handle systems with partial/invalid page protection implementation (e.g. mprotect() returning ENOSYS) more gracefully since the stack is explicitly created with read/write access.
-Eric.
---
Subject: [PATCH] set up guard protection after stack is mapped
calling mprotect beyond the guard page of PROT_NONE mmap-ed stack fails on
some devices, making it impossible to create thread. instead, allocate memory
for stack and guard first, with read and write permission, then protect guard
area.
---
src/thread/pthread_create.c | 11 ++++-------
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/src/thread/pthread_create.c b/src/thread/pthread_create.c
index 49f2f72..f846bec 100644
--- a/src/thread/pthread_create.c
+++ b/src/thread/pthread_create.c
@@ -232,21 +232,18 @@ int __pthread_create(pthread_t *restrict res, const pthread_attr_t *restrict att
} else {
guard = ROUND(attr._a_guardsize);
size = guard + ROUND(attr._a_stacksize
- + libc.tls_size + __pthread_tsd_size);
+ + libc.tls_size + __pthread_tsd_size);
}
if (!tsd) {
+ map = __mmap(0, size, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANON, -1, 0);
+ if (map == MAP_FAILED) goto fail;
if (guard) {
- map = __mmap(0, size, PROT_NONE, MAP_PRIVATE|MAP_ANON, -1, 0);
- if (map == MAP_FAILED) goto fail;
- if (__mprotect(map+guard, size-guard, PROT_READ|PROT_WRITE)
+ if (__mprotect(map, guard, PROT_NONE)
&& errno != ENOSYS) {
__munmap(map, size);
goto fail;
}
- } else {
- map = __mmap(0, size, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANON, -1, 0);
- if (map == MAP_FAILED) goto fail;
}
tsd = map + size - __pthread_tsd_size;
if (!stack) {
--
2.7.4
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.
