linux-kernel - Re: [GIT PULL] tracing: Two event pid filtering bug fixes

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: <20211127154226.60aea92a@oasis.local.home>
Date:   Sat, 27 Nov 2021 15:42:26 -0500
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Ingo Molnar <mingo@...nel.org>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Tom Zanussi <zanussi@...nel.org>,
        Tzvetomir Stoyanov <tz.stoyanov@...il.com>
Subject: Re: [GIT PULL] tracing: Two event pid filtering bug fixes

On Sat, 27 Nov 2021 12:12:55 -0800
Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> On Sat, Nov 27, 2021 at 10:28 AM Steven Rostedt <rostedt@...dmis.org> wrote:
> >
> > Two fixes to event pid filtering:
> >
> > - Have created events reflect the current state of pid filtering
> >
> > - Test pid filtering on discard test of recorded logic.
> >   (Also clean up the if statement to be cleaner).  
> 
> I could not parse either of those statements. The second one in
> particular is just a jumble of random words in a random order.

Ouch, rereading that I see what you mean. I guess it was a combination
of Thanksgiving Turkey, then finding out my email isn't going out due
to the updates to mail.kernel.org (which was acting as my smarthost
relay), and my wife wondering where I am (as I wasn't doing the chores
she asked me to), so I was in a bit of a rush to get the pull request
out after it had passed all my tests.

> 
> I tried to make it make sense by looking at the commits themselves,
> but who knows. Maybe I made it worse by turning it from
> incomprehensible to actively wrong.

First change:

 - If pid filtering is enabled, a flag is set to the file descriptor of
   the event for the instance buffer that has pid filtering enabled.
   This flag is checked at the time of triggering to know if the event
   should be traced or not. The problem was when an event was created
   (by module load, kprobe, eprobe, etc), a file descriptor is create
   in each instance, but it wasn't updating the pid filtering flag for
   that event. Hence, those events would start tracing on every
   task and not honor the pid filter.

Second change:

 - Even if an event is filtered out, it could have a "trigger"
   associated it it (triggers do actions based on the event fields,
   like a stack dump into the tracing buffer, or a histogram, or even
   disable tracing). Thus, the event is recorded into a temporary
   buffer so its fields may be used by the trigger. But after the
   trigger has run, it needs to know if that event should be recorded
   into the trace buffer or not, so the filtering is executed again (if
   the event is to be filtered it is discarded). But this second check
   did not take into account pid filtering, and so if an event had a
   trigger attached to it, it did not honor the pid filters, and traced
   for all processes.

Better?

> 
> Please make those explanations more clear in the future, ok?

This was a unique situation. I hope to be better next time.

-- Steve