Date: Tue, 18 Nov 2014 10:56:12 +0000 From: Catalin Marinas <catalin.marinas@....com> To: Andy Lutomirski <luto@...capital.net> Cc: Russell King <linux@....linux.org.uk>, "musl@...ts.openwall.com" <musl@...ts.openwall.com>, Szabolcs Nagy <nsz@...t70.net>, Kees Cook <keescook@...omium.org>, Rich Felker <dalias@...c.org>, "linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org> Subject: Re: ARM atomics overhaul for musl 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@....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
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.