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: <20130424163038.GA29816@jshin-Toonie>
Date:	Wed, 24 Apr 2013 11:30:38 -0500
From:	Jacob Shin <jacob.shin@....com>
To:	Will Deacon <will.deacon@....com>
CC:	Ingo Molnar <mingo@...hat.com>, Oleg Nesterov <oleg@...hat.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
	"H. Peter Anvin" <hpa@...or.com>,
	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

On Wed, Apr 24, 2013 at 10:48:53AM +0100, Will Deacon wrote:
> On Tue, Apr 23, 2013 at 04:18:46PM +0100, Jacob Shin wrote:
> > On Tue, Apr 23, 2013 at 04:02:40PM +0100, Will Deacon wrote:
> > > On Tue, Apr 23, 2013 at 03:40:57PM +0100, Jacob Shin wrote:
> > > > >   perf stat -e mem:0x1000/0xf:w a.out
> > > 
> > > Are you saying that this command would count any write to:
> > > 
> > > 	0x1000
> > > 	0x1001
> > > 	...
> > > 	0x100e
> > > 	0x100f
> > > 
> > > ?
> > > 
> > > If so, that differs from the ARM debug architecture in that the mask is called
> > > `byte-address-select', so a mask of 0b1001 would count accesses at +0 bytes
> > > and +3 bytes from the base address. Is that possible to describe with your
> > > masking scheme and a single watchpoint?
> > > 
> > > A mask of 0xf, would count +0, +1, +2 and +3 (essentially bp_len == 4).
> > > 
> > > Unfortunately, that means I can't just invert the mask like I originally
> > > thought.
> > 
> > Ah, .. that is different .
> > 
> > Our hardware matches on the breakpoint if:
> > 
> >   (physical_address & ~bp_addr_mask) == (bp_addr & ~bp_addr_mask)
> > 
> > In other words, the mask says which of the bp_addr bits hardware should
> > ignore when matching.
> > 
> > .. it would be great if we can come up with userland interface that works
> > for both archs. I'm coming up empty at the moment ..
> 
> After a bit of thought, I *think* the ARM mechanism is more expressive, and
> you could describe your masking in terms of byte-address-select. The
> downside is that we'd end up with much larger masks, which could be argued
> as counter-intuitive from a user's point of view.

Hm .. Oleg, any thoughts on this?

bp_addr is encoded into attr.config1 and bp_len in attr.config2. I'm not
sure if attr.config is being used or not, but if not, we could say that
architecture specific "stuff" goes into attr.config.

And in perf tools:

  perf stat -e mem:0x1000/0xf:w a.out

Will just translate into setting attr.config = 0xf. And only x86
hw_breakpoint will know what .config = 0xf means for x86 and do the right
thing. For ARM, 0xf will mean something different.

The downside is that in userland perf tool we need differing documentation
on what the mask syntax means for each architecture.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ