[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140628002048.GB19165@brightrain.aerifal.cx>
Date: Fri, 27 Jun 2014 20:20:48 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Cc: Andy Lutomirski <luto@...capital.net>, 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 Sat, Jun 28, 2014 at 12:35:05AM +0100, Russell King - ARM Linux wrote:
> 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.
Understood. Don't feel like you have to reply to the further emails in
this thread; we can wait until you have time.
> 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.
Thank you for taking the time to give the technical explanation of why
it is the way it is. That makes a lot more sense, and indeed it makes
the option of having a randomized address seem a lot less attractive.
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.
