linux-kernel - Re: [GIT PULL] tracing: Updates for 5.18

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:   Wed, 23 Mar 2022 15:39:23 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Beau Belgrave <beaub@...ux.microsoft.com>,
        Tom Zanussi <zanussi@...nel.org>,
        Stephen Rothwell <sfr@...b.auug.org.au>
Subject: Re: [GIT PULL] tracing: Updates for 5.18

On Wed, 23 Mar 2022 11:47:07 -0700
Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> On Mon, Mar 21, 2022 at 7:56 AM Steven Rostedt <rostedt@...dmis.org> wrote:
> >
> > A restructure of include/trace caused a conflict [..]  
> 
> Ugh. Disgusting. And in the very same pull request it shows why that
> TRACE_CUSTOM_EVENT() thing that caused this all was actually a
> horribly bad idea, since it also then DIDN'T WORK due to the kernel
> interfaces changing.

I thought I explained the reasoning behind that in my pull request.

CUSTOM events have to match the function prototype to the tracepoint that
they are on top of (which is created by the TRACE_EVENT), and if they do
not, bad things can happen at run time. Thus, the added check to make sure
it will fail at build time.

> 
> So this restructuring seems to have been triggered by something that
> was a bad idea to begin with.
> 
> But the real problem is here:
> 
> > Tracing updates for 5.18:
> >
> > - New user_events interface. User space can register an event with the kernel
> >   describing the format of the event. Then it will receive a byte in a page
> >   mapping that it can check against. A privileged task can then enable that
> >   event like any other event, which will change the mapped byte to true,
> >   telling the user space application to start writing the event to the
> >   tracing buffer.  
> 
> That explanation makes no sense, because it doesn't actually explain *why*.

Sorry, sometimes when you are deep into the work, things that are obvious
to yourself may not be obvious to others. Being able to know those things
is an art onto itself.

> 
> It explains *what*, but the big issue for new interfaces shoudl always
> be why the heck a new interface was needed in the first place.

The why is that we have applications that run in containers that want
events to be traced. But we do not want to always trace those events. These
applications will not have an interface to talk to, to say "start tracing
X", as they are inside a container and various other reasons.

Thus, the applications can add their own trace events, and then the admin
that is outside the container can enable the events inside the container,
by enabling them from the tracefs file system, which will set a byte in the
mapping that happened when the application registered the event, where it
can now know to start tracing the event.

It does require that the application has a conditional jmp on that byte,
and not be optimized like the kernel is with static_branches.

I hope that explains things a bit better.

> 
> I've pulled this, but under protest.

Thank you.

-- Steve