<div dir="ltr">So detailed explanation.<div>Thanks a lot. </div><div>Really appreciate it. </div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Aug 30, 2013 at 11:34 AM, Steve Grubb <span dir="ltr"><<a href="mailto:sgrubb@redhat.com" target="_blank">sgrubb@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Thursday, August 29, 2013 02:14:32 PM zhu xiuming wrote:<br>
> Thanks a lot.<br>
> May I ask for more information?<br>
><br>
> I am a little confused by the code. What is the reason behind that?<br>
<br>
</div>To measure the impact, you have to repeat the test over and over. So, what you<br>
want to do is create a test that does a syscall and loops on it. You test with<br>
audit disabled and then reboot with audit enabled and run the same test. You<br>
also have to shutdown as many dameons as possible because they alter the OS<br>
timing.<br>
<div class="im"><br>
> It seems that the test.c only access /usr/include directory.But "access"<br>
> does not trigger any rules in auditd.<br>
<br>
</div>Sure it does. If you have a syscall rule on open, for example, the audit<br>
system does not know if the syscall is of interest. So it walks through the<br>
list of rules to see if any match the current syscall. If it does, then it<br>
starts walking through each field of that rule.<br>
<br>
So, if you want to do a thorough study, then you want to test both misses and<br>
hits to see how much time is spent in both cases and then compare that when<br>
the audit system is not enabled and no rules loaded to when the audit daemon<br>
is enabled and rules loaded. You might also compare to when the audit daemon<br>
is enabled but there are no rules loaded.<br>
<div class="im"><br>
> Or you mean the test.c only stress the cpu?<br>
<br>
</div>Nope. Any syscall affects the audit system. But you want to do micro benchmarks<br>
to see the cumulative effect. Its easier to see a 5% performance hit on a<br>
microbenchmark that runs for 30 seconds than one that takes milliseconds to<br>
complete. You can also change the syscall to see if different syscalls have<br>
more impact than others. For example, the rename syscall probably gets hit<br>
hard because it has to create auxiliary records when there is a match. You<br>
might test networking as filesystem watches, too.<br>
<span class="HOEnZb"><font color="#888888"><br>
-Steve<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
> On Thu, Aug 29, 2013 at 1:24 PM, Steve Grubb <<a href="mailto:sgrubb@redhat.com">sgrubb@redhat.com</a>> wrote:<br>
> > On Thursday, August 29, 2013 12:59:33 PM zhu xiuming wrote:<br>
> > > Has someone done some work related to the performance impact of enabling<br>
> > > auditd on syscalls watching?<br>
> ><br>
> > Yes, long ago.<br>
> > <a href="http://people.redhat.com/sgrubb/files/lspp-perf.tar.gz" target="_blank">http://people.redhat.com/sgrubb/files/lspp-perf.tar.gz</a><br>
> ><br>
> > Short story is watches were undistinguishable from cache hit/misses and<br>
> > syscall auditing gets more impact as more rules get added and based on how<br>
> > complicated the rule is. CPU's have changed so much since I did the<br>
> > benchmarking that I won't even hazard a guess as to what the performance<br>
> > hit<br>
> > is on current hardware with current kernel.<br>
> ><br>
> > -Steve<br>
</div></div></blockquote></div><br></div>