linux-kernel - Re: [PATCH V2 1/4] perf: Add hardware breakpoint address mask

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: <20130426162043.GK30858@mudshark.cambridge.arm.com>
Date:	Fri, 26 Apr 2013 17:20:44 +0100
From:	Will Deacon <will.deacon@....com>
To:	Jacob Shin <jacob.shin@....com>
Cc:	"H. Peter Anvin" <hpa@...or.com>, Oleg Nesterov <oleg@...hat.com>,
	Ingo Molnar <mingo@...hat.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
	Thomas Gleixner <tglx@...utronix.de>,
	"x86@...nel.org" <x86@...nel.org>,
	Stephane Eranian <eranian@...gle.com>,
	Jiri Olsa <jolsa@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH V2 1/4] perf: Add hardware breakpoint address mask

Hi Jacob,

On Fri, Apr 26, 2013 at 12:19:11AM +0100, Jacob Shin wrote:
> On Thu, Apr 25, 2013 at 10:17:35AM -0700, H. Peter Anvin wrote:
> > On 04/25/2013 10:06 AM, Oleg Nesterov wrote:
> > >>
> > >> The downside is that in userland perf tool we need differing documentation
> > >> on what the mask syntax means for each architecture.
> > > 
> > > Personally I think this is acceptable.
> > > 
> > > But I am new to this code, so...
> > > 
> > 
> > That would seem really, really awkward.  Yes, perf has a bunch of
> > low-level stuff, but it would seem highly undesirable to force the user
> > to deal with something like that.
> > 
> > It would be good to have a user-friendly syntax that covers most of what
> > users may want to do and perhaps a longer form that can express
> > everything including ARM's byte selects; if the system can't honor the
> > request it should return an error.
> 
> Okay,
> 
> If arch specific masks are a no go, then I think I'm convinced that
> Oleg's idea of using bp_len is the right thing to do. Right now perf
> userland tool hard codes bp_len to 4, so I need to modify it to allow
> user to override the length if desired.

So what value ends up in the bp_len field: a length or a mask? I just want
to make sure it's flexible enough that, if we add another user interface for
the byte-select stuff, we don't need to butcher the attr in another way.

> Oleg, Frederic, et al.
> 
> Which syntax do you prefer?
> 
> If we want to set bp_len to 16:
> 
>   $ perf stat -e mem:0x1000:rw:16
> 
> Or
> 
>   $ perf stat -e mem:0x1000:16
> 
> Or
> 
>   $ perf stat -e mem:0x1000/16
> 
> If no bp_len value is specified, it will still default to 4 as it did
> before.

I certainly like the ability to change the length of an execute breakpoint,
as that helps for halfword instructions on ARM (not sure if your first
syntax precludes that, but just checking...).

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