linux-kernel - Re: [RFC PATCH 0/4] perf tools: Use the new ability of eBPF programs to access hardware PMU counter

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]

Date:	Fri, 28 Aug 2015 19:42:29 -0700
From:	Alexei Starovoitov <ast@...mgrid.com>
To:	xiakaixu <xiakaixu@...wei.com>
Cc:	davem@...emloft.net, daniel@...earbox.net, acme@...nel.org,
	mingo@...hat.com, a.p.zijlstra@...llo.nl,
	masami.hiramatsu.pt@...achi.com, jolsa@...nel.org,
	linux-kernel@...r.kernel.org, wangnan0@...wei.com, pi3orama@....com
Subject: Re: [RFC PATCH 0/4] perf tools: Use the new ability of eBPF programs
 to access hardware PMU counter

On 8/28/15 7:14 PM, xiakaixu wrote:
> Right, this is just a little example. Actually, I have tested this
> ability on kernel side and user space side, that is kprobe and uprobe.

great to hear.

> At this time i wish to get your comment on the current chosen implementation.
> Now the struct perf_event_map_def is introduced and the user can directly
> define the struct perf_event_attr, so we can skip the parse_events process
> and call the sys_perf_event_open on the events directly. This is the most
> simple implementation, but I am not sure it is the most appropriate.

I think it's a bit kludgy. You are trying to squeeze more and more
information into sections and pass them via elf.
It worked for samples early on, but now it's time to do better.
Like in bcc we just write normal C and extract all necessary information
by looking at C via clang:rewriter api. I think it's a cleaner approach.
In our use case we can compile on the host, so no intermediate files,
no elf files. If you have to cross-compile you can still use the same
approach and let llvm generate .o and emit all extra stuff as another
configuration file (say in .json), then let host load .o and use .json
to setup pmu events and everything else. It will work for higher number
of use cases, but at the end I don't see how you can avoid moving to
c+python or c+whatever approach, since static configuration (whether in
.json or in elf section) are not going to be enough. You'd need a
program in user space to deal with all the data that bpf program
in kernel is collecting.

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