Re: [RFC PATCH] udiag - User mode to trace_event (ftrace, perf, eBPF) ABI

[Beau Belgrave <beaub@linux.microsoft.com>]

On Tue, Aug 03, 2021 at 05:17:43PM -0400, Steven Rostedt wrote:
> 
> Hi Beau,
> 
> BTW, feel free to Cc LKML too (linux-kernel@vger.kernel.org)
> 
> 
> On Tue, 27 Jul 2021 12:35:35 -0700
> Beau Belgrave <beaub@linux.microsoft.com> wrote:
> 
> > User mode processes that require emitting diagnostic data are currently
> > limited to using uprobes to get data into trace_events. The udiag ABI
> > offers a way for user mode processes to write diagnostic data to
> > trace_events much faster than the uprobe die chain handler.
> > 
> > In addition a shared page is exposed out to registered user processes
> > that is used to enable single branch checking for if the trace_event is
> > being traced. This allows equivalent overhead as a uprobe site when
> > tracing is not enabled.
> > 
> > User processes register a trace_event to use via a device exposed at
> > /dev/udiag. System owners can write udev rules to decide the security
> > boundary. udiag is limited to only a page size worth of trace_events
> > that are isolated and put under the udiag subsystem. User processes
> > write events out via /dev/udiag. This allows for many languages and
> > processes to contribute the same events regardless of where in the code
> > the event was generated. This allows common code to be shared and
> > centrally processed on the machine within a eBPF program regardless how
> > the code has evolved as long as the data within the event follows the
> > same data format as before.
> > 
> > An example of this is common error conditions that can happen across a
> > suite of processes. A single eBPF program can watch for the single event
> > across all processes, regardless of binary location or language used to
> > create the process. Once problems are found, additional eBPF programs
> > can be launched to impose further tracing, run mitigations, etc.
> > 
> > Signed-off-by: Beau Belgrave <beaub@linux.microsoft.com>
> >
> 
> Can you provide user space code that would show a use case of this
> implementation. Understanding exactly what is expected on the user side
> will help tremendously with understanding the kernel side.
> 
> Thanks,
> 
> -- Steve
Sure thing, and thanks for the reply! I appreciate it.

For clarity, would you like a resend with the user mode code in the
description or would you like an in-thread example?

Thanks,
-Beau