Benchmarking the performance impact of auditd

Benchmarking the performance impact of auditd

[zhu xiuming]

[-- Attachment #1.1: Type: text/plain, Size: 120 bytes --]

HI,
Has someone done some work related to the performance impact of enabling
auditd on syscalls watching?

thanks a lot

[-- Attachment #1.2: Type: text/html, Size: 177 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Benchmarking the performance impact of auditd

[Steve Grubb]

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

Re: Benchmarking the performance impact of auditd

[Nathaniel Husted]

[-- Attachment #1.1: Type: text/plain, Size: 1113 bytes --]

While obviously not extremely thorough a research group I'm involved in has
looked at the performance impact of Audit though in this case specific to
Android mobile devices on ARM. Check the section at the end of page 4.

https://www.usenix.org/system/files/conference/tapp13/tapp13-final11.pdf

Cheers,
Nathaniel


On Thu, Aug 29, 2013 at 4: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
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
>

[-- Attachment #1.2: Type: text/html, Size: 1840 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Benchmarking the performance impact of auditd

[zhu xiuming]

[-- Attachment #1.1: Type: text/plain, Size: 1406 bytes --]

Thanks a lot.
It seems that I need some benchmark tool.


On Thu, Aug 29, 2013 at 2:02 PM, Nathaniel Husted <nhusted@gmail.com> wrote:

> While obviously not extremely thorough a research group I'm involved in
> has looked at the performance impact of Audit though in this case specific
> to Android mobile devices on ARM. Check the section at the end of page 4.
>
> https://www.usenix.org/system/files/conference/tapp13/tapp13-final11.pdf
>
> Cheers,
> Nathaniel
>
>
> On Thu, Aug 29, 2013 at 4: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
>>
>> --
>> Linux-audit mailing list
>> Linux-audit@redhat.com
>> https://www.redhat.com/mailman/listinfo/linux-audit
>>
>
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
>

[-- Attachment #1.2: Type: text/html, Size: 2692 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Benchmarking the performance impact of auditd

[zhu xiuming]

[-- Attachment #1.1: Type: text/plain, Size: 2779 bytes --]

So detailed explanation.
Thanks a lot.
Really appreciate it.


On Fri, Aug 30, 2013 at 11:34 AM, Steve Grubb <sgrubb@redhat.com> 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 <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
>

[-- Attachment #1.2: Type: text/html, Size: 3689 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]