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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141024141936.GS27405@n2100.arm.linux.org.uk>
Date:	Fri, 24 Oct 2014 15:19:36 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Mark Rutland <mark.rutland@....com>
Cc:	linux-arm-kernel@...ts.infradead.org,
	cross-distro@...ts.linaro.org, catalin.marinas@....com,
	serban.constantinescu@....com, will.deacon@....com,
	linux-kernel@...r.kernel.org, ghackmann@...gle.com,
	ijc@...lion.org.uk, linux-api@...r.kernel.org
Subject: Re: [RFC PATCH 0/1] arm64: Fix /proc/cpuinfo

On Fri, Oct 24, 2014 at 02:56:39PM +0100, Mark Rutland wrote:
> Currently, the arm64 /proc/cpuinfo format differs from that of arm, in a
> manner which prevents some otherwise portable applications from
> functioning as expected. Specifically, the "Features" line describes the
> 64-bit hwcaps exclusive of the 32-bit hwcaps, which causes issues for
> certain applications which attempt to parse /proc/cpuinfo to detect
> features rather than directly using the hwcaps exposed via auxval.

Like it or not, but every file in procfs is a userspace API, and can
be parsed by any program.  If we change a procfs file and a userspace
program then stops working, that's our fault, and our problem to fix
(by restoring the information published there in a manner which
userspace can parse.)

So, as you've found some programs which rely on this, ARM64 really does
need to be compatible with ARM32 in this respect.

It's unfortunate that people have decided that parsing the ELF HWCAPs
from /proc/cpuinfo is an acceptable way to go, rather than using the
binary information passed, but procfs is a much more visible source
of information than some binary interface which you need to read man
pages to find.

That's the danger of publishing information in either procfs or sysfs.
Once published, it becomes part of the userspace API, and it can become
hard to remove it.  This is why we should /always/ think very carefully
about what we expose through these filesystems.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ