linux-kernel - Re: [PATCH v0 0/5] perf: Introduce instruction trace filtering

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]

Date:	Fri, 11 Dec 2015 14:38:30 -0700
From:	Mathieu Poirier <mathieu.poirier@...aro.org>
To:	Alexander Shishkin <alexander.shishkin@...ux.intel.com>
Cc:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Ingo Molnar <mingo@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	vince@...ter.net, Stephane Eranian <eranian@...gle.com>,
	Arnaldo Carvalho de Melo <acme@...radead.org>
Subject: Re: [PATCH v0 0/5] perf: Introduce instruction trace filtering

On 11 December 2015 at 06:36, Alexander Shishkin
<alexander.shishkin@...ux.intel.com> wrote:
> Hi Peter,
>
> 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.
>
> This is based on my perf_mmap_close() patchset from yesterday [1], which
> in turn is based on your perf/core queue.
>
> [1] http://marc.info/?l=linux-kernel&m=144976438631073
>
> Alexander Shishkin (5):
>   perf: Move set_filter() from behind EVENT_TRACING
>   perf: Extend perf_event_aux() to optionally iterate through more
>     events
>   perf: Introduce instruction trace filtering
>   perf/x86/intel/pt: IP filtering register/cpuid bits
>   perf/x86/intel/pt: Add support for instruction trace filtering in PT
>
>  arch/x86/include/asm/msr-index.h          |  18 +
>  arch/x86/kernel/cpu/intel_pt.h            |  32 +-
>  arch/x86/kernel/cpu/perf_event_intel_pt.c | 134 +++++-
>  include/linux/perf_event.h                |  40 ++
>  kernel/events/core.c                      | 655 ++++++++++++++++++++++++++++--
>  5 files changed, 835 insertions(+), 44 deletions(-)
>
> --
> 2.6.2
>

Alex, Peter and al,

As I mentioned in a previous reply I think this patchset is aiming in
the right direction.  Here we are dealing with address range
filtering, something that is common to both IntelPT and CS, but what
happens when we want introduce options that aren't generic to all
tracers and still want to us the ioctl method?

Can we make the current scheme more extensible or generic so that
adding more architecture specific option is easily feasible?

Thanks for the consideration,
Mathieu
--
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/