audit.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paul Moore <paul@paul-moore.com>
To: Ivan Babrou <ivan@cloudflare.com>
Cc: audit@vger.kernel.org, linux-kernel@vger.kernel.org,
	kernel-team@cloudflare.com, Eric Paris <eparis@redhat.com>
Subject: Re: [PATCH] audit: check syscall bitmap on entry to avoid extra work
Date: Wed, 24 May 2023 22:15:33 -0400	[thread overview]
Message-ID: <CAHC9VhReahw8G4Vc0eMdhQMLhGYE53=X48akC13rN4EPkiF3tQ@mail.gmail.com> (raw)
In-Reply-To: <CABWYdi3_zAVpeTRBou_Br-n6VXeM1xWTCSvu==QWdG4sd+nnnw@mail.gmail.com>

On Wed, May 24, 2023 at 2:05 PM Ivan Babrou <ivan@cloudflare.com> wrote:
>
> On Tue, May 23, 2023 at 7:03 PM Paul Moore <paul@paul-moore.com> wrote:
> > > Could you elaborate on what exactly you would like to see added? It's
> > > not clear to me what is missing.
> >
> > I should have been more clear, let me try again ...
> >
> > From my perspective, this patch adds code and complexity to deal with
> > the performance impact of auditing.  In some cases that is the right
> > thing to do, but I would much rather see a more in-depth analysis of
> > where the audit hot spots are in this benchmark, and some thoughts on
> > how we might improve that.  In other words, don't just add additional
> > processing to bypass (slower, more involved) processing; look at the
> > processing that is currently being done and see if you can find a way
> > to make it faster.  It will likely take longer, but the results will
> > be much more useful.
>
> The fastest way to do something is to not do it to begin with.

While you are not wrong, I believe you and I are focusing on different
things.  From my perspective, you appear primarily concerned with
improving performance by reducing the overhead of auditing.  I too am
interested in reducing the audit overhead, but I also place a very
high value on maintainable code, perhaps more than performance simply
because the current audit code quality is so very poor.
Unfortunately, the patch you posted appears to me as yet another
bolt-on performance tweak that doesn't make an attempt at analyzing
the current hot spots of syscall auditing, and ideally offering
solutions.  Perhaps ultimately this approach is the only sane thing
that can be done, but I'd like to see some analysis first of the
syscall auditing path.

-- 
paul-moore.com

  reply	other threads:[~2023-05-25  2:16 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-23 18:16 [PATCH] audit: check syscall bitmap on entry to avoid extra work Ivan Babrou
2023-05-23 19:59 ` Paul Moore
2023-05-23 21:50   ` Ivan Babrou
2023-05-24  2:03     ` Paul Moore
2023-05-24 18:04       ` Ivan Babrou
2023-05-25  2:15         ` Paul Moore [this message]
2023-06-02 11:08           ` Ignat Korchagin
2023-06-02 14:56             ` Paul Moore
2023-06-02 15:15               ` Ignat Korchagin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAHC9VhReahw8G4Vc0eMdhQMLhGYE53=X48akC13rN4EPkiF3tQ@mail.gmail.com' \
    --to=paul@paul-moore.com \
    --cc=audit@vger.kernel.org \
    --cc=eparis@redhat.com \
    --cc=ivan@cloudflare.com \
    --cc=kernel-team@cloudflare.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).