linux-kernel - Re: [PATCH v8 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] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 18 Apr 2022 22:43:29 +0200
From:   Hagen Paul Pfeifer <hagen@...u.net>
To:     Beau Belgrave <beaub@...ux.microsoft.com>
Cc:     rostedt@...dmis.org, mhiramat@...nel.org,
        linux-trace-devel@...r.kernel.org, linux-kernel@...r.kernel.org,
        Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Subject: Re: [PATCH v8 00/12] user_events: Enable user processes to create
 and write to trace events

* Beau Belgrave | 2021-12-16 09:34:59 [-0800]:

>The typical scenario is on process start to mmap user_events_status. Processes
>then register the events they plan to use via the REG ioctl. The ioctl reads
>and updates the passed in user_reg struct. The status_index of the struct is
>used to know the byte in the status page to check for that event. The
>write_index of the struct is used to describe that event when writing out to
>the fd that was used for the ioctl call. The data must always include this
>index first when writing out data for an event. Data can be written either by
>write() or by writev().

Hey Beau, a little bit late to the party. A few questions from my side: What
are the exact weak points of USDT compared to User Events that stand in the
way of further extend USDT (in a non-compatible way, sure, just as an
different approach!)? The nice thing about USDT is that I can search for all
possible probes of the system via "find / | readelf | ". Since they are listed
in a dedicated ELF section (.note.stapsdt) - they are visible & transparent. I
can also map a hierarchy/structure in Executable/DSO via clever choice of
names. The big disadvantage of USDT is the lack of type information, but from
a registration, explicit point of view, they are nice.

Or in other words: why not extends the USDT approach? Why not

u32 val = 23;
const char *garbage = "tracestring";

DYNAMIC_TRACE_PROBE2("foo:bar", val, u32, garbage, cstring);

Sure, the argument names, here "val" and "garbage" should also be saved. I
also like the "just one additional header to the project to get things
running" (#include "sdt.h"). Sure, a DYNAMIC_TRACE_IS_ACTIVE("foo:bar") would
be great. But in fact we have never needed that in the past.

hgn