linux-kernel - Re: [PATCH v4] [RFC] trace: Add kprobe on tracepoint

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: <20210812000343.887f0084ff1c48de8c47ec90@kernel.org>
Date:   Thu, 12 Aug 2021 00:03:43 +0900
From:   Masami Hiramatsu <mhiramat@...nel.org>
To:     "Tzvetomir Stoyanov (VMware)" <tz.stoyanov@...il.com>
Cc:     rostedt@...dmis.org, linux-trace-devel@...r.kernel.org,
        linux-kernel@...r.kernel.org, tom.zanussi@...ux.intel.com
Subject: Re: [PATCH v4] [RFC] trace: Add kprobe on tracepoint

On Wed, 11 Aug 2021 17:14:33 +0300
"Tzvetomir Stoyanov (VMware)" <tz.stoyanov@...il.com> wrote:

> From: Tzvetomir Stoyanov (VMware) <tz.stoyanov@...il.com>
> 
> A new dynamic event is introduced: event probe. The event is attached
> to an existing tracepoint and uses its fields as arguments. The user
> can specify custom format string of the new event, select what tracepoint
> arguments will be printed and how to print them.
> An event probe is created by writing configuration string in
> 'dynamic_events' ftrace file:
>  e:GNAME/ENAME SYSTEM.EVENT [FETCHARGS]	- Set an event probe

Hmm, this inconsistency looks not good to me.

"GNAME/ENAME" "SYSTEM.EVENT"
 - GNAME is "group name" but SYSTEM is "system name" but both must point
   same idea.
 - Delimiter character is different.

Aren't these confusing users?

One idea is adding a patch for kprobe and uprobe events to accept new
delimiter '.'. This will give a consistency with hist triggers too.

Also, you can add a note about that the system and group is same
meaning in events.

>  -:GNAME/ENAME				- Delete an event probe
> 
> Where:
>  GNAME	- Group name, if omitted 'eprobes' is used.

If this is not mandatory, you should write it as 

e:[GNAME/]ENAME SYSTEM.EVENT [FETCHARGS]


>  ENAME	- Name of the new event in GNAME, mandatory.
>  SYSTEM	- Name of the system, where the tracepoint is defined, mandatory.
>  EVENT	- Name of the tracepoint event in SYSTEM, mandatory.
>  FETCHARGS - Arguments:
>   <name>=$<field>[:TYPE] - Fetch given filed of the tracepoint and print
> 			   it as given TYPE with given name. Supported
> 			   types are:
> 	                    (u8/u16/u32/u64/s8/s16/s32/s64), basic type
>         	            (x8/x16/x32/x64), hexadecimal types
> 			    "string", "ustring" and bitfield.
> 
> Example, attach an event probe on openat system call and print name of the
> file that will be opened:
>  echo "e:esys/eopen syscalls.sys_enter_openat file=\$filename:string" >> dynamic_events
> A new dynamic event is created in events/esys/eopen/ directory. It
> can be deleted with:
>  echo "-:esys/eopen" >> dynamic_events
> 
> Filters, triggers and histograms can be attached to the new event, it can
> be matched in synthetic events. There is one limitation - no synthetic
> events can be attached to an event probe.

I'm not sure what the "no synthetic events can be attached to an event probe"
means.
Can you show an example command what this means?

> 
> Co-developed-by: Steven Rostedt (VMware) <rostedt@...dmis.org>
> Signed-off-by: Tzvetomir Stoyanov (VMware) <tz.stoyanov@...il.com>
> ---
> Subject of the patch is still related to kprobe, though the design no
> more depends on kprobe. I did not change it for consistency with the
> first patch version. 

OK, thanks for moving onto the dynevent. Let me check the code in another
mail.
Anyway, I think this is good starting point. 

Thank you,

-- 
Masami Hiramatsu <mhiramat@...nel.org>