Hi Beau, BTW, feel free to Cc LKML too (linux-kernel@xxxxxxxxxxxxxxx) On Tue, 27 Jul 2021 12:35:35 -0700 Beau Belgrave <beaub@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx> > 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
|