[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140627230736.GX32514@n2100.arm.linux.org.uk>
Date: Sat, 28 Jun 2014 00:07:36 +0100
From: Russell King - ARM Linux <linux@....linux.org.uk>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com, Szabolcs Nagy <nsz@...t70.net>,
Kees Cook <keescook@...omium.org>,
linux-arm-kernel@...ts.infradead.org,
Andy Lutomirski <luto@...capital.net>
Subject: Re: Re: Thread pointer changes
On Fri, Jun 27, 2014 at 06:33:28PM -0400, Rich Felker wrote:
> On Fri, Jun 27, 2014 at 11:17:44PM +0100, Russell King - ARM Linux wrote:
> > As I've already said, that's a system integrator bug to have a kernel
> > without a kuser page with userspace which requires it.
> >
> > I think you're are missing one obvious solution to this which you can do:
> > you are passed the HWCAP fields in the ELF auxinfo. This will tell you
> > if the CPU has TLS support or not. If it has TLS support, then you don't
> > need to use the kuser helpers, and you know that it is a CPU which is ARM
> > architecture v6k or later,
>
> Are you sure? I think the minimum models for TLS and for LDREX/STREX
> are different; one is plain v6 and the other is v6k.
LDREX/STREX is v6+. TLS is v6k+.
> This greatly
> complicates the issue since the kernel only tells you if the TLS
> register is available, not if the atomics are.
uname() ?
> > If you want to know that the CPU supports the DMB
> > instruction rather than the CP15 barrier instruction, then you have to
> > check the uname details, or read /proc/cpuinfo (but I'd rather you
> > didn't.)
>
> These are not safe operations. /proc may not be mounted, or the file
> descriptor table may be full and open may fail, etc.
Balderdash. Since when has uname not been safe?
> > In addition, the HWCAP fields tell you about some of the other
> > instructions and FP options which are available to you, whether there's
> > integer division available, etc.
>
> Yes but for all of those it's safe to assume the lowest baseline. For
> TLS and atomics, removal (even optional) of kuser helper page means
> it's not safe to assume the lowest baseline; there MUST be a fallback
> to use the higher-model-only instructions if the kernel lacks kuser
> helper.
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.
If the ELF HWCAPs indicate TLS support, then you have atomics and you
have TLS registers, and you may or may not have the kuser helpers.
If it indicates no TLS support, then you will always have kuser helpers.
--
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.
