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

[Steven Rostedt <rostedt@goodmis.org>]

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