linux-kernel - Re: [PATCH] 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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20211013114034.13daac32@gandalf.local.home>
Date:   Wed, 13 Oct 2021 11:40:34 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Masami Hiramatsu <mhiramat@...nel.org>
Cc:     Beau Belgrave <beaub@...ux.microsoft.com>,
        linux-trace-devel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] user_events: Enable user processes to create and write
 to trace events

On Thu, 14 Oct 2021 00:21:32 +0900
Masami Hiramatsu <mhiramat@...nel.org> wrote:

> > This approach requires an FD returned and either an int for the status
> > page or the returend FD could expose the ID via another IOCTL being
> > issued.  
> 
> OK, I would like to suggest you to add events/user-events/*/marker file
> (which returns that shared file struct backed FD) so that some simple
> user scripts can also send the events (these may not use ioctl, just
> write the events.) But this can be done afterwards anyway.
> 

I'd prefer we avoid this. It will break some of the semantics of the events
directory. One, only "user-events" will have this "marker" file. Although
it will be very similar to the "inject" file, but that's only for debugging
anyway.

All the files in the events directory is starting to add a bunch of
overhead, as they are typically copied into the instances. Although, when
we get the eventfs directory created, maybe that will not be as big of a
deal. But that still doesn't fix the semantics issue.

-- Steve