linux-kernel - Re: [RFC 4/5] x86, perf: implements lwp-perf-integration (rc1)

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]

Date:	Wed, 21 Dec 2011 01:07:16 +0100
From:	Joerg Roedel <joro@...tes.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Avi Kivity <avi@...hat.com>,
	Robert Richter <robert.richter@....com>,
	Benjamin Block <bebl@...eta.org>,
	Hans Rosenfeld <hans.rosenfeld@....com>, hpa@...or.com,
	tglx@...utronix.de, suresh.b.siddha@...el.com, eranian@...gle.com,
	brgerst@...il.com, Andreas.Herrmann3@....com, x86@...nel.org,
	linux-kernel@...r.kernel.org,
	Benjamin Block <benjamin.block@....com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [RFC 4/5] x86, perf: implements lwp-perf-integration (rc1)

On Tue, Dec 20, 2011 at 07:40:04PM +0100, Ingo Molnar wrote:

> > I am fine with integrating LWP into perf as long as it makes 
> > sense and does not break the intended usage scenario for LWP.
> 
> That's the wrong way around - in reality we'll integrate LWP 
> upstream only once it makes sense and works well with the 
> primary instrumentation abstraction we have in the kernel.

I still don't see why you want an abstraction for a hardware feature
that clearly doesn't need it. From an enablement perspective LWP is much
closer to AVX than to the MSR based PMU. And nobody really wants or
needs a kernel abstraction for AVX, no?

> Me or PeterZ could just say "this feature is too limited and not 
> convincing enough yet, sorry".

This statement shows very clearly the bottom-line of our conflict. You
see this as a perf-topic, for everyone else it is an x86 topic.

> But i'm being nice and helpful here [...]

And I appreciate the discussion. But we have fundamentally different
stand-points.  I hope we can come to an agreement.

> There's no "security implications" whatsoever. LWP is a ring-3 
> hw feature and it can do nothing that the user-space app could 
> not already do ...

Really? How could an application count DCache misses today without
instrumentation? I guess your answer is 'with perf', but LWP is a much
more light-weight way to do that because it works _completly_ in
hardware when the kernel supports context-switching it.

> 
> > [...] It also destroys the intended use-case for LWP because 
> > it disturbs any process that is doing self-profiling with LWP.
> 
> Why would it destroy that? Self-profiling can install events 
> just fine, the kernel will arbitrate the resource.

Because you can't reliably hand over the LWPCB management to the kernel.
The instruction to load a new LWPCB is executable in ring-3. Any
kernel-use of LWP will never be reliable. 

> > So what you are saying is (not just here, also in other emails 
> > in this thread) that every hardware not designed for perf is 
> > crap?
> 
> No - PMU hardware designed to not allow the profiling of the 
> kernel is obviously a crappy aspect of it. Also, PMU hardware 
> that does not allow 100% encapsulation by the kernel is 
> obviously not very wisely done either.

Why? Whats wrong with user-space having control over its own PMU in a
safe way? This is what the feature was designed for.

Thanks,

	Joerg

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