linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paul Moore <paul@paul-moore.com>
To: Zixuan Zhao <zhaozixuan2@huawei.com>
Cc: eparis@redhat.com, linux-audit@redhat.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] audit: accelerate audit rule filter
Date: Wed, 24 Nov 2021 10:42:07 -0500	[thread overview]
Message-ID: <CAHC9VhS-pPDWBRX-6q7aj1Fj5oU0M2vgJC0ipTStczYGkFVvwg@mail.gmail.com> (raw)
In-Reply-To: <20211123075001.3676-1-zhaozixuan2@huawei.com>

On Tue, Nov 23, 2021 at 2:50 AM Zixuan Zhao <zhaozixuan2@huawei.com> wrote:
> We used lat_syscall of lmbench3 to test the performance impact of this
>  patch. We changed the number of rules and run lat_syscall with 1000
>  repetitions at each test. Syscalls measured by lat_syscall are not
>  monitored by rules.
>
> Before this optimization:
>
>              null     read    write     stat    fstat      open
>   0 rules  1.87ms   2.74ms   2.56ms   26.31ms  4.13ms   69.66ms
>  10 rules  2.15ms   3.13ms   3.32ms   26.99ms  4.16ms   74.70ms
>  20 rules  2.45ms   3.97ms   3.82ms   27.05ms  4.60ms   76.35ms
>  30 rules  2.64ms   4.52ms   3.95ms   30.30ms  4.94ms   78.94ms
>  40 rules  2.83ms   4.97ms   4.23ms   32.16ms  5.40ms   81.88ms
>  50 rules  3.00ms   5.30ms   4.84ms   33.49ms  5.79ms   83.20ms
> 100 rules  4.24ms   9.75ms   7.42ms   37.68ms  6.55ms   93.70ms
> 160 rules  5.50ms   16.89ms  12.18ms  51.53ms  17.45ms  155.40ms
>
> After this optimization:
>
>              null     read    write     stat    fstat      open
>   0 rules  1.81ms   2.84ms   2.42ms  27.70ms   4.15ms   69.10ms
>  10 rules  1.97ms   2.83ms   2.69ms  27.70ms   4.15ms   69.30ms
>  20 rules  1.72ms   2.91ms   2.41ms  26.49ms   3.91ms   71.19ms
>  30 rules  1.85ms   2.94ms   2.48ms  26.27ms   3.97ms   71.43ms
>  40 rules  1.88ms   2.94ms   2.78ms  26.85ms   4.08ms   69.79ms
>  50 rules  1.86ms   3.17ms   3.08ms  26.25ms   4.03ms   72.32ms
> 100 rules  1.84ms   3.00ms   2.81ms  26.25ms   3.98ms   70.25ms
> 160 rules  1.92ms   3.32ms   3.06ms  26.81ms   4.57ms   71.41ms
>
> As the result shown above, the syscall latencies increase as  the number
>  of rules increases, while with the patch the latencies remain stable.
>  This could help when a user adds many audit rules for purposes (such as
>  attack tracing or process behavior recording) but suffers from low
>  performance.

I have general concerns about trading memory and complexity for
performance gains, but beyond that the numbers you posted above don't
yet make sense to me.

Why are the latency increases due to rule count not similar across the
different syscalls? For example, I would think that if the increase in
syscall latency was directly attributed to the audit rule processing
then the increase on the "open" syscall should be similar to that of
the "null" syscall.  In other phrasing, if we can process 160 rules in
~4ms in the "null" case, why does it take us ~86ms in the "open" case?

--
paul moore
www.paul-moore.com

  reply	other threads:[~2021-11-24 15:42 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-23  7:50 [PATCH] audit: accelerate audit rule filter Zixuan Zhao
2021-11-24 15:42 ` Paul Moore [this message]
2021-11-29  7:35   ` zhaozixuan (C)
2021-12-01 19:39     ` Paul Moore
2021-12-02  2:25 zhaozixuan (C)
2021-12-06  2:49 ` Paul Moore

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=CAHC9VhS-pPDWBRX-6q7aj1Fj5oU0M2vgJC0ipTStczYGkFVvwg@mail.gmail.com \
    --to=paul@paul-moore.com \
    --cc=eparis@redhat.com \
    --cc=linux-audit@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=zhaozixuan2@huawei.com \
    /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).