So detailed explanation. Thanks a lot. Really appreciate it.
On Fri, Aug 30, 2013 at 11:34 AM, Steve Grubb <[email protected]> wrote: > 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 <[email protected]> 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 >
-- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
