linux-kernel - Re: [PATCH v10 00/12] user_events: Enable user processes to create and write to trace events

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]

Message-ID: <20220212001549.GA10191@kbox>
Date:   Fri, 11 Feb 2022 16:15:49 -0800
From:   Beau Belgrave <beaub@...ux.microsoft.com>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     mhiramat@...nel.org, linux-trace-devel@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v10 00/12] user_events: Enable user processes to create
 and write to trace events

On Thu, Feb 10, 2022 at 11:00:21PM -0500, Steven Rostedt wrote:
> On Tue, 18 Jan 2022 12:43:14 -0800
> Beau Belgrave <beaub@...ux.microsoft.com> wrote:
> 
> > User mode processes that wish to use trace events to get data into
> > ftrace, perf, eBPF, etc are limited to uprobes today. The user events
> > features enables an ABI for user mode processes to create and write to
> > trace events that are isolated from kernel level trace events. This
> > enables a faster path for tracing from user mode data as well as opens
> > managed code to participate in trace events, where stub locations are
> > dynamic.
> 
> So I finished my review, and I'm currently added it to my queue that
> I'm running through my tests.
> 
> Before I accept it though, I would really like you to send patches to
> linux-trace-devel@...r.kernel.org that add an API to libtracefs:
> 
>   https://git.kernel.org/pub/scm/libs/libtrace/libtracefs.git/
> 
> Something where users do not need to know about ioctls, or iovecs, etc.
> 
> struct tracefs_user_event *
>      tracefs_user_event_register(const char *name,
> 		enum tracefs_uevent_type type,
> 		char *field, ...);
> 
> Where tracefs_uevent_type can be:
> 
> enum tracefs_uevent_type {
> 	TRACEFS_UEVENT_END,
> 	TRACEFS_UEVENT_u8,
> 	TRACEFS_UEVENT_s8,
> 	TRACEFS_UEVENT_u16,
> 	...
> };
> 
>   uevent = tracefs_user_event_register("test",
> 		TRACEFS_UEVENT_u64, "count",
> 		TRACEFS_UEVENT_string, "name",
> 		TRACEFS_UEVENT_array, 16, "array",
> 		TRACEFS_UEVENT_END);
> 
> and that will do the ioctl to register the event, with the given types
> and fields.
> 
>   struct tracefs_user_event_status *ustatus;
> 
>   ustatus = tracefs_user_event_status();  // does the mmap.
> 
> 
> Then we could also have:
> 
>   if (tracefs_user_event_test(ustatus, uevent))
> 	tracefs_user_event_write(uevent, 64, "string", { 16 byte data });
> 
> The ustatus will be the mmap and the uevent will have the information
> to know where on the mmap to test for the event.
> 
> As for the write, the types are saved, and the write function will have
> variable arguments defined by the tracefs_user_event_register().
> 
> I think having that interface in libtracefs, would make this easy to
> use for everyone.

Agreed, I'll get going on this.

For performance I'm likely going to be play around with the shape of the
API. But it will look similar to the above.

Thanks,
-Beau