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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20211013165043.GA1427@kbox>
Date:   Wed, 13 Oct 2021 09:50:43 -0700
From:   Beau Belgrave <beaub@...ux.microsoft.com>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     Masami Hiramatsu <mhiramat@...nel.org>,
        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 Tue, Oct 12, 2021 at 09:18:52PM -0400, Steven Rostedt wrote:
> On Mon, 11 Oct 2021 09:25:23 -0700
> Beau Belgrave <beaub@...ux.microsoft.com> wrote:
> > 
> > Yes, in my mind there are two options to avoid kernel memory usage
> > per-event.
> > 
> > 1.
> > We have a an array per file struct that is independently ref-counted.
> > This is required to ensure lifetime requirements and to ensure user code
> > cannot access other user events that might have been free'd outside of
> > the lifetime and cause a kernel crash.
> > 
> > This approach also requires 2 int's to be returned, 1 for the status
> > page the other a local index for the write into the above array per-file
> > struct.
> > 
> > This is likely the most complex method due to it's lifetime and RCU
> > synchronization requirements. However, it represents the least memory to
> > both kernel and user space.
> 
> Does it require RCU synchronization as the updates only happen from
> user space. But is this for the writing of the event? You want a
> separate fd for each event to write to, instead of saying you have
> another interface to write and just pass the given id?
>
Yes, an example is a process creates the fd and registers some events.
Then the process forks and the child registers another event using the
same fd that was inherited.

If the original process writes while the child process registers at that
point the FD array can get resized / moved, therefore we need RCU deref
protection when resizing, etc.

I have a few gauntlet tools that try to crash user_events by writing,
registering, unregistering at weird times to try to flush this stuff
out.
> > In our own use case this will be low due to the way we plan to use the
> > events. However, I am not sure others will follow that :)
> 
> I will say, whenever we say this will only have a "few", if it becomes
> useful, it will end up having many.
> 
> -- Steve
Agree 100%, I've gone back and forth on which is better for a while. I'm
happy to update to RCU and send out a V3. Want to make sure we have
consensus of the right approach before spinning on it :)

Thanks,
-Beau