On Thursday, August 29, 2013 02:14:32 PM zhu xiuming wrote:
> Thanks a lot.
> May I ask for more information?
>
> I am a little confused by the code. What is the reason behind that?

To measure the impact, you have to repeat the test over and over. So, what you
want to do is create a test that does a syscall and loops on it. You test with
audit disabled and then reboot with audit enabled and run the same test. You
also have to shutdown as many dameons as possible because they alter the OS
timing.

> It seems that the test.c only access /usr/include directory.But "access"
> does not trigger any rules in auditd.

Sure it does. If you have a syscall rule on open, for example, the audit
system does not know if the syscall is of interest. So it walks through the
list of rules to see if any match the current syscall. If it does, then it
starts walking through each field of that rule.

So, if you want to do a thorough study, then you want to test both misses and
hits to see how much time is spent in both cases and then compare that when
the audit system is not enabled and no rules loaded to when the audit daemon
is enabled and rules loaded. You might also compare to when the audit daemon
is enabled but there are no rules loaded.

> Or you mean the test.c only stress the cpu?

Nope. Any syscall affects the audit system. But you want to do micro benchmarks
to see the cumulative effect. Its easier to see a 5% performance hit on a
microbenchmark that runs for 30 seconds than one that takes milliseconds to
complete. You can also change the syscall to see if different syscalls have
more impact than others. For example, the rename syscall probably gets hit
hard because it has to create auxiliary records when there is a match. You
might test networking as filesystem watches, too.

-Steve

> On Thu, Aug 29, 2013 at 1:24 PM, Steve Grubb <sgrubb@redhat.com> wrote:
> > On Thursday, August 29, 2013 12:59:33 PM zhu xiuming wrote:
> > > Has someone done some work related to the performance impact of enabling
> > > auditd on syscalls watching?
> >
> > Yes, long ago.
> > http://people.redhat.com/sgrubb/files/lspp-perf.tar.gz
> >
> > Short story is watches were undistinguishable from cache hit/misses and
> > syscall auditing gets more impact as more rules get added and based on how
> > complicated the rule is. CPU's have changed so much since I did the
> > benchmarking that I won't even hazard a guess as to what the performance
> > hit
> > is on current hardware with current kernel.
> >
> > -Steve