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: <20141024134800.GC21513@worktop.programming.kicks-ass.net>
Date:	Fri, 24 Oct 2014 15:48:00 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Alexander Shishkin <alexander.shishkin@...ux.intel.com>
Cc:	Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org,
	Robert Richter <rric@...nel.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Mike Galbraith <efault@....de>,
	Paul Mackerras <paulus@...ba.org>,
	Stephane Eranian <eranian@...gle.com>,
	Andi Kleen <ak@...ux.intel.com>, kan.liang@...el.com,
	adrian.hunter@...el.com, acme@...radead.org
Subject: Re: [PATCH v5 12/20] x86: perf: intel_pt: Intel PT PMU driver

On Fri, Oct 24, 2014 at 04:18:46PM +0300, Alexander Shishkin wrote:
> Peter Zijlstra <peterz@...radead.org> writes:

> Ah, I see what you mean. The main point of this whole reserved region
> proposal is that one shouldn't have to update one's kernel to enable new
> PT packets by doing -e intel_pt/config=0xf00d/, if one is CAP_SYS_ADMIN.
> 
> > No need to probe in that case. That is the same thing we do for all
> > unenumerated model specific things.
> 
> They are, actually, enumerated, we just want to be able to enable them
> before they are. If the driver is aware of feature X, it can test for it
> in CPUID and allow/disallow it based on that.

If you've got hardware that 'exposes' functionality not enumerated in
CPUID you have the capability of modifying the kernel.

And while it might seem like a cute feature when you have early
hardware, that is no reason to make the code horrible. Either just patch
your firmware such that CPUID reports the right bits for your hardware
or frob the kernel.


--
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