linux-kernel - Re: [PATCH v5 0/6] enable creating [k,u]probe with perf_event

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-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 19 Dec 2017 17:24:04 +0000
From:   Song Liu <songliubraving@...com>
To:     Daniel Borkmann <daniel@...earbox.net>
CC:     Peter Zijlstra <peterz@...radead.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        "mingo@...hat.com" <mingo@...hat.com>,
        David Miller <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Kernel Team <Kernel-team@...com>
Subject: Re: [PATCH v5 0/6] enable creating [k,u]probe with perf_event_open


> On Dec 8, 2017, at 11:57 AM, Daniel Borkmann <daniel@...earbox.net> wrote:
> 
> On 12/06/2017 11:45 PM, Song Liu wrote:
>> Changes PATCH v4 to PATCH v5:
>>  Remove PERF_PROBE_CONFIG_IS_RETPROBE from uapi, use PMU_FORMAT_ATTR
>>  instead.
>> 
>> Changes PATCH v3 to PATCH v4:
>>  Remove uapi define MAX_PROBE_FUNC_NAME_LEN, use KSYM_NAME_LEN instead.
>>  Add flag PERF_PROBE_CONFIG_IS_RETPROBE for config field of [k,u]probe.
>>  Optimize ifdef's of CONFIG_KPROBE_EVENTS and CONFIG_UPROBE_EVENTS.
>>  Optimize checks in perf_event_is_tracing().
>>  Optimize perf_tp_register().
>> 
>> Changes PATCH v2 to PATCH v3:
>>  Remove fixed type PERF_TYPE_KPROBE and PERF_TYPE_UPROBE, use dynamic
>>  type instead.
>>  Update userspace (samples/bpf, bcc) to look up type from sysfs.
>>  Change License info in test_many_kprobe_user.c as Philippe Ombredanne
>>  suggested.
>> 
>> Changes PATCH v1 to PATCH v2:
>>  Split PERF_TYPE_PROBE into PERF_TYPE_KPROBE and PERF_TYPE_UPROBE.
>>  Split perf_probe into perf_kprobe and perf_uprobe.
>>  Remove struct probe_desc, use config1 and config2 instead.
>> 
>> Changes RFC v2 to PATCH v1:
>>  Check type PERF_TYPE_PROBE in perf_event_set_filter().
>>  Rebase on to tip perf/core.
>> 
>> Changes RFC v1 to RFC v2:
>>  Fix build issue reported by kbuild test bot by adding ifdef of
>>  CONFIG_KPROBE_EVENTS, and CONFIG_UPROBE_EVENTS.
>> 
>> RFC v1 cover letter:
>> 
>> This is to follow up the discussion over "new kprobe api" at Linux
>> Plumbers 2017:
>> 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linuxplumbersconf.org_2017_ocw_proposals_4808&d=DwICaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=dR8692q0_uaizy0jkrBJQM5k2hfm4CiFxYT8KaysFrg&m=iAtBi3jXPYfFgvhHTsv8oWyUKiyEwnGZ34-4jniREz4&s=87sxRxoRkJJenQjCtFLJFXkMLvd_rHkY8ZGON9em1Jc&e=
>> 
>> With current kernel, user space tools can only create/destroy [k,u]probes
>> with a text-based API (kprobe_events and uprobe_events in tracefs). This
>> approach relies on user space to clean up the [k,u]probe after using them.
>> However, this is not easy for user space to clean up properly.
>> 
>> To solve this problem, we introduce a file descriptor based API.
>> Specifically, we extended perf_event_open to create [k,u]probe, and attach
>> this [k,u]probe to the file descriptor created by perf_event_open. These
>> [k,u]probe are associated with this file descriptor, so they are not
>> available in tracefs.
>> 
>> We reuse large portion of existing trace_kprobe and trace_uprobe code.
>> Currently, the file descriptor API does not support arguments as the
>> text-based API does. This should not be a problem, as user of the file
>> decriptor based API read data through other methods (bpf, etc.).
>> 
>> I also include a patch to to bcc, and a patch to man-page perf_even_open.
>> Please see the list below. A fork of bcc with this patch is also available
>> on github:
>> 
>>  https://github.com/liu-song-6/bcc/tree/perf_event_open
> 
> Peter / Stephen, I presume this will be routed through one of you, if
> not please yell.
> 
> Thanks,
> Daniel
> 

Dear Peter, 

Do you have further feedbacks/comments on these patches? If not, could you 
please confirm they are ready for merge?

Thanks and Best Regards,
Song