mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Cc: Kees Cook <keescook@chromium.org>, linux-arm-kernel@lists.infradead.org
Subject: Re: Re: Thread pointer changes
Date: Fri, 27 Jun 2014 18:26:26 -0400	[thread overview]
Message-ID: <20140627222626.GA17988@brightrain.aerifal.cx> (raw)
In-Reply-To: <20140627220400.GT32514@n2100.arm.linux.org.uk>

On Fri, Jun 27, 2014 at 11:04:00PM +0100, Russell King - ARM Linux wrote:
> On Fri, Jun 27, 2014 at 05:37:43PM -0400, Rich Felker wrote:
> > On Fri, Jun 27, 2014 at 12:27:45PM -0700, Andy Lutomirski wrote:
> > > Hi ARM people and Kees-
> > > 
> > > The "vectors" page appears to be an abomination that's a lot like the
> > > x86_64 vsyscall page.  IMO it should be phased out.
> > 
> > I'm not a fan of this extreme approach, but if it's taken, there needs
> > to be some way to continue to make universal binaries which work
> > safely on:
> > 
> > - Pre-v6, v6, and v7+ hardware.
> 
> And that is to make use of the kuser page.
> 
> > - Pre-removal and post-removal kernels.
> 
> Please, don't get stuff confused.
> 
> The kuser page isn't going anywhere _except_ for one situation: where
> the system integrator has determined that they have built their
> userspace not to require the kuser helpers, and wish to have greater
> security and performance through doing so.
> 
> What we *aren't* doing with the kernel is removing the page entirely
> for ARMv7+ CPUs.  We are merely giving system integrators the option
> to increase security /provided/ their userspace is built appropriately.
> 
> If the userspace requires the kuser helpers, then the page *must* be
> provided by the kernel.
> 
> It is a system integrator/distro bug to provide a kernel with the kuser
> helpers disabled, but then to provide a libc which requires the page.

From our standpoint it is not necessarily the system integrator/distro
who provides the libc, but rather the distributor of the (possibly
static-linked, or possibly dynamic-linked but with its own full set of
libs) application binary. As a provider of tools used to produce such
binaries, we want these binaries to work regardless of how the kernel
was configured.

Thus, my interest is in ensuring that, whenever the kuser helper page
is disabled (or, as proposed, moved to a dynamic address), there's a
safe and efficient way to detect this condition and know what to do to
work around it.

Rich


  reply	other threads:[~2014-06-27 22:26 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-10  7:28 Rich Felker
2014-06-11 14:55 ` Rich Felker
2014-06-27 19:27   ` Andy Lutomirski
2014-06-27 20:09     ` Russell King - ARM Linux
2014-06-27 21:09       ` Szabolcs Nagy
2014-06-27 21:30         ` Russell King - ARM Linux
2014-06-27 21:47           ` Andy Lutomirski
2014-06-27 21:58             ` Rich Felker
2014-06-27 21:55           ` Rich Felker
2014-06-27 22:17             ` Russell King - ARM Linux
2014-06-27 22:25               ` Andy Lutomirski
2014-06-27 22:54                 ` Russell King - ARM Linux
2014-06-28  0:11                   ` Rich Felker
2014-06-27 22:33               ` Rich Felker
2014-06-27 23:07                 ` Russell King - ARM Linux
2014-06-27 23:17                   ` Andy Lutomirski
2014-06-27 23:35                     ` Russell King - ARM Linux
2014-06-27 23:40                       ` Andy Lutomirski
2014-06-30 15:38                         ` [musl] " Christopher Covington
2014-07-02 21:16                           ` Rich Felker
2014-06-28  0:20                       ` Rich Felker
2014-06-27 22:40               ` Szabolcs Nagy
2014-06-27 22:51                 ` Andy Lutomirski
2014-06-27 23:12                 ` Russell King - ARM Linux
2014-06-28 16:37                   ` Szabolcs Nagy
2014-06-27 21:37     ` Rich Felker
2014-06-27 22:04       ` Russell King - ARM Linux
2014-06-27 22:26         ` Rich Felker [this message]
2014-06-27 23:03           ` Russell King - ARM Linux
2014-06-28  7:09         ` u-igbb
2014-06-27 23:20     ` Russell King - ARM Linux
2014-06-28  0:38       ` Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140627222626.GA17988@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=keescook@chromium.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).