linux-kernel - Re: [RFC PATCH 0/1] arm64: Fix /proc/cpuinfo

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 6 Nov 2014 16:54:31 +0000
From:	Will Deacon <will.deacon@....com>
To:	Catalin Marinas <catalin.marinas@....com>
Cc:	Mark Rutland <Mark.Rutland@....com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"ghackmann@...gle.com" <ghackmann@...gle.com>,
	"ijc@...lion.org.uk" <ijc@...lion.org.uk>,
	Serban Constantinescu <Serban.Constantinescu@....com>,
	"cross-distro@...ts.linaro.org" <cross-distro@...ts.linaro.org>,
	"linux-api@...r.kernel.org" <linux-api@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 0/1] arm64: Fix /proc/cpuinfo

On Thu, Nov 06, 2014 at 04:43:12PM +0000, Catalin Marinas wrote:
> On Fri, Oct 24, 2014 at 02:56:39PM +0100, Mark Rutland wrote:
> > [d] Print different hwcaps dependent on the personality.
> > 
> >     This would allow for 32-bit and 64-bit applications to function
> >     correctly, but for some 32-bit applications the personality would
> >     need to be set explicitly by the user.
> 
> Which makes this option actually in line with the uname -m behaviour. My
> vote goes for [d] with option [b] as a close alternative.
> 
> > [1] arm, v3.17, Versatile Express A15x2 A7x3 coretile
> > Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm 
> [...]
> > [2] arm64, v3.17, Juno platform
> > Features        : fp asimd evtstrm aes pmull sha1 sha2 crc32 
> 
> As an exercise, I'm trying to see what option [b] would look like when
> CONFIG_COMPAT is enabled:
> 
> Features        : fp asimd evtstrm aes pmull sha1 sha2 crc32 half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae
> 
> The duplicate strings would only be listed once (evtstrm, aes, pmull,
> sha1, sha2, crc32). New AArch64 features that we may expect to be
> optional on AArch32 could be prefixed with "a64". If they are missing
> entirely from AArch32, (like asimd), no need for the prefix.
> 
> The advantage is that we don't need to check the personality but we have
> to assume that scripts would not search for substrings (sane people
> shouldn't do this anyway as the Features string can always be extended).

And a big disadvantage is that I can imagine AArch64 applications checking
for "neon" instead of "asimd", which will break if they're run under kernels
without COMPAT support enabled.

So I'm inclined to stick with Mark's patch as it is.

Will
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/