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 for Android: free password hash cracker in your pocket
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 21 Apr 2016 18:16:58 +0300
From:	Alexander Shishkin <alexander.shishkin@...ux.intel.com>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org,
	vince@...ter.net, eranian@...gle.com,
	Arnaldo Carvalho de Melo <acme@...radead.org>,
	Mathieu Poirier <mathieu.poirier@...aro.org>,
	Alexander Shishkin <alexander.shishkin@...ux.intel.com>
Subject: [PATCH v1 0/5] perf: Introduce address range filtering

Hi Peter,

This is the second round of my filtering patchset. I've changed quite
many things since the previous one [1], notably

 * split the pmu callback in two as we discussed,
 * split the filter itself into 'core' and 'hw' parts,
 * made only parent events eligible for configuring filters (children
   can still have their 'hw' portions),
 * and basically re-wrote the whole thing around that.

And also, dropped the awkward 'itrace' infix, which was just
confusing and rebranded it as "address range filtering", which is
actually more representative of what it is. I also figured that it's
usefulness may not be limited to instruction tracing (or even
hardware) pmus.

Newer version of Intel PT supports address-based filtering, and this
patchset adds support for it to perf core and the PT pmu driver. It
works by configuring a number of address ranges in hardware and
telling it to use these ranges to filter its traces. Similar feature
also exists in ARM Coresight ETM/PTM and it is also taken into account
in this patchset.

Firstly, userspace configures filters via an ioctl(), filters are
formatted as an ascii string. Filters may refer to addresses in object
files for userspace code or kernel addresses. The latter might be
extended in the future to support kernel modules.

For userspace filters, we scan the task's vmas to see if any of them
match the defined filters (inode+offset) and if they do, calculate
memory offsets and program them into hardware. Note that since
different tasks will have different mappings for the same object
files, supporting cpu-wide events would require special tricks to
context-switch filters for userspace code.

Also, we monitor new mmap and exec events to update (or clear) filter
configuration.

[1] http://marc.info/?l=linux-kernel&m=144984116019143

Alexander Shishkin (5):
  perf: Move set_filter() from behind EVENT_TRACING
  perf/x86/intel/pt: IP filtering register/cpuid bits
  perf: Extend perf_event_aux_ctx() to optionally iterate through more
    events
  perf: Introduce address range filtering
  perf/x86/intel/pt: Add support for address range filtering in PT

 arch/x86/events/intel/pt.c       | 185 ++++++++++-
 arch/x86/events/intel/pt.h       |  30 ++
 arch/x86/include/asm/msr-index.h |  18 ++
 include/linux/perf_event.h       |  95 ++++++
 kernel/events/core.c             | 684 ++++++++++++++++++++++++++++++++++++---
 5 files changed, 969 insertions(+), 43 deletions(-)

-- 
2.8.0.rc3

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ