mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Russell King <linux@arm.linux.org.uk>,
	"musl@lists.openwall.com" <musl@lists.openwall.com>,
	Szabolcs Nagy <nsz@port70.net>, Kees Cook <keescook@chromium.org>,
	Rich Felker <dalias@libc.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: ARM atomics overhaul for musl
Date: Tue, 18 Nov 2014 10:56:12 +0000	[thread overview]
Message-ID: <20141118105611.GC28279@e104818-lin.cambridge.arm.com> (raw)
In-Reply-To: <CALCETrUAtAJ1CmuxOFiiu53kAWwofUpFaBeFAZF7Th2VXPbHZg@mail.gmail.com>

On Mon, Nov 17, 2014 at 05:38:46PM +0000, Andy Lutomirski wrote:
> On Nov 17, 2014 6:39 AM, "Russell King - ARM Linux"
> <linux@arm.linux.org.uk> wrote:
> >
> > On Mon, Nov 17, 2014 at 01:54:13PM +0000, Catalin Marinas wrote:
> > > If you haven't noticed, the distinction between ARMv6 and ARMv7 has been
> > > blurred enough (guess why cpu_architecture() reports ARMv7 for
> > > ARM11MPCore). ARM is trying to move away from architecture version
> > > numbers, which are rather useful for marketing, to proper feature
> > > detection based on CPUID. Whether there is an ARMv9 or not, it's
> > > irrelevant to what Linux should do (i.e. use CPUID rather than guess
> > > features based on architecture version numbers).
> >
> > That may be what is desired, but unfortunately we have no way to export
> > all the intricate feature registers to userspace.  No, elf hwcaps don't
> > support it, there's only 64 bits split between two words there, and
> > there are many more than just 64 bits of feature registers.
> 
> That's a ridiculous argument.  Linux can freely add bits.
> 
> You could add AT_ARM_FEATURES that points to a length followed by the
> indicated number of words, or you could just keep adding new HWCAP
> fields as needed.  This is expandable forever.

That's fine by me, I don't have a problem with more hwcap bits.

> > Given that even cocked these up (just as what happened with the cache
> > type register) decoding of the feature type registers depends on the
> > underlying CPU architecture.
> >
> > So, even _if_ we exported the feature registers to userspace, you still
> > need to know the CPU architecture to decode them properly, so you still
> > need to parse the AT_PLATFORM string to get that information.
> 
> There's no need to expose the hardware feature registers as is.
> Define your own sensible feature bits just for Linux.

We get regular questions about direct access to the hardware feature
bits, many using the x86 cpuid instruction as argument. So far we
couldn't see good enough reasons, otherwise we would have pushed such
instruction in the ARMv8 architecture. It's also not a simple direct
hardware access since the kernel may want to mask some features it does
not support, which pretty much requires HWCAP or some banked CPUID
registers in hardware.

There seems to be a category of software that can't access HWCAP or
/proc/self/auxv. This is Android software, I'm not sure how the
developers came to this conclusion but they think allowing
/proc/cpuinfo access is ok but not /proc/self/auxv. I'm not sure direct
cpuid access is a good enough argument for such scenario. To me it looks
like something they should solve in their security implementation.

Another class are dynamic loaders that don't yet have a C library
loaded. However, as such loaders are the first entry point, I don't see
why they couldn't access auxv directly. One particular scenario here is
finding out which CPU micro-architecture (implementation) it is so that
the dynamic loader could choose a more optimised library. CPUID would
help partially here (get the actual MIDR identifying the CPU
implementation rather than just features) but not on heterogeneous
systems like big.LITTLE. Which means that we would still be better off
with some extra features in auxv, maybe even listing the individual MIDR
for all the CPUs in the system.

-- 
Catalin


  reply	other threads:[~2014-11-18 10:56 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-16  5:56 Rich Felker
2014-11-16 16:33 ` Russell King - ARM Linux
2014-11-16 16:50   ` Rich Felker
2014-11-16 17:10     ` Russell King - ARM Linux
2014-11-16 18:27       ` Andy Lutomirski
2014-11-16 18:56         ` Rich Felker
2014-11-16 19:02       ` Rich Felker
2014-11-17 13:54       ` Catalin Marinas
2014-11-17 14:11         ` Szabolcs Nagy
2014-11-17 14:47           ` Catalin Marinas
2014-11-17 14:39         ` Russell King - ARM Linux
2014-11-17 15:26           ` Catalin Marinas
2014-11-17 15:47             ` Russell King - ARM Linux
2014-11-17 16:19               ` Catalin Marinas
2014-11-17 16:53                 ` Russell King - ARM Linux
2014-11-17 17:48                   ` Catalin Marinas
2014-11-17 17:38           ` Andy Lutomirski
2014-11-18 10:56             ` Catalin Marinas [this message]
2014-11-18 18:14               ` Will Deacon
2014-11-18 18:24                 ` Andy Lutomirski
2014-11-18 19:19                 ` Russell King - ARM Linux
2014-11-19 18:32                 ` Catalin Marinas
2014-11-17 11:48   ` Catalin Marinas
2014-11-17 12:21     ` Arnd Bergmann
2014-11-17 13:30       ` Szabolcs Nagy
2014-11-17 14:34         ` Catalin Marinas
2014-11-16 22:33 ` Jens Gustedt
2014-11-16 23:23   ` 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=20141118105611.GC28279@e104818-lin.cambridge.arm.com \
    --to=catalin.marinas@arm.com \
    --cc=dalias@libc.org \
    --cc=keescook@chromium.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux@arm.linux.org.uk \
    --cc=luto@amacapital.net \
    --cc=musl@lists.openwall.com \
    --cc=nsz@port70.net \
    /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).