linux-kernel - Re: [PATCH 1/2] hw-breakpoints: Perf interface support for breakpoint ranges

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] [day] [month] [year] [list]

Message-ID: <20091204205959.GA13473@nowhere>
Date:	Fri, 4 Dec 2009 22:00:06 +0100
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc:	Ingo Molnar <mingo@...e.hu>, LKML <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Paul Mackerras <paulus@...ba.org>,
	Prasad <prasad@...ux.vnet.ibm.com>,
	Will Deacon <will.deacon@....com>,
	Paul Mundt <lethal@...ux-sh.org>
Subject: Re: [PATCH 1/2] hw-breakpoints: Perf interface support for
	breakpoint ranges

On Fri, Dec 04, 2009 at 02:08:53PM +1100, Benjamin Herrenschmidt wrote:
> On Thu, 2009-12-03 at 22:16 +0100, Frederic Weisbecker wrote:
> > Looking a the PowerPc cpu implementations of breakpoints, we have
> > for both data and instruction breakpoints:
> > 
> > - 2 Address registers (let's rather talk about a comparison operand)
> > - Control registers that define the comparison nature (equal, greater,
> >   lesser than) against the above addresses.
> > - Control registers that define how to handle the 2 address registers.
> >   The instruction address or memory access need to either match
> >    - Address 1 OR Address 2 (OR = boolean OR, not binary)
> >    - Address 1 AND Address 2 ( AND = boolean AND, not binary)
> >   And this match is subject to the comparison rules independantly
> >   defined for these two addresses by the control registers
> 
> Well.. the debug facility is different between different PowerPC CPU
> families... There's range breakpoints on some but not all, there's data
> value compare or even instruction value compare on some, etc...



Sure.
I've picked this example (Freescale G2 PPC) as it looks one the trickiest
implementations.


 
> > The most obvious practical uses of these facilities are either the
> > definition of two independant traditional breakpoints, or the
> > definition of a breakpoint that matches a range of addresses.
> > 
> > Hence we want the generic breakpoint interface to support it.
> > This patch splits up the struct perf_event_attr::bp_addr field
> > into bp_start and bp_end.
> 
> Ok, that sounds like a good idea.
> 
> > The definition of a simple breakpoint needs bp_start and bp_end to be
> > equal, ie: a simple breakpoint is a range breakpoint which start and
> > end addresses are identical.
> 
> Ok. So a 0 sized point. Makes sense.



Now that I think about it.
Why not actually use the bp_len field. It was first meant to determine
the size of the access (1, 2, 4, 8 in x86). But that could be extended
to define ranges if breakpoint ranges imply accesses of random size.

What do you think? If the PowerPc range breakpoints are always for
random size accesses (I'm not sure about it), then that would make
sense.

In this case we should drop this patch as the current interface is already
fine. We just need to turn bp_len into a u64 (u32 may not cover every cases).



> > To define a range breakpoint, you just need to set bp_start and bp_end
> > to the limits of your address range.
> 
> Inclusive ?



Yeah, that probably makes more sense as a default.

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