[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140611145533.GT179@brightrain.aerifal.cx>
Date: Wed, 11 Jun 2014 10:55:33 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Thread pointer changes
On Tue, Jun 10, 2014 at 03:28:35AM -0400, Rich Felker wrote:
> For ARM, I think we should revisit the thread-pointer/atomic inlining
> work that was done as a sloppy workaround for kernels without the
> kuser_helper page. If the set_thread_area syscall fails (due to an old
> kernel that doesn't support it), we can setup a function pointer for
> the __aeabi_read_tp function that only supports a single main thread
> and returns its thread pointer. Likewise at this stage we could detect
> the presence or absence of the kuser_helper page and substitute our
> own fallbacks (using the instructions directly) if needed. One thing
> that should be checked though is whether there are any kernel versions
> which support EABI syscalls but not the thread-pointer setup syscall.
> If not, there's really no use in having a fallback for that. These
> slides look like they might shed some light on the history:
> http://wookware.org/talks/armeabidebconf.pdf
According to those slides, the EABI-form syscall convention (which
musl requires) was not added to Linux until 2.6.15. The kuser helpers
(just thread pointer and atomic cas) were originally added in 2.6.12.
Since we already have a bigger reason not to support pre-2.6.15
kernels on ARM, there's no need to worry about whether TLS is
supported by the kernel; we can just assume __set_thread_area will
always work.
As for whether the kuser helper page exists, there are three cases:
1. Normal kuser page - everything available and works.
2. Mainline kernel CONFIG_KUSER_HELPERS disabled - the page is present
but filled with a HCF instruction. This is easy to detect.
3. Hardened grsec kernels - the page is completely missing, so
attempts to access it fault. And worse yet, most syscalls report
EFAULT even if it's present because it's above the task size
address limit (in the kernel address range). So far the only way
I've found to detect it is process_vm_readv which was not added
until 3.2; I'm not sure if there are relevant pre-3.2 grsec kernels
with kuser helpers disabled.
Rich
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.
