[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140627233505.GA32514@n2100.arm.linux.org.uk>
Date: Sat, 28 Jun 2014 00:35:05 +0100
From: Russell King - ARM Linux <linux@....linux.org.uk>
To: Andy Lutomirski <luto@...capital.net>
Cc: Rich Felker <dalias@...c.org>, musl@...ts.openwall.com,
Szabolcs Nagy <nsz@...t70.net>, Kees Cook <keescook@...omium.org>,
"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>
Subject: Re: Re: Thread pointer changes
On Fri, Jun 27, 2014 at 04:17:52PM -0700, Andy Lutomirski wrote:
> On Fri, Jun 27, 2014 at 4:07 PM, Russell King - ARM Linux
> <linux@....linux.org.uk> wrote:
> > The kuser helpers can NOT be removed unless the CPU is v6k+. Let me
> > put that a different way: the kuser helpers can not be removed unless
> > the ELF HWCAPs indicate TLS support.
>
> Why? (This is an honest question -- there may be an excellent
> answer.) I understand why they're needed in the first place, but I
> don't understand why they need to live at a fixed address.
Just very briefly - and this will be my last reply on this until Monday,
especially so as I've spent a solid 1h30 replying to the emails in this
thread, and it's past midnight here.
I referred to the problems in an earlier reply (maybe in a different
sub-thread of this thread.)
To answer your "why" (which I'll take as "why can't they be removed")
the reason for that is the lack of TLS support. If the kuser page
is removed _and_ there is no hardware TLS support, then there is no way
for userspace to have TLS.
As for your second bit (about why they need to live at a fixed address)
we could have randomised it on v6 and later CPUs, but there are some
v6 CPUs which suffer from data cache aliasing, just like all the previous
CPUs. With the data cache aliasing, it would make the TLS implementation
a lot more complex.
As part of the TLS implementation for older CPUs, the TLS value is stored
right at the top of that page, and on every context switch, we have to
update that value. If the page was at a randomised address, the kernel
would either have to poke directly into userspace and flush it from the
caches (which is error prone - what if userspace unmaps the page) or it
has to do cache flushing to ensure that the value is visible via the
user alias of the page.
If it wasn't for this need, we would have probably gone for a VDSO from
the start.
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
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.
