linux-kernel - Re: [RFC PATCH 1/2] hw-breakpoints: Separate constraint space for data and instruction breakpoints

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: <20100416145607.GD5162@nowhere>
Date:	Fri, 16 Apr 2010 16:56:09 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Will Deacon <will.deacon@....com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Mahesh Salgaonkar <mahesh@...ux.vnet.ibm.com>,
	"K . Prasad" <prasad@...ux.vnet.ibm.com>,
	Paul Mundt <lethal@...ux-sh.org>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Paul Mackerras <paulus@...ba.org>, Ingo Molnar <mingo@...e.hu>
Subject: Re: [RFC PATCH 1/2] hw-breakpoints: Separate constraint space for
	data and instruction breakpoints

On Fri, Apr 16, 2010 at 03:35:30PM +0100, Will Deacon wrote:
> Hello Frederic,
> 
> Thanks for this.
> 
> On Tue, 2010-04-13 at 00:01 +0100, Frederic Weisbecker wrote:
> > There are two outstanding fashions for archs to implement hardware
> > breakpoints.
> > 
> > The first is to separate breakpoint address pattern definition
> > space between data and instruction breakpoints. We then have
> > typically distinct instruction address breakpoint registers
> > and data address breakpoint registers, delivered with
> > separate control registers for data and instruction breakpoints
> > as well. This is the case of PowerPc and ARM for example.
> > 
> > The second consists in having merged breakpoint address space
> > definition between data and instruction breakpoint. Address
> > registers can host either instruction or data address and
> > the access mode for the breakpoint is defined in a control
> > register. This is the case of x86.
> > 
> > This patch adds a new CONFIG_HAVE_MIXED_BREAKPOINTS_REGS config
> > that archs can select if they belong to the second case. Those
> > will have their slot allocation merged for instructions and
> > data breakpoints.
> > 
> > The others will have a separate slot tracking between data and
> > instruction breakpoints.
> 
> This looks useful for supporting architectures with separate
> data/instruction breakpoints.
> 
> A couple of points:
> 
> 1.) Will this affect the arch backend at all?


No change is required from the backend. In fact this config probably
only fits for x86, unless there are other archs that have shared
register addresses... Archs that only support data or inst breakpoints
should also select it, but only to save a bit of memory, there would
be no functional changes.


 
> 2.) On ARM, it is possible to have different numbers of breakpoint registers
>     and watchpoint registers [which we do not know until runtime]. This
>     means that we have to define HBP_NUM as a potential upper bound,
>     which seems a bit wasteful. Perhaps there could be a mechanism to 
>     register the available resources at runtime?


Ah that's interesting. Ok, I will update my patch to integrate that.

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