[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrVFvYNPHMozB2E2L0LWSPv=o6JHfmoz4_pBC2gQwRLpug@mail.gmail.com>
Date: Fri, 27 Jun 2014 16:17:52 -0700
From: Andy Lutomirski <luto@...capital.net>
To: Russell King - ARM Linux <linux@....linux.org.uk>
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 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.
The closest thing to this that I'm familiar with is x86_32's sysenter.
It's a very useful instruction, but it's basically impossible for libc
to contain a sysenter instruction in the libc image. So the kernel
provides one *at a randomized address*, and libc calls it.
Admittedly, x86_32 has an advantage over ARM here: libc without a
sysenter helper is completely functional; it's just slower.
Nonetheless, ISTM it should be possible to start advertising the kuser
helper address to libc, get all the libcs to play along, and then
offer an option of randomizing it for people who know that they don't
have any old libcs on their systems.
--Andy
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.
