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: <yw1xppddwx50.fsf@unicorn.mansr.com>
Date:	Mon, 27 Oct 2014 11:49:15 +0000
From:	Måns Rullgård <mans@...sr.com>
To:	Will Deacon <will.deacon@....com>
Cc:	Stephen Boyd <sboyd@...eaurora.org>,
	Russell King <linux@....linux.org.uk>,
	"linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-msm\@vger.kernel.org" <linux-arm-msm@...r.kernel.org>,
	"linux-arm-kernel\@lists.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Rob Clark <robdclark@...il.com>
Subject: Re: [PATCH v2 2/3] ARM: vfp: Fix VFPv3 hwcap detection on CPUID based cpus

Will Deacon <will.deacon@....com> writes:

> Perhaps it would be better to consider exposing the ID registers to
> userspace in some manner? This could be done either via an undef handler, or
> using the vdso. We would add a (final) hwcap advertising this cpuid support.
> For big/little systems, the kernel would need to expose a suitable subset of
> the features (we already have the sanity checking code from Rutland).

This was discussed a few years ago, and some people raised various
objections.  Off the top of my head:

- Some features (e.g. VFP/NEON) need kernel support, and if this is not
  enabled, the actual system capabilities will not match the raw
  register value.  Fudging the values exposed to userspace would be
  fragile.
  (This argument has some merit.)

- Only v7 and newer CPUs have the CPUID registers.  Ridiculously old
  CPUs don't even have a CP15.  Providing synthetic values might be
  tricky.  Software thus needs to support alternate feature detection
  methods for such hardware.
  (This is true enough.)

- It would only be available on new kernels, so software would still
  need a fallback to another method for the foreseeable future.
  (This is a rather lazy argument.)

- It would be specific to Linux, so software can't rely on it anyway.
  (This is an even lazier argument.)

-- 
Måns Rullgård
mans@...sr.com
--
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