linux-kernel - Re: [Patch 0/1] HW-BKPT: Allow per-cpu kernel-space Hardware Breakpoint requests

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, 26 Aug 2009 13:49:57 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	"K.Prasad" <prasad@...ux.vnet.ibm.com>,
	Peter Zijlstra <peterz@...radead.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Lai Jiangshan <laijs@...fujitsu.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
	Alan Stern <stern@...land.harvard.edu>
Subject: Re: [Patch 0/1] HW-BKPT: Allow per-cpu kernel-space Hardware
	Breakpoint requests

On Wed, Aug 26, 2009 at 11:16:42AM +0200, Ingo Molnar wrote:
> 
> * Frederic Weisbecker <fweisbec@...il.com> wrote:
> 
> > On Fri, Aug 21, 2009 at 04:28:11PM +0200, Ingo Molnar wrote:
> > > 
> > > * K.Prasad <prasad@...ux.vnet.ibm.com> wrote:
> > > 
> > > > > Providing those would let us build a pmu struct on top of this 
> > > > > high level API, hopefully.
> > > 
> > > Note that there's a PMU struct already in 
> > > arch/x86/kernel/cpu/perf_counter.c. Could debug-register ops be 
> > > tacked on to it?
> > 
> > No, we don't need to build an arch level pmu since the BP api 
> > already handles the arch abstraction (or well, it is planned to).
> > 
> > Instead, what we need is a core pmu that relies on the BP api. 
> > Such pmu will be allocated dynamically while creating a hardware 
> > breakpoint counter.
> 
> i'm not convinced at all we need all that layering of 
> perfcounters->pmu->BP. Why not add BP support to the PMU abstraction 
> and be done with it?
> 
> That way we get hardware breakpoints via 'pinned, exclusive, per cpu 
> hw-breakpoint counters' for example and kernel/hw-breakpoint.c can 
> go away altogether.
> 
> kernel/perf_counter.c already handles scheduling, conflict 
> resolution, enumeration, syscall exposure and more.
> 
> Hm?


What you are suggesting is a complete refactoring of the breakpoint API
on top of pmus.

Well, that's possible and would factorize the scheduling, conflict and so
on. So that's theoretically a good point and I hope we'll come to such
centralization, that looks like my suggestion to Peter to share the
perfcounter layer that handles the scheduling of hardware registers.

But the pmu handling is currently not ready for that.
For now it's completely tied to perfcounter, the pmu handling must
become completely standalone wrt perfcounter because hardware
breakpoint shouldn't depend on perfcounter.
It couldn't even, because it is not only wanted for perfcounter but
currently used by ptrace (and perhaps some other various users) and
I can't imagine we need to open a perfcounter to use ptrace facilities.

That said, I really agree with the concept, we could then drop the
scheduling bindings for hardware breakpoints and use a centralized
thing for that which would be the pmu.

But:

- the PMUs handling is not ready for that as I explained above
- we still need the hardware breakpoint layer that decodes a breakpoint
  request (address, length of the memory target, number of registers
  limitation). This part is still a mandatory feature to build dynamic
  PMU based breakpoints.

Frederic.

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