* Re: Linux audit performance impact
From: Richard Guy Briggs @ 2015-02-03 16:45 UTC (permalink / raw)
To: Satish Chandra Kilaru
Cc: linux-audit@redhat.com, Viswanath, Logeswari P (MCOU OSTL)
In-Reply-To: <CAAnai+XxzpQQq_-0=MCr2FBwxA0yfW_Y3ET6QiLBmC4fSrtc8w@mail.gmail.com>
On 15/02/03, Satish Chandra Kilaru wrote:
> How many events can kernel accumulate without I/o ?
The kernel default is 64 *buffers*, but I think Fedora and RHEL set it
to 320. It is now possible to set it to "0" which means limited only by
system resources. See "man auditctl", "-b" option. An event can be
made up of several buffers.
Of course, how long a system lasts before the queue blows up depends on
your rule set...
However, at the moment, it will still write out to klog if auditd isn't
running.
> On Tuesday, February 3, 2015, Viswanath, Logeswari P (MCOU OSTL) <
> logeswari.pv@hp.com> wrote:
>
> > I don't want to disable auditing (i.e. disable audit record collection),
> > but just do not want the records to delivered to user space since I want to
> > remove the I/O overhead while running the performance test.
> > Is there any option for this?
> >
> > -----Original Message-----
> > From: Richard Guy Briggs [mailto:rgb@redhat.com <javascript:;>]
> > Sent: Thursday, January 29, 2015 10:23 PM
> > To: Viswanath, Logeswari P (MCOU OSTL)
> > Cc: Satish Chandra Kilaru; Steve Grubb; linux-audit@redhat.com
> > <javascript:;>
> > Subject: Re: Linux audit performance impact
> >
> > On 15/01/29, Viswanath, Logeswari P (MCOU OSTL) wrote:
> > > Please read my question as “Is there any option to configure kaudit
> > > not to log audit records to syslog? when auditd not running.”
> >
> > Yeah, remove audit=1 from the kernel command line, or set audit=0 in its
> > place. This will stop all but AVCs and if auditd has ever run since boot.
> > If audit=0 is on the kernel boot line, it will be impossible to run auditd.
> >
> > There is a feature request that is likely coming soon that could be
> > useful:
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=1160046
> > "If no audit daemon is running, but an audit multicast subscriber is
> > around, then the kernel shouldn't forward audit data to kmsg"
> >
> > > From: Viswanath, Logeswari P (MCOU OSTL)
> > > Sent: Thursday, January 29, 2015 11:49 AM
> > > To: 'Satish Chandra Kilaru'; Steve Grubb
> > > Cc: linux-audit@redhat.com <javascript:;>
> > > Subject: RE: Linux audit performance impact
> > >
> > > Is there any option to configure kaudit not to log audit records to
> > syslog when auditd is running?
> > > This way we can assess the impact of enabling audit without involving
> > disk I/o overhead.
> > >
> > > From: Satish Chandra Kilaru [mailto:iam.kilaru@gmail.com <javascript:;>]
> > > Sent: Thursday, January 29, 2015 9:12 AM
> > > To: Steve Grubb
> > > Cc: linux-audit@redhat.com <javascript:;><mailto:linux-audit@redhat.com
> > <javascript:;>>; Viswanath,
> > > Logeswari P (MCOU OSTL)
> > > Subject: Re: Linux audit performance impact
> > >
> > > I agree with you... but writing to disk can trigger further events
> > leading spiralling of events...
> > > I brought down my server few times with stupid rules...
> > >
> > > On Wed, Jan 28, 2015 at 10:39 PM, Steve Grubb <sgrubb@redhat.com
> > <javascript:;><mailto:sgrubb@redhat.com <javascript:;>>> wrote:
> > > On Wednesday, January 28, 2015 10:18:47 AM Satish Chandra Kilaru wrote:
> > > > Write your own program to receive audit events directly without
> > > > using auditd...
> > > > That should be faster ....
> > > > Auditd will log the events to disk causing more I/o than u need...
> > >
> > > But even that is configurable in many ways. You can decide if you want
> > > logging to disk or not and what kind of assurance that it made it to
> > > disk and the priority of that audit daemon. Then you also have all the
> > > normal tuning knobs for disk throughput that you would use for any
> > > disk performance critical system.
> > >
> > > -Steve
> > >
> > > > On Wednesday, January 28, 2015, Viswanath, Logeswari P (MCOU OSTL) <
> > > >
> > > > logeswari.pv@hp.com <javascript:;><mailto:logeswari.pv@hp.com
> > <javascript:;>>> wrote:
> > > > > Hi Steve,
> > > > >
> > > > > I am Logeswari working for HP.
> > > > >
> > > > >
> > > > >
> > > > > We want to know audit performance impact on RHEL and Suse linux to
> > > > > help us evaluate linux audit as data source for our host based IDS.
> > > > >
> > > > > When we ran our own performance test with a test audispd plugin,
> > > > > we found if a system can perform 200000 open/close system calls
> > > > > per second without auditing, system can perform only 3000
> > > > > open/close system calls auditing is enabled for open/close system
> > > > > call which is a HUGE impact on the system performance. It would be
> > > > > great if anyone can help us answering the following questions.
> > > > >
> > > > >
> > > > >
> > > > > 1) Is this performance impact expected? If yes, what is the
> > reason
> > > > > behind it and can we fix it?
> > > > >
> > > > > 2) Have anyone done any benchmarking for performance impact? If
> > yes,
> > > > > can you please share the numbers and also the steps/programs used
> > > > > the run the same.
> > > > >
> > > > > 3) Help us validating the performance test we have done in our
> > test
> > > > > setup using the steps mentioned along with the results attached.
> > > > >
> > > > >
> > > > >
> > > > > Attached test program (loader.c) to invoke open and close system
> > calls.
> > > > >
> > > > > Attached idskerndsp is the audispd plugin program.
> > > > >
> > > > > We used time command to determine how much time the system took to
> > > > > complete 50000 open/close system calls without (results attached
> > > > > Without-auditing) and with auditing enabled on the system
> > > > > (With-auditing-NOLOG-audispd-plugin and With-auditing-RAW)
> > > > >
> > > > >
> > > > >
> > > > > System details:
> > > > >
> > > > >
> > > > >
> > > > > 1 CPU machine
> > > > >
> > > > >
> > > > >
> > > > > *OS Version*
> > > > >
> > > > > RHEL 6.5
> > > > >
> > > > >
> > > > >
> > > > > *Kernel Version*
> > > > >
> > > > > uname –r
> > > > >
> > > > > 2.6.32-431.el6.x86_64
> > > > >
> > > > >
> > > > >
> > > > > Note: auditd was occupying 35% of CPU and was sleeping for most of
> > > > > the time whereas kauditd was occupying 20% of the CPU.
> > > > >
> > > > >
> > > > >
> > > > > Thanks & Regards,
> > > > >
> > > > > Logeswari.
> > >
> > >
> > >
> > > --
> > > Please Donate to www.wikipedia.org<http://www.wikipedia.org>
> >
> > > --
> > > Linux-audit mailing list
> > > Linux-audit@redhat.com <javascript:;>
> > > https://www.redhat.com/mailman/listinfo/linux-audit
> >
> >
> > - RGB
> >
> > --
> > Richard Guy Briggs <rbriggs@redhat.com <javascript:;>>
> > Senior Software Engineer, Kernel Security, AMER ENG Base Operating
> > Systems, Red Hat Remote, Ottawa, Canada
> > Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
> >
>
>
> --
> Please Donate to www.wikipedia.org
- RGB
--
Richard Guy Briggs <rbriggs@redhat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Re: Linux audit performance impact
From: Satish Chandra Kilaru @ 2015-02-03 12:03 UTC (permalink / raw)
To: Viswanath, Logeswari P (MCOU OSTL)
Cc: Richard Guy Briggs, linux-audit@redhat.com
In-Reply-To: <9DBA79E0CE64AA42B07DEDAAD0F7DB914165A49A@G4W3222.americas.hpqcorp.net>
[-- Attachment #1.1: Type: text/plain, Size: 6145 bytes --]
How many events can kernel accumulate without I/o ?
On Tuesday, February 3, 2015, Viswanath, Logeswari P (MCOU OSTL) <
logeswari.pv@hp.com> wrote:
> I don't want to disable auditing (i.e. disable audit record collection),
> but just do not want the records to delivered to user space since I want to
> remove the I/O overhead while running the performance test.
> Is there any option for this?
>
> -----Original Message-----
> From: Richard Guy Briggs [mailto:rgb@redhat.com <javascript:;>]
> Sent: Thursday, January 29, 2015 10:23 PM
> To: Viswanath, Logeswari P (MCOU OSTL)
> Cc: Satish Chandra Kilaru; Steve Grubb; linux-audit@redhat.com
> <javascript:;>
> Subject: Re: Linux audit performance impact
>
> On 15/01/29, Viswanath, Logeswari P (MCOU OSTL) wrote:
> > Please read my question as “Is there any option to configure kaudit
> > not to log audit records to syslog? when auditd not running.”
>
> Yeah, remove audit=1 from the kernel command line, or set audit=0 in its
> place. This will stop all but AVCs and if auditd has ever run since boot.
> If audit=0 is on the kernel boot line, it will be impossible to run auditd.
>
> There is a feature request that is likely coming soon that could be
> useful:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1160046
> "If no audit daemon is running, but an audit multicast subscriber is
> around, then the kernel shouldn't forward audit data to kmsg"
>
> > From: Viswanath, Logeswari P (MCOU OSTL)
> > Sent: Thursday, January 29, 2015 11:49 AM
> > To: 'Satish Chandra Kilaru'; Steve Grubb
> > Cc: linux-audit@redhat.com <javascript:;>
> > Subject: RE: Linux audit performance impact
> >
> > Is there any option to configure kaudit not to log audit records to
> syslog when auditd is running?
> > This way we can assess the impact of enabling audit without involving
> disk I/o overhead.
> >
> > From: Satish Chandra Kilaru [mailto:iam.kilaru@gmail.com <javascript:;>]
> > Sent: Thursday, January 29, 2015 9:12 AM
> > To: Steve Grubb
> > Cc: linux-audit@redhat.com <javascript:;><mailto:linux-audit@redhat.com
> <javascript:;>>; Viswanath,
> > Logeswari P (MCOU OSTL)
> > Subject: Re: Linux audit performance impact
> >
> > I agree with you... but writing to disk can trigger further events
> leading spiralling of events...
> > I brought down my server few times with stupid rules...
> >
> > On Wed, Jan 28, 2015 at 10:39 PM, Steve Grubb <sgrubb@redhat.com
> <javascript:;><mailto:sgrubb@redhat.com <javascript:;>>> wrote:
> > On Wednesday, January 28, 2015 10:18:47 AM Satish Chandra Kilaru wrote:
> > > Write your own program to receive audit events directly without
> > > using auditd...
> > > That should be faster ....
> > > Auditd will log the events to disk causing more I/o than u need...
> >
> > But even that is configurable in many ways. You can decide if you want
> > logging to disk or not and what kind of assurance that it made it to
> > disk and the priority of that audit daemon. Then you also have all the
> > normal tuning knobs for disk throughput that you would use for any
> > disk performance critical system.
> >
> > -Steve
> >
> > > On Wednesday, January 28, 2015, Viswanath, Logeswari P (MCOU OSTL) <
> > >
> > > logeswari.pv@hp.com <javascript:;><mailto:logeswari.pv@hp.com
> <javascript:;>>> wrote:
> > > > Hi Steve,
> > > >
> > > > I am Logeswari working for HP.
> > > >
> > > >
> > > >
> > > > We want to know audit performance impact on RHEL and Suse linux to
> > > > help us evaluate linux audit as data source for our host based IDS.
> > > >
> > > > When we ran our own performance test with a test audispd plugin,
> > > > we found if a system can perform 200000 open/close system calls
> > > > per second without auditing, system can perform only 3000
> > > > open/close system calls auditing is enabled for open/close system
> > > > call which is a HUGE impact on the system performance. It would be
> > > > great if anyone can help us answering the following questions.
> > > >
> > > >
> > > >
> > > > 1) Is this performance impact expected? If yes, what is the
> reason
> > > > behind it and can we fix it?
> > > >
> > > > 2) Have anyone done any benchmarking for performance impact? If
> yes,
> > > > can you please share the numbers and also the steps/programs used
> > > > the run the same.
> > > >
> > > > 3) Help us validating the performance test we have done in our
> test
> > > > setup using the steps mentioned along with the results attached.
> > > >
> > > >
> > > >
> > > > Attached test program (loader.c) to invoke open and close system
> calls.
> > > >
> > > > Attached idskerndsp is the audispd plugin program.
> > > >
> > > > We used time command to determine how much time the system took to
> > > > complete 50000 open/close system calls without (results attached
> > > > Without-auditing) and with auditing enabled on the system
> > > > (With-auditing-NOLOG-audispd-plugin and With-auditing-RAW)
> > > >
> > > >
> > > >
> > > > System details:
> > > >
> > > >
> > > >
> > > > 1 CPU machine
> > > >
> > > >
> > > >
> > > > *OS Version*
> > > >
> > > > RHEL 6.5
> > > >
> > > >
> > > >
> > > > *Kernel Version*
> > > >
> > > > uname –r
> > > >
> > > > 2.6.32-431.el6.x86_64
> > > >
> > > >
> > > >
> > > > Note: auditd was occupying 35% of CPU and was sleeping for most of
> > > > the time whereas kauditd was occupying 20% of the CPU.
> > > >
> > > >
> > > >
> > > > Thanks & Regards,
> > > >
> > > > Logeswari.
> >
> >
> >
> > --
> > Please Donate to www.wikipedia.org<http://www.wikipedia.org>
>
> > --
> > Linux-audit mailing list
> > Linux-audit@redhat.com <javascript:;>
> > https://www.redhat.com/mailman/listinfo/linux-audit
>
>
> - RGB
>
> --
> Richard Guy Briggs <rbriggs@redhat.com <javascript:;>>
> Senior Software Engineer, Kernel Security, AMER ENG Base Operating
> Systems, Red Hat Remote, Ottawa, Canada
> Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
>
--
Please Donate to www.wikipedia.org
[-- Attachment #1.2: Type: text/html, Size: 8740 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* RE: Linux audit performance impact
From: Viswanath, Logeswari P (MCOU OSTL) @ 2015-02-03 10:27 UTC (permalink / raw)
To: Richard Guy Briggs; +Cc: linux-audit@redhat.com
In-Reply-To: <20150129165231.GU29998@madcap2.tricolour.ca>
I don't want to disable auditing (i.e. disable audit record collection), but just do not want the records to delivered to user space since I want to remove the I/O overhead while running the performance test.
Is there any option for this?
-----Original Message-----
From: Richard Guy Briggs [mailto:rgb@redhat.com]
Sent: Thursday, January 29, 2015 10:23 PM
To: Viswanath, Logeswari P (MCOU OSTL)
Cc: Satish Chandra Kilaru; Steve Grubb; linux-audit@redhat.com
Subject: Re: Linux audit performance impact
On 15/01/29, Viswanath, Logeswari P (MCOU OSTL) wrote:
> Please read my question as “Is there any option to configure kaudit
> not to log audit records to syslog? when auditd not running.”
Yeah, remove audit=1 from the kernel command line, or set audit=0 in its place. This will stop all but AVCs and if auditd has ever run since boot. If audit=0 is on the kernel boot line, it will be impossible to run auditd.
There is a feature request that is likely coming soon that could be
useful:
https://bugzilla.redhat.com/show_bug.cgi?id=1160046
"If no audit daemon is running, but an audit multicast subscriber is around, then the kernel shouldn't forward audit data to kmsg"
> From: Viswanath, Logeswari P (MCOU OSTL)
> Sent: Thursday, January 29, 2015 11:49 AM
> To: 'Satish Chandra Kilaru'; Steve Grubb
> Cc: linux-audit@redhat.com
> Subject: RE: Linux audit performance impact
>
> Is there any option to configure kaudit not to log audit records to syslog when auditd is running?
> This way we can assess the impact of enabling audit without involving disk I/o overhead.
>
> From: Satish Chandra Kilaru [mailto:iam.kilaru@gmail.com]
> Sent: Thursday, January 29, 2015 9:12 AM
> To: Steve Grubb
> Cc: linux-audit@redhat.com<mailto:linux-audit@redhat.com>; Viswanath,
> Logeswari P (MCOU OSTL)
> Subject: Re: Linux audit performance impact
>
> I agree with you... but writing to disk can trigger further events leading spiralling of events...
> I brought down my server few times with stupid rules...
>
> On Wed, Jan 28, 2015 at 10:39 PM, Steve Grubb <sgrubb@redhat.com<mailto:sgrubb@redhat.com>> wrote:
> On Wednesday, January 28, 2015 10:18:47 AM Satish Chandra Kilaru wrote:
> > Write your own program to receive audit events directly without
> > using auditd...
> > That should be faster ....
> > Auditd will log the events to disk causing more I/o than u need...
>
> But even that is configurable in many ways. You can decide if you want
> logging to disk or not and what kind of assurance that it made it to
> disk and the priority of that audit daemon. Then you also have all the
> normal tuning knobs for disk throughput that you would use for any
> disk performance critical system.
>
> -Steve
>
> > On Wednesday, January 28, 2015, Viswanath, Logeswari P (MCOU OSTL) <
> >
> > logeswari.pv@hp.com<mailto:logeswari.pv@hp.com>> wrote:
> > > Hi Steve,
> > >
> > > I am Logeswari working for HP.
> > >
> > >
> > >
> > > We want to know audit performance impact on RHEL and Suse linux to
> > > help us evaluate linux audit as data source for our host based IDS.
> > >
> > > When we ran our own performance test with a test audispd plugin,
> > > we found if a system can perform 200000 open/close system calls
> > > per second without auditing, system can perform only 3000
> > > open/close system calls auditing is enabled for open/close system
> > > call which is a HUGE impact on the system performance. It would be
> > > great if anyone can help us answering the following questions.
> > >
> > >
> > >
> > > 1) Is this performance impact expected? If yes, what is the reason
> > > behind it and can we fix it?
> > >
> > > 2) Have anyone done any benchmarking for performance impact? If yes,
> > > can you please share the numbers and also the steps/programs used
> > > the run the same.
> > >
> > > 3) Help us validating the performance test we have done in our test
> > > setup using the steps mentioned along with the results attached.
> > >
> > >
> > >
> > > Attached test program (loader.c) to invoke open and close system calls.
> > >
> > > Attached idskerndsp is the audispd plugin program.
> > >
> > > We used time command to determine how much time the system took to
> > > complete 50000 open/close system calls without (results attached
> > > Without-auditing) and with auditing enabled on the system
> > > (With-auditing-NOLOG-audispd-plugin and With-auditing-RAW)
> > >
> > >
> > >
> > > System details:
> > >
> > >
> > >
> > > 1 CPU machine
> > >
> > >
> > >
> > > *OS Version*
> > >
> > > RHEL 6.5
> > >
> > >
> > >
> > > *Kernel Version*
> > >
> > > uname –r
> > >
> > > 2.6.32-431.el6.x86_64
> > >
> > >
> > >
> > > Note: auditd was occupying 35% of CPU and was sleeping for most of
> > > the time whereas kauditd was occupying 20% of the CPU.
> > >
> > >
> > >
> > > Thanks & Regards,
> > >
> > > Logeswari.
>
>
>
> --
> Please Donate to www.wikipedia.org<http://www.wikipedia.org>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
- RGB
--
Richard Guy Briggs <rbriggs@redhat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Re: [PATCH 2/2] audit: don't reset working wait time accidentally with auditd
From: Paul Moore @ 2015-02-02 21:16 UTC (permalink / raw)
To: Richard Guy Briggs; +Cc: linux-audit, eparis
In-Reply-To: <20150130211044.GY18752@madcap2.tricolour.ca>
On Friday, January 30, 2015 04:10:44 PM Richard Guy Briggs wrote:
> On 15/01/29, Paul Moore wrote:
> > On Tuesday, January 27, 2015 07:34:02 PM Richard Guy Briggs wrote:
> > > During a queue overflow condition while we are waiting for auditd to
> > > drain
> > > the queue to make room for regular messages, we don't want a successful
> > > auditd that has bypassed the queue check to reset the backlog wait time.
> > >
> > > Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> > > ---
> > >
> > > kernel/audit.c | 3 ++-
> > > 1 files changed, 2 insertions(+), 1 deletions(-)
> >
> > I'm still wondering why we ever change audit_backlog_wait_time, it is only
> > so we don't end up calling wait_for_auditd() multiple times while we are
> > waiting for the queue to drain?
>
> Not exactly. Up to the timeout, all subsequent callers will wait for
> auditd as well. It is so that if wait_for_auditd() does time out, we
> don't make new callers after that timeout wait, but return an error
> immediately. If/when auditd does manage to succeed and recover after
> that wait time, it will reset the wait time and resume normal operation.
Okay, thanks for the clarification on both patches. If I have one nit, it
would be that you could have merged both patches into a single patch; just
something to remember for future submissions.
Like the tree pruning thread patch, I'm going to queue this up for after this
upcoming merge window.
> > As a general comment, not directed at anyone in particular, the audit
> > backlog/queue handling looks a little odd ...
>
> Indeed...
I suspect we'll need to look closer at this code in the future, or rather I'll
*want* to look closer at this in the future but for right now I think we've
got enough to deal with.
--
paul moore
security @ redhat
^ permalink raw reply
* Re: [RFC PATCH v4] audit: move the tree pruning to a dedicated thread
From: Paul Moore @ 2015-02-02 20:47 UTC (permalink / raw)
To: Imre Palik
Cc: linux-audit, Eric Paris, linux-kernel, Palik, Imre, Matt Wilson
In-Reply-To: <1422626759-27859-1-git-send-email-imrep.amz@gmail.com>
On Friday, January 30, 2015 03:05:59 PM Imre Palik wrote:
> From: "Palik, Imre" <imrep@amazon.de>
>
> When file auditing is enabled, during a low memory situation, a memory
> allocation with __GFP_FS can lead to pruning the inode cache. Which can,
> in turn lead to audit_tree_freeing_mark() being called. This can call
> audit_schedule_prune(), that tries to fork a pruning thread, and
> waits until the thread is created. But forking needs memory, and the
> memory allocations there are done with __GFP_FS.
>
> So we are waiting merrily for some __GFP_FS memory allocations to complete,
> while holding some filesystem locks. This can take a while ...
>
> This patch creates a single thread for pruning the tree from
> audit_add_tree_rule(), and thus avoids the deadlock that the on-demand
> thread creation can cause.
>
> Reported-by: Matt Wilson <msw@amazon.com>
> Cc: Matt Wilson <msw@amazon.com>
> Signed-off-by: Imre Palik <imrep@amazon.de>
Thanks for your persistence on this patch, I know it can be frustrating at
times. I'm happy with this revision of the patch, but considering that we are
only one week away from the merge window opening, I'm going to queue this up
for the *next* merge window; I'll move this to the audit#next branch as soon
as the v3.20 merge window closes.
> diff --git a/kernel/audit_tree.c b/kernel/audit_tree.c
> index 2e0c974..71fd1f2 100644
> --- a/kernel/audit_tree.c
> +++ b/kernel/audit_tree.c
> @@ -37,6 +37,7 @@ struct audit_chunk {
>
> static LIST_HEAD(tree_list);
> static LIST_HEAD(prune_list);
> +static struct task_struct *prune_thread;
>
> /*
> * One struct chunk is attached to each inode of interest.
> @@ -651,6 +652,57 @@ static int tag_mount(struct vfsmount *mnt, void *arg)
> return tag_chunk(mnt->mnt_root->d_inode, arg);
> }
>
> +/*
> + * That gets run when evict_chunk() ends up needing to kill audit_tree.
> + * Runs from a separate thread.
> + */
> +static int prune_tree_thread(void *unused)
> +{
> + for (;;) {
> + set_current_state(TASK_INTERRUPTIBLE);
> + if (list_empty(&prune_list))
> + schedule();
> + __set_current_state(TASK_RUNNING);
> +
> + mutex_lock(&audit_cmd_mutex);
> + mutex_lock(&audit_filter_mutex);
> +
> + while (!list_empty(&prune_list)) {
> + struct audit_tree *victim;
> +
> + victim = list_entry(prune_list.next,
> + struct audit_tree, list);
> + list_del_init(&victim->list);
> +
> + mutex_unlock(&audit_filter_mutex);
> +
> + prune_one(victim);
> +
> + mutex_lock(&audit_filter_mutex);
> + }
> +
> + mutex_unlock(&audit_filter_mutex);
> + mutex_unlock(&audit_cmd_mutex);
> + }
> + return 0;
> +}
> +
> +static int audit_launch_prune(void)
> +{
> + if (prune_thread)
> + return 0;
> + prune_thread = kthread_create(prune_tree_thread, NULL,
> + "audit_prune_tree");
> + if (IS_ERR(prune_thread)) {
> + pr_err("cannot start thread audit_prune_tree");
> + prune_thread = NULL;
> + return -ENOMEM;
> + } else {
> + wake_up_process(prune_thread);
> + return 0;
> + }
> +}
> +
> /* called with audit_filter_mutex */
> int audit_add_tree_rule(struct audit_krule *rule)
> {
> @@ -674,6 +726,12 @@ int audit_add_tree_rule(struct audit_krule *rule)
> /* do not set rule->tree yet */
> mutex_unlock(&audit_filter_mutex);
>
> + if (unlikely(!prune_thread)) {
> + err = audit_launch_prune();
> + if (err)
> + goto Err;
> + }
> +
> err = kern_path(tree->pathname, 0, &path);
> if (err)
> goto Err;
> @@ -811,36 +869,10 @@ int audit_tag_tree(char *old, char *new)
> return failed;
> }
>
> -/*
> - * That gets run when evict_chunk() ends up needing to kill audit_tree.
> - * Runs from a separate thread.
> - */
> -static int prune_tree_thread(void *unused)
> -{
> - mutex_lock(&audit_cmd_mutex);
> - mutex_lock(&audit_filter_mutex);
> -
> - while (!list_empty(&prune_list)) {
> - struct audit_tree *victim;
> -
> - victim = list_entry(prune_list.next, struct audit_tree, list);
> - list_del_init(&victim->list);
> -
> - mutex_unlock(&audit_filter_mutex);
> -
> - prune_one(victim);
> -
> - mutex_lock(&audit_filter_mutex);
> - }
> -
> - mutex_unlock(&audit_filter_mutex);
> - mutex_unlock(&audit_cmd_mutex);
> - return 0;
> -}
>
> static void audit_schedule_prune(void)
> {
> - kthread_run(prune_tree_thread, NULL, "audit_prune_tree");
> + wake_up_process(prune_thread);
> }
>
> /*
> @@ -907,9 +939,9 @@ static void evict_chunk(struct audit_chunk *chunk)
> for (n = 0; n < chunk->count; n++)
> list_del_init(&chunk->owners[n].list);
> spin_unlock(&hash_lock);
> + mutex_unlock(&audit_filter_mutex);
> if (need_prune)
> audit_schedule_prune();
> - mutex_unlock(&audit_filter_mutex);
> }
>
> static int audit_tree_handle_event(struct fsnotify_group *group,
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [PATCH 2/2] audit: don't reset working wait time accidentally with auditd
From: Richard Guy Briggs @ 2015-01-30 21:10 UTC (permalink / raw)
To: Paul Moore; +Cc: linux-audit, eparis
In-Reply-To: <4410568.1yJqvi4AlT@sifl>
On 15/01/29, Paul Moore wrote:
> On Tuesday, January 27, 2015 07:34:02 PM Richard Guy Briggs wrote:
> > During a queue overflow condition while we are waiting for auditd to drain
> > the queue to make room for regular messages, we don't want a successful
> > auditd that has bypassed the queue check to reset the backlog wait time.
> >
> > Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> > ---
> > kernel/audit.c | 3 ++-
> > 1 files changed, 2 insertions(+), 1 deletions(-)
>
> I'm still wondering why we ever change audit_backlog_wait_time, it is only so
> we don't end up calling wait_for_auditd() multiple times while we are waiting
> for the queue to drain?
Not exactly. Up to the timeout, all subsequent callers will wait for
auditd as well. It is so that if wait_for_auditd() does time out, we
don't make new callers after that timeout wait, but return an error
immediately. If/when auditd does manage to succeed and recover after
that wait time, it will reset the wait time and resume normal operation.
> As a general comment, not directed at anyone in particular, the audit
> backlog/queue handling looks a little odd ...
Indeed...
> > diff --git a/kernel/audit.c b/kernel/audit.c
> > index b333f03..73293ea 100644
> > --- a/kernel/audit.c
> > +++ b/kernel/audit.c
> > @@ -1395,7 +1395,8 @@ struct audit_buffer *audit_log_start(struct
> > audit_context *ctx, gfp_t gfp_mask, return NULL;
> > }
> >
> > - audit_backlog_wait_time = audit_backlog_wait_time_master;
> > + if (!reserve)
> > + audit_backlog_wait_time = audit_backlog_wait_time_master;
> >
> > ab = audit_buffer_alloc(ctx, gfp_mask, type);
> > if (!ab) {
>
> --
> paul moore
- RGB
--
Richard Guy Briggs <rbriggs@redhat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
^ permalink raw reply
* Re: [PATCH 1/2] audit: don't lose set wait time on first successful call to audit_log_start()
From: Richard Guy Briggs @ 2015-01-30 21:03 UTC (permalink / raw)
To: Paul Moore; +Cc: linux-audit, eparis
In-Reply-To: <2098336.04HiSDC4cU@sifl>
On 15/01/29, Paul Moore wrote:
> On Tuesday, January 27, 2015 07:34:01 PM Richard Guy Briggs wrote:
> > Copy the set wait time to a working value to avoid losing the set value if
> > the queue overflows.
> >
> > Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> > ---
> > kernel/audit.c | 7 ++++---
> > 1 files changed, 4 insertions(+), 3 deletions(-)
>
> Just so I'm understanding this patch correctly, you create a the new
> audit_backlog_wait_time_master because the existing audit_backlog_wait_time
> can be overwritten by the code in audit_log_start() when the audit record
> backlog overflows (it is set to audit_backlog_wait_overflow), yes?
Correct.
> Further, if the queue overflows the audit_backlog_wait_time will remain set to
> audit_backlog_wait_overflow until the queue is drained, yes? Is that what we
> want?
Drained sufficiently to be able to allocate audit log buffers to regular
processes, yes.
This was the intent and original functioning until the logic was
disrupted by the "negative sleep durations" fix in commit 8291991.
Several attempts were made to fix it since (e789e56, ae887e0, 51cc83f, c81825d).
> > diff --git a/kernel/audit.c b/kernel/audit.c
> > index 53bb39b..b333f03 100644
> > --- a/kernel/audit.c
> > +++ b/kernel/audit.c
> > @@ -107,6 +107,7 @@ static u32 audit_rate_limit;
> > * When set to zero, this means unlimited. */
> > static u32 audit_backlog_limit = 64;
> > #define AUDIT_BACKLOG_WAIT_TIME (60 * HZ)
> > +static u32 audit_backlog_wait_time_master = AUDIT_BACKLOG_WAIT_TIME;
> > static u32 audit_backlog_wait_time = AUDIT_BACKLOG_WAIT_TIME;
> > static u32 audit_backlog_wait_overflow = 0;
> >
> > @@ -338,7 +339,7 @@ static int audit_set_backlog_limit(u32 limit)
> > static int audit_set_backlog_wait_time(u32 timeout)
> > {
> > return audit_do_config_change("audit_backlog_wait_time",
> > - &audit_backlog_wait_time, timeout);
> > + &audit_backlog_wait_time_master, timeout);
> > }
> >
> > static int audit_set_enabled(u32 state)
> > @@ -843,7 +844,7 @@ static int audit_receive_msg(struct sk_buff *skb, struct
> > nlmsghdr *nlh) s.lost = atomic_read(&audit_lost);
> > s.backlog = skb_queue_len(&audit_skb_queue);
> > s.version = AUDIT_VERSION_LATEST;
> > - s.backlog_wait_time = audit_backlog_wait_time;
> > + s.backlog_wait_time = audit_backlog_wait_time_master;
> > audit_send_reply(skb, seq, AUDIT_GET, 0, 0, &s, sizeof(s));
> > break;
> > }
> > @@ -1394,7 +1395,7 @@ struct audit_buffer *audit_log_start(struct
> > audit_context *ctx, gfp_t gfp_mask, return NULL;
> > }
> >
> > - audit_backlog_wait_time = AUDIT_BACKLOG_WAIT_TIME;
> > + audit_backlog_wait_time = audit_backlog_wait_time_master;
> >
> > ab = audit_buffer_alloc(ctx, gfp_mask, type);
> > if (!ab) {
>
> --
> paul moore
> security @ redhat
>
- RGB
--
Richard Guy Briggs <rbriggs@redhat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
^ permalink raw reply
* Re: [RFC PATCH v4] audit: move the tree pruning to a dedicated thread
From: Richard Guy Briggs @ 2015-01-30 18:42 UTC (permalink / raw)
To: Imre Palik; +Cc: linux-audit, Palik, Imre, Matt Wilson, linux-kernel
In-Reply-To: <1422626759-27859-1-git-send-email-imrep.amz@gmail.com>
On 15/01/30, Imre Palik wrote:
> From: "Palik, Imre" <imrep@amazon.de>
>
> When file auditing is enabled, during a low memory situation, a memory
> allocation with __GFP_FS can lead to pruning the inode cache. Which can,
> in turn lead to audit_tree_freeing_mark() being called. This can call
> audit_schedule_prune(), that tries to fork a pruning thread, and
> waits until the thread is created. But forking needs memory, and the
> memory allocations there are done with __GFP_FS.
>
> So we are waiting merrily for some __GFP_FS memory allocations to complete,
> while holding some filesystem locks. This can take a while ...
>
> This patch creates a single thread for pruning the tree from
> audit_add_tree_rule(), and thus avoids the deadlock that the on-demand
> thread creation can cause.
>
> Reported-by: Matt Wilson <msw@amazon.com>
> Cc: Matt Wilson <msw@amazon.com>
> Signed-off-by: Imre Palik <imrep@amazon.de>
Reviewed-by: Richard Guy Briggs <rgb@redhat.com>
> ---
> kernel/audit_tree.c | 88 +++++++++++++++++++++++++++++++++++----------------
> 1 file changed, 60 insertions(+), 28 deletions(-)
>
> diff --git a/kernel/audit_tree.c b/kernel/audit_tree.c
> index 2e0c974..71fd1f2 100644
> --- a/kernel/audit_tree.c
> +++ b/kernel/audit_tree.c
> @@ -37,6 +37,7 @@ struct audit_chunk {
>
> static LIST_HEAD(tree_list);
> static LIST_HEAD(prune_list);
> +static struct task_struct *prune_thread;
>
> /*
> * One struct chunk is attached to each inode of interest.
> @@ -651,6 +652,57 @@ static int tag_mount(struct vfsmount *mnt, void *arg)
> return tag_chunk(mnt->mnt_root->d_inode, arg);
> }
>
> +/*
> + * That gets run when evict_chunk() ends up needing to kill audit_tree.
> + * Runs from a separate thread.
> + */
> +static int prune_tree_thread(void *unused)
> +{
> + for (;;) {
> + set_current_state(TASK_INTERRUPTIBLE);
> + if (list_empty(&prune_list))
> + schedule();
> + __set_current_state(TASK_RUNNING);
> +
> + mutex_lock(&audit_cmd_mutex);
> + mutex_lock(&audit_filter_mutex);
> +
> + while (!list_empty(&prune_list)) {
> + struct audit_tree *victim;
> +
> + victim = list_entry(prune_list.next,
> + struct audit_tree, list);
> + list_del_init(&victim->list);
> +
> + mutex_unlock(&audit_filter_mutex);
> +
> + prune_one(victim);
> +
> + mutex_lock(&audit_filter_mutex);
> + }
> +
> + mutex_unlock(&audit_filter_mutex);
> + mutex_unlock(&audit_cmd_mutex);
> + }
> + return 0;
> +}
> +
> +static int audit_launch_prune(void)
> +{
> + if (prune_thread)
> + return 0;
> + prune_thread = kthread_create(prune_tree_thread, NULL,
> + "audit_prune_tree");
> + if (IS_ERR(prune_thread)) {
> + pr_err("cannot start thread audit_prune_tree");
> + prune_thread = NULL;
> + return -ENOMEM;
> + } else {
> + wake_up_process(prune_thread);
> + return 0;
> + }
> +}
> +
> /* called with audit_filter_mutex */
> int audit_add_tree_rule(struct audit_krule *rule)
> {
> @@ -674,6 +726,12 @@ int audit_add_tree_rule(struct audit_krule *rule)
> /* do not set rule->tree yet */
> mutex_unlock(&audit_filter_mutex);
>
> + if (unlikely(!prune_thread)) {
> + err = audit_launch_prune();
> + if (err)
> + goto Err;
> + }
> +
> err = kern_path(tree->pathname, 0, &path);
> if (err)
> goto Err;
> @@ -811,36 +869,10 @@ int audit_tag_tree(char *old, char *new)
> return failed;
> }
>
> -/*
> - * That gets run when evict_chunk() ends up needing to kill audit_tree.
> - * Runs from a separate thread.
> - */
> -static int prune_tree_thread(void *unused)
> -{
> - mutex_lock(&audit_cmd_mutex);
> - mutex_lock(&audit_filter_mutex);
> -
> - while (!list_empty(&prune_list)) {
> - struct audit_tree *victim;
> -
> - victim = list_entry(prune_list.next, struct audit_tree, list);
> - list_del_init(&victim->list);
> -
> - mutex_unlock(&audit_filter_mutex);
> -
> - prune_one(victim);
> -
> - mutex_lock(&audit_filter_mutex);
> - }
> -
> - mutex_unlock(&audit_filter_mutex);
> - mutex_unlock(&audit_cmd_mutex);
> - return 0;
> -}
>
> static void audit_schedule_prune(void)
> {
> - kthread_run(prune_tree_thread, NULL, "audit_prune_tree");
> + wake_up_process(prune_thread);
> }
>
> /*
> @@ -907,9 +939,9 @@ static void evict_chunk(struct audit_chunk *chunk)
> for (n = 0; n < chunk->count; n++)
> list_del_init(&chunk->owners[n].list);
> spin_unlock(&hash_lock);
> + mutex_unlock(&audit_filter_mutex);
> if (need_prune)
> audit_schedule_prune();
> - mutex_unlock(&audit_filter_mutex);
> }
>
> static int audit_tree_handle_event(struct fsnotify_group *group,
> --
> 1.7.9.5
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
- RGB
--
Richard Guy Briggs <rbriggs@redhat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
^ permalink raw reply
* [RFC PATCH v4] audit: move the tree pruning to a dedicated thread
From: Imre Palik @ 2015-01-30 14:05 UTC (permalink / raw)
To: linux-audit
Cc: Paul Moore, Eric Paris, linux-kernel, Palik, Imre, Matt Wilson
From: "Palik, Imre" <imrep@amazon.de>
When file auditing is enabled, during a low memory situation, a memory
allocation with __GFP_FS can lead to pruning the inode cache. Which can,
in turn lead to audit_tree_freeing_mark() being called. This can call
audit_schedule_prune(), that tries to fork a pruning thread, and
waits until the thread is created. But forking needs memory, and the
memory allocations there are done with __GFP_FS.
So we are waiting merrily for some __GFP_FS memory allocations to complete,
while holding some filesystem locks. This can take a while ...
This patch creates a single thread for pruning the tree from
audit_add_tree_rule(), and thus avoids the deadlock that the on-demand
thread creation can cause.
Reported-by: Matt Wilson <msw@amazon.com>
Cc: Matt Wilson <msw@amazon.com>
Signed-off-by: Imre Palik <imrep@amazon.de>
---
kernel/audit_tree.c | 88 +++++++++++++++++++++++++++++++++++----------------
1 file changed, 60 insertions(+), 28 deletions(-)
diff --git a/kernel/audit_tree.c b/kernel/audit_tree.c
index 2e0c974..71fd1f2 100644
--- a/kernel/audit_tree.c
+++ b/kernel/audit_tree.c
@@ -37,6 +37,7 @@ struct audit_chunk {
static LIST_HEAD(tree_list);
static LIST_HEAD(prune_list);
+static struct task_struct *prune_thread;
/*
* One struct chunk is attached to each inode of interest.
@@ -651,6 +652,57 @@ static int tag_mount(struct vfsmount *mnt, void *arg)
return tag_chunk(mnt->mnt_root->d_inode, arg);
}
+/*
+ * That gets run when evict_chunk() ends up needing to kill audit_tree.
+ * Runs from a separate thread.
+ */
+static int prune_tree_thread(void *unused)
+{
+ for (;;) {
+ set_current_state(TASK_INTERRUPTIBLE);
+ if (list_empty(&prune_list))
+ schedule();
+ __set_current_state(TASK_RUNNING);
+
+ mutex_lock(&audit_cmd_mutex);
+ mutex_lock(&audit_filter_mutex);
+
+ while (!list_empty(&prune_list)) {
+ struct audit_tree *victim;
+
+ victim = list_entry(prune_list.next,
+ struct audit_tree, list);
+ list_del_init(&victim->list);
+
+ mutex_unlock(&audit_filter_mutex);
+
+ prune_one(victim);
+
+ mutex_lock(&audit_filter_mutex);
+ }
+
+ mutex_unlock(&audit_filter_mutex);
+ mutex_unlock(&audit_cmd_mutex);
+ }
+ return 0;
+}
+
+static int audit_launch_prune(void)
+{
+ if (prune_thread)
+ return 0;
+ prune_thread = kthread_create(prune_tree_thread, NULL,
+ "audit_prune_tree");
+ if (IS_ERR(prune_thread)) {
+ pr_err("cannot start thread audit_prune_tree");
+ prune_thread = NULL;
+ return -ENOMEM;
+ } else {
+ wake_up_process(prune_thread);
+ return 0;
+ }
+}
+
/* called with audit_filter_mutex */
int audit_add_tree_rule(struct audit_krule *rule)
{
@@ -674,6 +726,12 @@ int audit_add_tree_rule(struct audit_krule *rule)
/* do not set rule->tree yet */
mutex_unlock(&audit_filter_mutex);
+ if (unlikely(!prune_thread)) {
+ err = audit_launch_prune();
+ if (err)
+ goto Err;
+ }
+
err = kern_path(tree->pathname, 0, &path);
if (err)
goto Err;
@@ -811,36 +869,10 @@ int audit_tag_tree(char *old, char *new)
return failed;
}
-/*
- * That gets run when evict_chunk() ends up needing to kill audit_tree.
- * Runs from a separate thread.
- */
-static int prune_tree_thread(void *unused)
-{
- mutex_lock(&audit_cmd_mutex);
- mutex_lock(&audit_filter_mutex);
-
- while (!list_empty(&prune_list)) {
- struct audit_tree *victim;
-
- victim = list_entry(prune_list.next, struct audit_tree, list);
- list_del_init(&victim->list);
-
- mutex_unlock(&audit_filter_mutex);
-
- prune_one(victim);
-
- mutex_lock(&audit_filter_mutex);
- }
-
- mutex_unlock(&audit_filter_mutex);
- mutex_unlock(&audit_cmd_mutex);
- return 0;
-}
static void audit_schedule_prune(void)
{
- kthread_run(prune_tree_thread, NULL, "audit_prune_tree");
+ wake_up_process(prune_thread);
}
/*
@@ -907,9 +939,9 @@ static void evict_chunk(struct audit_chunk *chunk)
for (n = 0; n < chunk->count; n++)
list_del_init(&chunk->owners[n].list);
spin_unlock(&hash_lock);
+ mutex_unlock(&audit_filter_mutex);
if (need_prune)
audit_schedule_prune();
- mutex_unlock(&audit_filter_mutex);
}
static int audit_tree_handle_event(struct fsnotify_group *group,
--
1.7.9.5
^ permalink raw reply related
* RE: Linux audit performance impact
From: Viswanath, Logeswari P (MCOU OSTL) @ 2015-01-30 13:08 UTC (permalink / raw)
To: Satish Chandra Kilaru, Richard Guy Briggs; +Cc: linux-audit@redhat.com
In-Reply-To: <CAAnai+UD_1-KK6xpUnRP2vscTZHHAoiU88b4eKk5kYO9fdtFAg@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 5823 bytes --]
Test program tries to open the same file that exists on the system.
From: Satish Chandra Kilaru [mailto:iam.kilaru@gmail.com]
Sent: Thursday, January 29, 2015 10:44 PM
To: Richard Guy Briggs
Cc: Viswanath, Logeswari P (MCOU OSTL); Steve Grubb; linux-audit@redhat.com
Subject: Re: Linux audit performance impact
Try configuring external syslog server...that way ur disk is free of I/o...
Are you opening/closing same file again and again or different files?
If external syslog server is not possible, try to open files from a disk that is not used by syslog...
On Thursday, January 29, 2015, Richard Guy Briggs <rgb@redhat.com<mailto:rgb@redhat.com>> wrote:
On 15/01/29, Viswanath, Logeswari P (MCOU OSTL) wrote:
> Please read my question as “Is there any option to configure kaudit
> not to log audit records to syslog? when auditd not running.”
Yeah, remove audit=1 from the kernel command line, or set audit=0 in its
place. This will stop all but AVCs and if auditd has ever run since
boot. If audit=0 is on the kernel boot line, it will be impossible to
run auditd.
There is a feature request that is likely coming soon that could be
useful:
https://bugzilla.redhat.com/show_bug.cgi?id=1160046
"If no audit daemon is running, but an audit multicast subscriber is
around, then the kernel shouldn't forward audit data to kmsg"
> From: Viswanath, Logeswari P (MCOU OSTL)
> Sent: Thursday, January 29, 2015 11:49 AM
> To: 'Satish Chandra Kilaru'; Steve Grubb
> Cc: linux-audit@redhat.com<javascript:;>
> Subject: RE: Linux audit performance impact
>
> Is there any option to configure kaudit not to log audit records to syslog when auditd is running?
> This way we can assess the impact of enabling audit without involving disk I/o overhead.
>
> From: Satish Chandra Kilaru [mailto:iam.kilaru@gmail.com<javascript:;>]
> Sent: Thursday, January 29, 2015 9:12 AM
> To: Steve Grubb
> Cc: linux-audit@redhat.com<javascript:;><mailto:linux-audit@redhat.com<javascript:;>>; Viswanath, Logeswari P (MCOU OSTL)
> Subject: Re: Linux audit performance impact
>
> I agree with you... but writing to disk can trigger further events leading spiralling of events...
> I brought down my server few times with stupid rules...
>
> On Wed, Jan 28, 2015 at 10:39 PM, Steve Grubb <sgrubb@redhat.com<javascript:;><mailto:sgrubb@redhat.com<javascript:;>>> wrote:
> On Wednesday, January 28, 2015 10:18:47 AM Satish Chandra Kilaru wrote:
> > Write your own program to receive audit events directly without using
> > auditd...
> > That should be faster ....
> > Auditd will log the events to disk causing more I/o than u need...
>
> But even that is configurable in many ways. You can decide if you want logging
> to disk or not and what kind of assurance that it made it to disk and the
> priority of that audit daemon. Then you also have all the normal tuning knobs
> for disk throughput that you would use for any disk performance critical
> system.
>
> -Steve
>
> > On Wednesday, January 28, 2015, Viswanath, Logeswari P (MCOU OSTL) <
> >
> > logeswari.pv@hp.com<javascript:;><mailto:logeswari.pv@hp.com<javascript:;>>> wrote:
> > > Hi Steve,
> > >
> > > I am Logeswari working for HP.
> > >
> > >
> > >
> > > We want to know audit performance impact on RHEL and Suse linux to help us
> > > evaluate linux audit as data source for our host based IDS.
> > >
> > > When we ran our own performance test with a test audispd plugin, we found
> > > if a system can perform 200000 open/close system calls per second without
> > > auditing, system can perform only 3000 open/close system calls auditing is
> > > enabled for open/close system call which is a HUGE impact on the system
> > > performance. It would be great if anyone can help us answering the
> > > following questions.
> > >
> > >
> > >
> > > 1) Is this performance impact expected? If yes, what is the reason
> > > behind it and can we fix it?
> > >
> > > 2) Have anyone done any benchmarking for performance impact? If yes,
> > > can you please share the numbers and also the steps/programs used the run
> > > the same.
> > >
> > > 3) Help us validating the performance test we have done in our test
> > > setup using the steps mentioned along with the results attached.
> > >
> > >
> > >
> > > Attached test program (loader.c) to invoke open and close system calls.
> > >
> > > Attached idskerndsp is the audispd plugin program.
> > >
> > > We used time command to determine how much time the system took to
> > > complete 50000 open/close system calls without (results attached
> > > Without-auditing) and with auditing enabled on the system
> > > (With-auditing-NOLOG-audispd-plugin and With-auditing-RAW)
> > >
> > >
> > >
> > > System details:
> > >
> > >
> > >
> > > 1 CPU machine
> > >
> > >
> > >
> > > *OS Version*
> > >
> > > RHEL 6.5
> > >
> > >
> > >
> > > *Kernel Version*
> > >
> > > uname –r
> > >
> > > 2.6.32-431.el6.x86_64
> > >
> > >
> > >
> > > Note: auditd was occupying 35% of CPU and was sleeping for most of the
> > > time whereas kauditd was occupying 20% of the CPU.
> > >
> > >
> > >
> > > Thanks & Regards,
> > >
> > > Logeswari.
>
>
>
> --
> Please Donate to www.wikipedia.org<http://www.wikipedia.org><http://www.wikipedia.org>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com<javascript:;>
> https://www.redhat.com/mailman/listinfo/linux-audit
- RGB
--
Richard Guy Briggs <rbriggs@redhat.com<javascript:;>>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
--
Please Donate to www.wikipedia.org<http://www.wikipedia.org>
[-- Attachment #1.2: Type: text/html, Size: 10383 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] audit: don't reset working wait time accidentally with auditd
From: Paul Moore @ 2015-01-29 23:16 UTC (permalink / raw)
To: Richard Guy Briggs; +Cc: linux-audit, eparis
In-Reply-To: <075a355dd6d63a0330ffc5ef5a3480132540827b.1422392773.git.rgb@redhat.com>
On Tuesday, January 27, 2015 07:34:02 PM Richard Guy Briggs wrote:
> During a queue overflow condition while we are waiting for auditd to drain
> the queue to make room for regular messages, we don't want a successful
> auditd that has bypassed the queue check to reset the backlog wait time.
>
> Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> ---
> kernel/audit.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
I'm still wondering why we ever change audit_backlog_wait_time, it is only so
we don't end up calling wait_for_auditd() multiple times while we are waiting
for the queue to drain?
As a general comment, not directed at anyone in particular, the audit
backlog/queue handling looks a little odd ...
> diff --git a/kernel/audit.c b/kernel/audit.c
> index b333f03..73293ea 100644
> --- a/kernel/audit.c
> +++ b/kernel/audit.c
> @@ -1395,7 +1395,8 @@ struct audit_buffer *audit_log_start(struct
> audit_context *ctx, gfp_t gfp_mask, return NULL;
> }
>
> - audit_backlog_wait_time = audit_backlog_wait_time_master;
> + if (!reserve)
> + audit_backlog_wait_time = audit_backlog_wait_time_master;
>
> ab = audit_buffer_alloc(ctx, gfp_mask, type);
> if (!ab) {
--
paul moore
security @ redhat
^ permalink raw reply
* Re: [PATCH 1/2] audit: don't lose set wait time on first successful call to audit_log_start()
From: Paul Moore @ 2015-01-29 23:11 UTC (permalink / raw)
To: Richard Guy Briggs; +Cc: linux-audit, eparis
In-Reply-To: <2192ffc51189b5caa7d7172d59fea6fcc8bf07a5.1422392773.git.rgb@redhat.com>
On Tuesday, January 27, 2015 07:34:01 PM Richard Guy Briggs wrote:
> Copy the set wait time to a working value to avoid losing the set value if
> the queue overflows.
>
> Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> ---
> kernel/audit.c | 7 ++++---
> 1 files changed, 4 insertions(+), 3 deletions(-)
Just so I'm understanding this patch correctly, you create a the new
audit_backlog_wait_time_master because the existing audit_backlog_wait_time
can be overwritten by the code in audit_log_start() when the audit record
backlog overflows (it is set to audit_backlog_wait_overflow), yes?
Further, if the queue overflows the audit_backlog_wait_time will remain set to
audit_backlog_wait_overflow until the queue is drained, yes? Is that what we
want?
> diff --git a/kernel/audit.c b/kernel/audit.c
> index 53bb39b..b333f03 100644
> --- a/kernel/audit.c
> +++ b/kernel/audit.c
> @@ -107,6 +107,7 @@ static u32 audit_rate_limit;
> * When set to zero, this means unlimited. */
> static u32 audit_backlog_limit = 64;
> #define AUDIT_BACKLOG_WAIT_TIME (60 * HZ)
> +static u32 audit_backlog_wait_time_master = AUDIT_BACKLOG_WAIT_TIME;
> static u32 audit_backlog_wait_time = AUDIT_BACKLOG_WAIT_TIME;
> static u32 audit_backlog_wait_overflow = 0;
>
> @@ -338,7 +339,7 @@ static int audit_set_backlog_limit(u32 limit)
> static int audit_set_backlog_wait_time(u32 timeout)
> {
> return audit_do_config_change("audit_backlog_wait_time",
> - &audit_backlog_wait_time, timeout);
> + &audit_backlog_wait_time_master, timeout);
> }
>
> static int audit_set_enabled(u32 state)
> @@ -843,7 +844,7 @@ static int audit_receive_msg(struct sk_buff *skb, struct
> nlmsghdr *nlh) s.lost = atomic_read(&audit_lost);
> s.backlog = skb_queue_len(&audit_skb_queue);
> s.version = AUDIT_VERSION_LATEST;
> - s.backlog_wait_time = audit_backlog_wait_time;
> + s.backlog_wait_time = audit_backlog_wait_time_master;
> audit_send_reply(skb, seq, AUDIT_GET, 0, 0, &s, sizeof(s));
> break;
> }
> @@ -1394,7 +1395,7 @@ struct audit_buffer *audit_log_start(struct
> audit_context *ctx, gfp_t gfp_mask, return NULL;
> }
>
> - audit_backlog_wait_time = AUDIT_BACKLOG_WAIT_TIME;
> + audit_backlog_wait_time = audit_backlog_wait_time_master;
>
> ab = audit_buffer_alloc(ctx, gfp_mask, type);
> if (!ab) {
--
paul moore
security @ redhat
^ permalink raw reply
* Re: Linux audit performance impact
From: Satish Chandra Kilaru @ 2015-01-29 17:13 UTC (permalink / raw)
To: Richard Guy Briggs
Cc: linux-audit@redhat.com, Viswanath, Logeswari P (MCOU OSTL)
In-Reply-To: <20150129165231.GU29998@madcap2.tricolour.ca>
[-- Attachment #1.1: Type: text/plain, Size: 5780 bytes --]
Try configuring external syslog server...that way ur disk is free of I/o...
Are you opening/closing same file again and again or different files?
If external syslog server is not possible, try to open files from a disk
that is not used by syslog...
On Thursday, January 29, 2015, Richard Guy Briggs <rgb@redhat.com> wrote:
> On 15/01/29, Viswanath, Logeswari P (MCOU OSTL) wrote:
> > Please read my question as “Is there any option to configure kaudit
> > not to log audit records to syslog? when auditd not running.”
>
> Yeah, remove audit=1 from the kernel command line, or set audit=0 in its
> place. This will stop all but AVCs and if auditd has ever run since
> boot. If audit=0 is on the kernel boot line, it will be impossible to
> run auditd.
>
> There is a feature request that is likely coming soon that could be
> useful:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1160046
> "If no audit daemon is running, but an audit multicast subscriber is
> around, then the kernel shouldn't forward audit data to kmsg"
>
> > From: Viswanath, Logeswari P (MCOU OSTL)
> > Sent: Thursday, January 29, 2015 11:49 AM
> > To: 'Satish Chandra Kilaru'; Steve Grubb
> > Cc: linux-audit@redhat.com <javascript:;>
> > Subject: RE: Linux audit performance impact
> >
> > Is there any option to configure kaudit not to log audit records to
> syslog when auditd is running?
> > This way we can assess the impact of enabling audit without involving
> disk I/o overhead.
> >
> > From: Satish Chandra Kilaru [mailto:iam.kilaru@gmail.com <javascript:;>]
> > Sent: Thursday, January 29, 2015 9:12 AM
> > To: Steve Grubb
> > Cc: linux-audit@redhat.com <javascript:;><mailto:linux-audit@redhat.com
> <javascript:;>>; Viswanath, Logeswari P (MCOU OSTL)
> > Subject: Re: Linux audit performance impact
> >
> > I agree with you... but writing to disk can trigger further events
> leading spiralling of events...
> > I brought down my server few times with stupid rules...
> >
> > On Wed, Jan 28, 2015 at 10:39 PM, Steve Grubb <sgrubb@redhat.com
> <javascript:;><mailto:sgrubb@redhat.com <javascript:;>>> wrote:
> > On Wednesday, January 28, 2015 10:18:47 AM Satish Chandra Kilaru wrote:
> > > Write your own program to receive audit events directly without using
> > > auditd...
> > > That should be faster ....
> > > Auditd will log the events to disk causing more I/o than u need...
> >
> > But even that is configurable in many ways. You can decide if you want
> logging
> > to disk or not and what kind of assurance that it made it to disk and the
> > priority of that audit daemon. Then you also have all the normal tuning
> knobs
> > for disk throughput that you would use for any disk performance critical
> > system.
> >
> > -Steve
> >
> > > On Wednesday, January 28, 2015, Viswanath, Logeswari P (MCOU OSTL) <
> > >
> > > logeswari.pv@hp.com <javascript:;><mailto:logeswari.pv@hp.com
> <javascript:;>>> wrote:
> > > > Hi Steve,
> > > >
> > > > I am Logeswari working for HP.
> > > >
> > > >
> > > >
> > > > We want to know audit performance impact on RHEL and Suse linux to
> help us
> > > > evaluate linux audit as data source for our host based IDS.
> > > >
> > > > When we ran our own performance test with a test audispd plugin, we
> found
> > > > if a system can perform 200000 open/close system calls per second
> without
> > > > auditing, system can perform only 3000 open/close system calls
> auditing is
> > > > enabled for open/close system call which is a HUGE impact on the
> system
> > > > performance. It would be great if anyone can help us answering the
> > > > following questions.
> > > >
> > > >
> > > >
> > > > 1) Is this performance impact expected? If yes, what is the
> reason
> > > > behind it and can we fix it?
> > > >
> > > > 2) Have anyone done any benchmarking for performance impact? If
> yes,
> > > > can you please share the numbers and also the steps/programs used
> the run
> > > > the same.
> > > >
> > > > 3) Help us validating the performance test we have done in our
> test
> > > > setup using the steps mentioned along with the results attached.
> > > >
> > > >
> > > >
> > > > Attached test program (loader.c) to invoke open and close system
> calls.
> > > >
> > > > Attached idskerndsp is the audispd plugin program.
> > > >
> > > > We used time command to determine how much time the system took to
> > > > complete 50000 open/close system calls without (results attached
> > > > Without-auditing) and with auditing enabled on the system
> > > > (With-auditing-NOLOG-audispd-plugin and With-auditing-RAW)
> > > >
> > > >
> > > >
> > > > System details:
> > > >
> > > >
> > > >
> > > > 1 CPU machine
> > > >
> > > >
> > > >
> > > > *OS Version*
> > > >
> > > > RHEL 6.5
> > > >
> > > >
> > > >
> > > > *Kernel Version*
> > > >
> > > > uname –r
> > > >
> > > > 2.6.32-431.el6.x86_64
> > > >
> > > >
> > > >
> > > > Note: auditd was occupying 35% of CPU and was sleeping for most of
> the
> > > > time whereas kauditd was occupying 20% of the CPU.
> > > >
> > > >
> > > >
> > > > Thanks & Regards,
> > > >
> > > > Logeswari.
> >
> >
> >
> > --
> > Please Donate to www.wikipedia.org<http://www.wikipedia.org>
>
> > --
> > Linux-audit mailing list
> > Linux-audit@redhat.com <javascript:;>
> > https://www.redhat.com/mailman/listinfo/linux-audit
>
>
> - RGB
>
> --
> Richard Guy Briggs <rbriggs@redhat.com <javascript:;>>
> Senior Software Engineer, Kernel Security, AMER ENG Base Operating
> Systems, Red Hat
> Remote, Ottawa, Canada
> Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
>
--
Please Donate to www.wikipedia.org
[-- Attachment #1.2: Type: text/html, Size: 8205 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: Linux audit performance impact
From: Richard Guy Briggs @ 2015-01-29 16:52 UTC (permalink / raw)
To: Viswanath, Logeswari P (MCOU OSTL); +Cc: linux-audit@redhat.com
In-Reply-To: <9DBA79E0CE64AA42B07DEDAAD0F7DB9141659EE1@G4W3222.americas.hpqcorp.net>
On 15/01/29, Viswanath, Logeswari P (MCOU OSTL) wrote:
> Please read my question as “Is there any option to configure kaudit
> not to log audit records to syslog? when auditd not running.”
Yeah, remove audit=1 from the kernel command line, or set audit=0 in its
place. This will stop all but AVCs and if auditd has ever run since
boot. If audit=0 is on the kernel boot line, it will be impossible to
run auditd.
There is a feature request that is likely coming soon that could be
useful:
https://bugzilla.redhat.com/show_bug.cgi?id=1160046
"If no audit daemon is running, but an audit multicast subscriber is
around, then the kernel shouldn't forward audit data to kmsg"
> From: Viswanath, Logeswari P (MCOU OSTL)
> Sent: Thursday, January 29, 2015 11:49 AM
> To: 'Satish Chandra Kilaru'; Steve Grubb
> Cc: linux-audit@redhat.com
> Subject: RE: Linux audit performance impact
>
> Is there any option to configure kaudit not to log audit records to syslog when auditd is running?
> This way we can assess the impact of enabling audit without involving disk I/o overhead.
>
> From: Satish Chandra Kilaru [mailto:iam.kilaru@gmail.com]
> Sent: Thursday, January 29, 2015 9:12 AM
> To: Steve Grubb
> Cc: linux-audit@redhat.com<mailto:linux-audit@redhat.com>; Viswanath, Logeswari P (MCOU OSTL)
> Subject: Re: Linux audit performance impact
>
> I agree with you... but writing to disk can trigger further events leading spiralling of events...
> I brought down my server few times with stupid rules...
>
> On Wed, Jan 28, 2015 at 10:39 PM, Steve Grubb <sgrubb@redhat.com<mailto:sgrubb@redhat.com>> wrote:
> On Wednesday, January 28, 2015 10:18:47 AM Satish Chandra Kilaru wrote:
> > Write your own program to receive audit events directly without using
> > auditd...
> > That should be faster ....
> > Auditd will log the events to disk causing more I/o than u need...
>
> But even that is configurable in many ways. You can decide if you want logging
> to disk or not and what kind of assurance that it made it to disk and the
> priority of that audit daemon. Then you also have all the normal tuning knobs
> for disk throughput that you would use for any disk performance critical
> system.
>
> -Steve
>
> > On Wednesday, January 28, 2015, Viswanath, Logeswari P (MCOU OSTL) <
> >
> > logeswari.pv@hp.com<mailto:logeswari.pv@hp.com>> wrote:
> > > Hi Steve,
> > >
> > > I am Logeswari working for HP.
> > >
> > >
> > >
> > > We want to know audit performance impact on RHEL and Suse linux to help us
> > > evaluate linux audit as data source for our host based IDS.
> > >
> > > When we ran our own performance test with a test audispd plugin, we found
> > > if a system can perform 200000 open/close system calls per second without
> > > auditing, system can perform only 3000 open/close system calls auditing is
> > > enabled for open/close system call which is a HUGE impact on the system
> > > performance. It would be great if anyone can help us answering the
> > > following questions.
> > >
> > >
> > >
> > > 1) Is this performance impact expected? If yes, what is the reason
> > > behind it and can we fix it?
> > >
> > > 2) Have anyone done any benchmarking for performance impact? If yes,
> > > can you please share the numbers and also the steps/programs used the run
> > > the same.
> > >
> > > 3) Help us validating the performance test we have done in our test
> > > setup using the steps mentioned along with the results attached.
> > >
> > >
> > >
> > > Attached test program (loader.c) to invoke open and close system calls.
> > >
> > > Attached idskerndsp is the audispd plugin program.
> > >
> > > We used time command to determine how much time the system took to
> > > complete 50000 open/close system calls without (results attached
> > > Without-auditing) and with auditing enabled on the system
> > > (With-auditing-NOLOG-audispd-plugin and With-auditing-RAW)
> > >
> > >
> > >
> > > System details:
> > >
> > >
> > >
> > > 1 CPU machine
> > >
> > >
> > >
> > > *OS Version*
> > >
> > > RHEL 6.5
> > >
> > >
> > >
> > > *Kernel Version*
> > >
> > > uname –r
> > >
> > > 2.6.32-431.el6.x86_64
> > >
> > >
> > >
> > > Note: auditd was occupying 35% of CPU and was sleeping for most of the
> > > time whereas kauditd was occupying 20% of the CPU.
> > >
> > >
> > >
> > > Thanks & Regards,
> > >
> > > Logeswari.
>
>
>
> --
> Please Donate to www.wikipedia.org<http://www.wikipedia.org>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
- RGB
--
Richard Guy Briggs <rbriggs@redhat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* RE: Linux audit performance impact
From: Viswanath, Logeswari P (MCOU OSTL) @ 2015-01-29 13:29 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit@redhat.com
In-Reply-To: <5473650.MEjjDQdHXo@x2>
Hi Steve,
We ran the same performance test with auditd not started and events go to syslog.
System can perform 15000 open/close system calls per second which is better than earlier results (3000 open/close system calls per sec) but still the impact is big (compared to 200000 open/close per sec without auditing) and not acceptable.
Do you know the reason behind where kauditd spends time and how it can be improved?
Thanks & Regards,
Logeswari.
-----Original Message-----
From: Steve Grubb [mailto:sgrubb@redhat.com]
Sent: Wednesday, January 28, 2015 8:46 PM
To: linux-audit@redhat.com
Cc: Viswanath, Logeswari P (MCOU OSTL)
Subject: Re: Linux audit performance impact
Hello,
On Wednesday, January 28, 2015 02:57:58 PM Viswanath, Logeswari P wrote:
> We want to know audit performance impact on RHEL and Suse linux to
> help us evaluate linux audit as data source for our host based IDS.
> When we ran our own performance test with a test audispd plugin, we
> found if a system can perform 200000 open/close system calls per
> second without auditing, system can perform only 3000 open/close
> system calls auditing is enabled for open/close system call which is a
> HUGE impact on the system performance. It would be great if anyone can help us answering the following questions.
>
>
> 1) Is this performance impact expected? If yes, what is the reason
> behind it and can we fix it?
I'll leave this for the kernel guys to answer. That said, I think more detailed information might be helpful.
If auditd is not started and events go to syslog, does the performance change?
To do this audit=1 on boot line and auditctl -R /etc/rules.d/your.rules
what rules do you have loaded?
What do you get when audit is enabled and no rules loaded?
If you have other syscall rules loaded that are not open and openat or close, does the performance change? I suspect that if you trigger a rule, you are thrown onto the slow path. Open is perhaps the most lengthy because of multiple auxiliary records and path resolution. But we need data to tell.
That said, I know that the kernel audit path changed a couple years ago so it might be worthwhile to test against an old kernel to see if the change has affected performance.
-Steve
> 2) Have anyone done any benchmarking for performance impact? If yes,
> can you please share the numbers and also the steps/programs used the
> run the same.
>
> 3) Help us validating the performance test we have done in our test
> setup using the steps mentioned along with the results attached.
>
> Attached test program (loader.c) to invoke open and close system calls.
> Attached idskerndsp is the audispd plugin program.
> We used time command to determine how much time the system took to
> complete
> 50000 open/close system calls without (results attached
> Without-auditing) and with auditing enabled on the system
> (With-auditing-NOLOG-audispd-plugin
> and With-auditing-RAW)
>
> System details:
>
> 1 CPU machine
>
> OS Version
> RHEL 6.5
>
> Kernel Version
> uname -r
> 2.6.32-431.el6.x86_64
>
> Note: auditd was occupying 35% of CPU and was sleeping for most of the
> time whereas kauditd was occupying 20% of the CPU.
>
> Thanks & Regards,
> Logeswari.
^ permalink raw reply
* Re: [PATCH v10 1/3] arm64: Add __NR_* definitions for compat syscalls
From: Will Deacon @ 2015-01-29 9:57 UTC (permalink / raw)
To: Timur Tabi
Cc: AKASHI Takahiro, Al Viro, eparis@redhat.com, rgb@redhat.com,
Catalin Marinas, linaro-kernel@lists.linaro.org, Deepak Saxena,
lkml, linux-audit@redhat.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAOZdJXUhpmi0SM5izDYQnx8SHjWjqOFVduV0+boPw6+YCKP5+g@mail.gmail.com>
On Wed, Jan 28, 2015 at 09:31:49PM +0000, Timur Tabi wrote:
> On Fri, Jul 4, 2014 at 2:28 AM, AKASHI Takahiro
> <takahiro.akashi@linaro.org> wrote:
> > +#define __ARM_NR_COMPAT_BASE 0x0f0000
> > +#define __ARM_NR_compat_cacheflush (__ARM_NR_COMPAT_BASE+2)
> > +#define __ARM_NR_compat_set_tls (__ARM_NR_COMPAT_BASE+5)
>
> I know this patch is six months old, but I was wondering if anyone
> knows of any plans to make these syscalls available to 64-bit apps?
> We have a 32-bit app that uses __ARM_NR_compat_cacheflush, and we'd
> like to port that app to 64-bit. I'm just not sure how to start doing
> that, since there don't appear to be any 64-bit ARM-specific syscalls.
You can issue cache maintenance instructions directly from EL0 in AArch64.
Take a look at DC CVAU, DC CVAC, DC CIVAC, IC IVAU and DC ZVA.
As for the TLS register, that's also writable from EL0 but I wouldn't
recommend messing with it outside of libc.
Will
^ permalink raw reply
* RE: Linux audit performance impact
From: Viswanath, Logeswari P (MCOU OSTL) @ 2015-01-29 9:20 UTC (permalink / raw)
To: Satish Chandra Kilaru, Steve Grubb; +Cc: linux-audit@redhat.com
In-Reply-To: <CAAnai+Uq0o5pnmp065RoBtn0hcLCtJSzf-fgp-sRC7H1HETX_A@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 3785 bytes --]
Please read my question as “Is there any option to configure kaudit not to log audit records to syslog? when auditd not running.”
From: Viswanath, Logeswari P (MCOU OSTL)
Sent: Thursday, January 29, 2015 11:49 AM
To: 'Satish Chandra Kilaru'; Steve Grubb
Cc: linux-audit@redhat.com
Subject: RE: Linux audit performance impact
Is there any option to configure kaudit not to log audit records to syslog when auditd is running?
This way we can assess the impact of enabling audit without involving disk I/o overhead.
From: Satish Chandra Kilaru [mailto:iam.kilaru@gmail.com]
Sent: Thursday, January 29, 2015 9:12 AM
To: Steve Grubb
Cc: linux-audit@redhat.com<mailto:linux-audit@redhat.com>; Viswanath, Logeswari P (MCOU OSTL)
Subject: Re: Linux audit performance impact
I agree with you... but writing to disk can trigger further events leading spiralling of events...
I brought down my server few times with stupid rules...
On Wed, Jan 28, 2015 at 10:39 PM, Steve Grubb <sgrubb@redhat.com<mailto:sgrubb@redhat.com>> wrote:
On Wednesday, January 28, 2015 10:18:47 AM Satish Chandra Kilaru wrote:
> Write your own program to receive audit events directly without using
> auditd...
> That should be faster ....
> Auditd will log the events to disk causing more I/o than u need...
But even that is configurable in many ways. You can decide if you want logging
to disk or not and what kind of assurance that it made it to disk and the
priority of that audit daemon. Then you also have all the normal tuning knobs
for disk throughput that you would use for any disk performance critical
system.
-Steve
> On Wednesday, January 28, 2015, Viswanath, Logeswari P (MCOU OSTL) <
>
> logeswari.pv@hp.com<mailto:logeswari.pv@hp.com>> wrote:
> > Hi Steve,
> >
> > I am Logeswari working for HP.
> >
> >
> >
> > We want to know audit performance impact on RHEL and Suse linux to help us
> > evaluate linux audit as data source for our host based IDS.
> >
> > When we ran our own performance test with a test audispd plugin, we found
> > if a system can perform 200000 open/close system calls per second without
> > auditing, system can perform only 3000 open/close system calls auditing is
> > enabled for open/close system call which is a HUGE impact on the system
> > performance. It would be great if anyone can help us answering the
> > following questions.
> >
> >
> >
> > 1) Is this performance impact expected? If yes, what is the reason
> > behind it and can we fix it?
> >
> > 2) Have anyone done any benchmarking for performance impact? If yes,
> > can you please share the numbers and also the steps/programs used the run
> > the same.
> >
> > 3) Help us validating the performance test we have done in our test
> > setup using the steps mentioned along with the results attached.
> >
> >
> >
> > Attached test program (loader.c) to invoke open and close system calls.
> >
> > Attached idskerndsp is the audispd plugin program.
> >
> > We used time command to determine how much time the system took to
> > complete 50000 open/close system calls without (results attached
> > Without-auditing) and with auditing enabled on the system
> > (With-auditing-NOLOG-audispd-plugin and With-auditing-RAW)
> >
> >
> >
> > System details:
> >
> >
> >
> > 1 CPU machine
> >
> >
> >
> > *OS Version*
> >
> > RHEL 6.5
> >
> >
> >
> > *Kernel Version*
> >
> > uname –r
> >
> > 2.6.32-431.el6.x86_64
> >
> >
> >
> > Note: auditd was occupying 35% of CPU and was sleeping for most of the
> > time whereas kauditd was occupying 20% of the CPU.
> >
> >
> >
> > Thanks & Regards,
> >
> > Logeswari.
--
Please Donate to www.wikipedia.org<http://www.wikipedia.org>
[-- Attachment #1.2: Type: text/html, Size: 9062 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* RE: Linux audit performance impact
From: Viswanath, Logeswari P (MCOU OSTL) @ 2015-01-29 6:18 UTC (permalink / raw)
To: Satish Chandra Kilaru, Steve Grubb; +Cc: linux-audit@redhat.com
In-Reply-To: <CAAnai+Uq0o5pnmp065RoBtn0hcLCtJSzf-fgp-sRC7H1HETX_A@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 3413 bytes --]
Is there any option to configure kaudit not to log audit records to syslog when auditd is running?
This way we can assess the impact of enabling audit without involving disk I/o overhead.
From: Satish Chandra Kilaru [mailto:iam.kilaru@gmail.com]
Sent: Thursday, January 29, 2015 9:12 AM
To: Steve Grubb
Cc: linux-audit@redhat.com; Viswanath, Logeswari P (MCOU OSTL)
Subject: Re: Linux audit performance impact
I agree with you... but writing to disk can trigger further events leading spiralling of events...
I brought down my server few times with stupid rules...
On Wed, Jan 28, 2015 at 10:39 PM, Steve Grubb <sgrubb@redhat.com<mailto:sgrubb@redhat.com>> wrote:
On Wednesday, January 28, 2015 10:18:47 AM Satish Chandra Kilaru wrote:
> Write your own program to receive audit events directly without using
> auditd...
> That should be faster ....
> Auditd will log the events to disk causing more I/o than u need...
But even that is configurable in many ways. You can decide if you want logging
to disk or not and what kind of assurance that it made it to disk and the
priority of that audit daemon. Then you also have all the normal tuning knobs
for disk throughput that you would use for any disk performance critical
system.
-Steve
> On Wednesday, January 28, 2015, Viswanath, Logeswari P (MCOU OSTL) <
>
> logeswari.pv@hp.com<mailto:logeswari.pv@hp.com>> wrote:
> > Hi Steve,
> >
> > I am Logeswari working for HP.
> >
> >
> >
> > We want to know audit performance impact on RHEL and Suse linux to help us
> > evaluate linux audit as data source for our host based IDS.
> >
> > When we ran our own performance test with a test audispd plugin, we found
> > if a system can perform 200000 open/close system calls per second without
> > auditing, system can perform only 3000 open/close system calls auditing is
> > enabled for open/close system call which is a HUGE impact on the system
> > performance. It would be great if anyone can help us answering the
> > following questions.
> >
> >
> >
> > 1) Is this performance impact expected? If yes, what is the reason
> > behind it and can we fix it?
> >
> > 2) Have anyone done any benchmarking for performance impact? If yes,
> > can you please share the numbers and also the steps/programs used the run
> > the same.
> >
> > 3) Help us validating the performance test we have done in our test
> > setup using the steps mentioned along with the results attached.
> >
> >
> >
> > Attached test program (loader.c) to invoke open and close system calls.
> >
> > Attached idskerndsp is the audispd plugin program.
> >
> > We used time command to determine how much time the system took to
> > complete 50000 open/close system calls without (results attached
> > Without-auditing) and with auditing enabled on the system
> > (With-auditing-NOLOG-audispd-plugin and With-auditing-RAW)
> >
> >
> >
> > System details:
> >
> >
> >
> > 1 CPU machine
> >
> >
> >
> > *OS Version*
> >
> > RHEL 6.5
> >
> >
> >
> > *Kernel Version*
> >
> > uname –r
> >
> > 2.6.32-431.el6.x86_64
> >
> >
> >
> > Note: auditd was occupying 35% of CPU and was sleeping for most of the
> > time whereas kauditd was occupying 20% of the CPU.
> >
> >
> >
> > Thanks & Regards,
> >
> > Logeswari.
--
Please Donate to www.wikipedia.org<http://www.wikipedia.org>
[-- Attachment #1.2: Type: text/html, Size: 7437 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: Linux audit performance impact
From: Satish Chandra Kilaru @ 2015-01-29 3:41 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit@redhat.com, Viswanath, Logeswari P (MCOU OSTL)
In-Reply-To: <2570512.tu3C9iW5N2@x2>
[-- Attachment #1.1: Type: text/plain, Size: 3119 bytes --]
I agree with you... but writing to disk can trigger further events leading
spiralling of events...
I brought down my server few times with stupid rules...
On Wed, Jan 28, 2015 at 10:39 PM, Steve Grubb <sgrubb@redhat.com> wrote:
> On Wednesday, January 28, 2015 10:18:47 AM Satish Chandra Kilaru wrote:
> > Write your own program to receive audit events directly without using
> > auditd...
> > That should be faster ....
> > Auditd will log the events to disk causing more I/o than u need...
>
> But even that is configurable in many ways. You can decide if you want
> logging
> to disk or not and what kind of assurance that it made it to disk and the
> priority of that audit daemon. Then you also have all the normal tuning
> knobs
> for disk throughput that you would use for any disk performance critical
> system.
>
> -Steve
>
> > On Wednesday, January 28, 2015, Viswanath, Logeswari P (MCOU OSTL) <
> >
> > logeswari.pv@hp.com> wrote:
> > > Hi Steve,
> > >
> > > I am Logeswari working for HP.
> > >
> > >
> > >
> > > We want to know audit performance impact on RHEL and Suse linux to
> help us
> > > evaluate linux audit as data source for our host based IDS.
> > >
> > > When we ran our own performance test with a test audispd plugin, we
> found
> > > if a system can perform 200000 open/close system calls per second
> without
> > > auditing, system can perform only 3000 open/close system calls
> auditing is
> > > enabled for open/close system call which is a HUGE impact on the system
> > > performance. It would be great if anyone can help us answering the
> > > following questions.
> > >
> > >
> > >
> > > 1) Is this performance impact expected? If yes, what is the reason
> > > behind it and can we fix it?
> > >
> > > 2) Have anyone done any benchmarking for performance impact? If
> yes,
> > > can you please share the numbers and also the steps/programs used the
> run
> > > the same.
> > >
> > > 3) Help us validating the performance test we have done in our
> test
> > > setup using the steps mentioned along with the results attached.
> > >
> > >
> > >
> > > Attached test program (loader.c) to invoke open and close system calls.
> > >
> > > Attached idskerndsp is the audispd plugin program.
> > >
> > > We used time command to determine how much time the system took to
> > > complete 50000 open/close system calls without (results attached
> > > Without-auditing) and with auditing enabled on the system
> > > (With-auditing-NOLOG-audispd-plugin and With-auditing-RAW)
> > >
> > >
> > >
> > > System details:
> > >
> > >
> > >
> > > 1 CPU machine
> > >
> > >
> > >
> > > *OS Version*
> > >
> > > RHEL 6.5
> > >
> > >
> > >
> > > *Kernel Version*
> > >
> > > uname –r
> > >
> > > 2.6.32-431.el6.x86_64
> > >
> > >
> > >
> > > Note: auditd was occupying 35% of CPU and was sleeping for most of the
> > > time whereas kauditd was occupying 20% of the CPU.
> > >
> > >
> > >
> > > Thanks & Regards,
> > >
> > > Logeswari.
>
--
Please Donate to www.wikipedia.org
[-- Attachment #1.2: Type: text/html, Size: 4276 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: Linux audit performance impact
From: Steve Grubb @ 2015-01-29 3:39 UTC (permalink / raw)
To: linux-audit; +Cc: Viswanath, Logeswari P (MCOU OSTL)
In-Reply-To: <CAAnai+W5WWJ1n=s1ojODH92AeU81jR44fqNHLz+d2zyyHkjG=A@mail.gmail.com>
On Wednesday, January 28, 2015 10:18:47 AM Satish Chandra Kilaru wrote:
> Write your own program to receive audit events directly without using
> auditd...
> That should be faster ....
> Auditd will log the events to disk causing more I/o than u need...
But even that is configurable in many ways. You can decide if you want logging
to disk or not and what kind of assurance that it made it to disk and the
priority of that audit daemon. Then you also have all the normal tuning knobs
for disk throughput that you would use for any disk performance critical
system.
-Steve
> On Wednesday, January 28, 2015, Viswanath, Logeswari P (MCOU OSTL) <
>
> logeswari.pv@hp.com> wrote:
> > Hi Steve,
> >
> > I am Logeswari working for HP.
> >
> >
> >
> > We want to know audit performance impact on RHEL and Suse linux to help us
> > evaluate linux audit as data source for our host based IDS.
> >
> > When we ran our own performance test with a test audispd plugin, we found
> > if a system can perform 200000 open/close system calls per second without
> > auditing, system can perform only 3000 open/close system calls auditing is
> > enabled for open/close system call which is a HUGE impact on the system
> > performance. It would be great if anyone can help us answering the
> > following questions.
> >
> >
> >
> > 1) Is this performance impact expected? If yes, what is the reason
> > behind it and can we fix it?
> >
> > 2) Have anyone done any benchmarking for performance impact? If yes,
> > can you please share the numbers and also the steps/programs used the run
> > the same.
> >
> > 3) Help us validating the performance test we have done in our test
> > setup using the steps mentioned along with the results attached.
> >
> >
> >
> > Attached test program (loader.c) to invoke open and close system calls.
> >
> > Attached idskerndsp is the audispd plugin program.
> >
> > We used time command to determine how much time the system took to
> > complete 50000 open/close system calls without (results attached
> > Without-auditing) and with auditing enabled on the system
> > (With-auditing-NOLOG-audispd-plugin and With-auditing-RAW)
> >
> >
> >
> > System details:
> >
> >
> >
> > 1 CPU machine
> >
> >
> >
> > *OS Version*
> >
> > RHEL 6.5
> >
> >
> >
> > *Kernel Version*
> >
> > uname –r
> >
> > 2.6.32-431.el6.x86_64
> >
> >
> >
> > Note: auditd was occupying 35% of CPU and was sleeping for most of the
> > time whereas kauditd was occupying 20% of the CPU.
> >
> >
> >
> > Thanks & Regards,
> >
> > Logeswari.
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Re: Linux audit performance impact
From: Satish Chandra Kilaru @ 2015-01-29 2:59 UTC (permalink / raw)
To: Viswanath, Logeswari P (MCOU OSTL); +Cc: linux-audit@redhat.com
In-Reply-To: <9DBA79E0CE64AA42B07DEDAAD0F7DB9141659CF6@G4W3222.americas.hpqcorp.net>
[-- Attachment #1.1: Type: text/plain, Size: 3853 bytes --]
if u enable monitorint write system call, writes by audit system will lead
to a spiral of audit messages...
On Wed, Jan 28, 2015 at 10:52 AM, Viswanath, Logeswari P (MCOU OSTL) <
logeswari.pv@hp.com> wrote:
> Hi Steve,
>
> Thanks for the quick reply.
>
> Please look in-line for my replies.
>
> Regards,
> Logeswari.
>
> -----Original Message-----
> From: Steve Grubb [mailto:sgrubb@redhat.com]
> Sent: Wednesday, January 28, 2015 8:46 PM
> To: linux-audit@redhat.com
> Cc: Viswanath, Logeswari P (MCOU OSTL)
> Subject: Re: Linux audit performance impact
>
> Hello,
>
> On Wednesday, January 28, 2015 02:57:58 PM Viswanath, Logeswari P wrote:
> > We want to know audit performance impact on RHEL and Suse linux to
> > help us evaluate linux audit as data source for our host based IDS.
> > When we ran our own performance test with a test audispd plugin, we
> > found if a system can perform 200000 open/close system calls per
> > second without auditing, system can perform only 3000 open/close
> > system calls auditing is enabled for open/close system call which is a
> > HUGE impact on the system performance. It would be great if anyone can
> help us answering the following questions.
> >
> >
> > 1) Is this performance impact expected? If yes, what is the reason
> > behind it and can we fix it?
>
> I'll leave this for the kernel guys to answer. That said, I think more
> detailed information might be helpful.
>
> If auditd is not started and events go to syslog, does the performance
> change?
> To do this audit=1 on boot line and auditctl -R /etc/rules.d/your.rules
>
> Logeswari=>System can perform 15000 open/close system calls per second
> which is better than earlier results.
>
> what rules do you have loaded?
>
> Logeswari=> # auditctl -l
> LIST_RULES: exit,always syscall=open,close
>
> What do you get when audit is enabled and no rules loaded?
>
> Logeswari=> Impact is there but not major.
>
> If you have other syscall rules loaded that are not open and openat or
> close, does the performance change? I suspect that if you trigger a rule,
> you are thrown onto the slow path. Open is perhaps the most lengthy because
> of multiple auxiliary records and path resolution. But we need data to tell.
>
> Logeswari=> Yes, there is an major impact. I enabled write system call and
> this rule is first in the set of rules along with open/close.
>
> That said, I know that the kernel audit path changed a couple years ago so
> it might be worthwhile to test against an old kernel to see if the change
> has affected performance.
>
> Logeswari=> We tested with kernel 2.6.32. Should we test with old/new
> kernel?
>
> -Steve
>
> > 2) Have anyone done any benchmarking for performance impact? If yes,
> > can you please share the numbers and also the steps/programs used the
> > run the same.
> >
> > 3) Help us validating the performance test we have done in our test
> > setup using the steps mentioned along with the results attached.
> >
> > Attached test program (loader.c) to invoke open and close system calls.
> > Attached idskerndsp is the audispd plugin program.
> > We used time command to determine how much time the system took to
> > complete
> > 50000 open/close system calls without (results attached
> > Without-auditing) and with auditing enabled on the system
> > (With-auditing-NOLOG-audispd-plugin
> > and With-auditing-RAW)
> >
> > System details:
> >
> > 1 CPU machine
> >
> > OS Version
> > RHEL 6.5
> >
> > Kernel Version
> > uname -r
> > 2.6.32-431.el6.x86_64
> >
> > Note: auditd was occupying 35% of CPU and was sleeping for most of the
> > time whereas kauditd was occupying 20% of the CPU.
> >
> > Thanks & Regards,
> > Logeswari.
>
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
>
--
Please Donate to www.wikipedia.org
[-- Attachment #1.2: Type: text/html, Size: 5084 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [RFC PATCH v3] audit: move the tree pruning to a dedicated thread
From: Paul Moore @ 2015-01-28 21:40 UTC (permalink / raw)
To: Imre Palik; +Cc: Palik, Imre, linux-audit, Matt Wilson, linux-kernel
In-Reply-To: <1421324870-15070-1-git-send-email-imrep.amz@gmail.com>
On Thursday, January 15, 2015 01:27:50 PM Imre Palik wrote:
> From: "Palik, Imre" <imrep@amazon.de>
>
> When file auditing is enabled, during a low memory situation, a memory
> allocation with __GFP_FS can lead to pruning the inode cache. Which can,
> in turn lead to audit_tree_freeing_mark() being called. This can call
> audit_schedule_prune(), that tries to fork a pruning thread, and
> waits until the thread is created. But forking needs memory, and the
> memory allocations there are done with __GFP_FS.
>
> So we are waiting merrily for some __GFP_FS memory allocations to complete,
> while holding some filesystem locks. This can take a while ...
>
> This patch creates a single thread for pruning the tree from
> audit_add_tree_rule(), and thus avoids the deadlock that the on-demand
> thread creation can cause.
>
> Reported-by: Matt Wilson <msw@amazon.com>
> Cc: Matt Wilson <msw@amazon.com>
> Signed-off-by: Imre Palik <imrep@amazon.de>
...
> diff --git a/kernel/audit_tree.c b/kernel/audit_tree.c
> index 2e0c974..4883b6e 100644
> --- a/kernel/audit_tree.c
> +++ b/kernel/audit_tree.c
> @@ -37,6 +37,7 @@ struct audit_chunk {
>
> static LIST_HEAD(tree_list);
> static LIST_HEAD(prune_list);
> +static struct task_struct *prune_thread;
>
> /*
> * One struct chunk is attached to each inode of interest.
> @@ -651,6 +652,55 @@ static int tag_mount(struct vfsmount *mnt, void *arg)
> return tag_chunk(mnt->mnt_root->d_inode, arg);
> }
>
> +/*
> + * That gets run when evict_chunk() ends up needing to kill audit_tree.
> + * Runs from a separate thread.
> + */
> +static int prune_tree_thread(void *unused)
> +{
> + for (;;) {
> + set_current_state(TASK_INTERRUPTIBLE);
> + if (list_empty(&prune_list))
> + schedule();
> + __set_current_state(TASK_RUNNING);
> +
> + mutex_lock(&audit_cmd_mutex);
> + mutex_lock(&audit_filter_mutex);
> +
> + while (!list_empty(&prune_list)) {
> + struct audit_tree *victim;
> +
> + victim = list_entry(prune_list.next,
> + struct audit_tree, list);
> + list_del_init(&victim->list);
> +
> + mutex_unlock(&audit_filter_mutex);
> +
> + prune_one(victim);
> +
> + mutex_lock(&audit_filter_mutex);
> + }
> +
> + mutex_unlock(&audit_filter_mutex);
> + mutex_unlock(&audit_cmd_mutex);
> + }
> + return 0;
> +}
> +
> +static int launch_prune_thread(void)
> +{
> + prune_thread = kthread_create(prune_tree_thread, NULL,
> + "audit_prune_tree");
> + if (IS_ERR(prune_thread)) {
> + pr_err("cannot start thread audit_prune_tree");
> + prune_thread = NULL;
> + return -ENOMEM;
> + } else {
> + wake_up_process(prune_thread);
> + return 0;
> + }
> +}
Before trying to create a new instance of prune_tree_thread, should we check
to see if one exists? I know you have a check for this in
audit_add_tree_rule() but I would rather it be in the function above to help
prevent accidental misuse in the future.
Also, how about we rename this to audit_launch_prune() so are naming is more
consistent, see audit_schedule_prune()?
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [PATCH v10 1/3] arm64: Add __NR_* definitions for compat syscalls
From: Arnd Bergmann @ 2015-01-28 21:35 UTC (permalink / raw)
To: linaro-kernel
Cc: rgb, Catalin Marinas, Timur Tabi, lkml, eparis, AKASHI Takahiro,
linux-audit, Al Viro, linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAOZdJXUhpmi0SM5izDYQnx8SHjWjqOFVduV0+boPw6+YCKP5+g@mail.gmail.com>
On Wednesday 28 January 2015 15:31:49 Timur Tabi wrote:
> On Fri, Jul 4, 2014 at 2:28 AM, AKASHI Takahiro
> <takahiro.akashi@linaro.org> wrote:
> > +#define __ARM_NR_COMPAT_BASE 0x0f0000
> > +#define __ARM_NR_compat_cacheflush (__ARM_NR_COMPAT_BASE+2)
> > +#define __ARM_NR_compat_set_tls (__ARM_NR_COMPAT_BASE+5)
>
> I know this patch is six months old, but I was wondering if anyone
> knows of any plans to make these syscalls available to 64-bit apps?
> We have a 32-bit app that uses __ARM_NR_compat_cacheflush, and we'd
> like to port that app to 64-bit. I'm just not sure how to start doing
> that, since there don't appear to be any 64-bit ARM-specific syscalls.
>
You can add architecture specific syscalls by using the 16 numbers following
__NR_arch_specific_syscall. Whether it makes sense to have a cacheflush
syscall on arm64, I have no idea.
I believe that we should not need a set_tls syscall though.
Arnd
^ permalink raw reply
* Re: [PATCH v10 1/3] arm64: Add __NR_* definitions for compat syscalls
From: Timur Tabi @ 2015-01-28 21:31 UTC (permalink / raw)
To: AKASHI Takahiro
Cc: linaro-kernel, rgb, Catalin Marinas, Will Deacon, lkml, eparis,
Deepak Saxena, Al Viro, linux-audit,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1404458911-8214-2-git-send-email-takahiro.akashi@linaro.org>
On Fri, Jul 4, 2014 at 2:28 AM, AKASHI Takahiro
<takahiro.akashi@linaro.org> wrote:
> +#define __ARM_NR_COMPAT_BASE 0x0f0000
> +#define __ARM_NR_compat_cacheflush (__ARM_NR_COMPAT_BASE+2)
> +#define __ARM_NR_compat_set_tls (__ARM_NR_COMPAT_BASE+5)
I know this patch is six months old, but I was wondering if anyone
knows of any plans to make these syscalls available to 64-bit apps?
We have a 32-bit app that uses __ARM_NR_compat_cacheflush, and we'd
like to port that app to 64-bit. I'm just not sure how to start doing
that, since there don't appear to be any 64-bit ARM-specific syscalls.
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
^ permalink raw reply
* RE: Linux audit performance impact
From: Viswanath, Logeswari P (MCOU OSTL) @ 2015-01-28 15:53 UTC (permalink / raw)
To: Satish Chandra Kilaru; +Cc: linux-audit@redhat.com
In-Reply-To: <CAAnai+W5WWJ1n=s1ojODH92AeU81jR44fqNHLz+d2zyyHkjG=A@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 2287 bytes --]
Thanks for the quick reply Satish.
From: Satish Chandra Kilaru [mailto:iam.kilaru@gmail.com]
Sent: Wednesday, January 28, 2015 8:49 PM
To: Viswanath, Logeswari P (MCOU OSTL)
Cc: linux-audit@redhat.com<mailto:linux-audit@redhat.com>
Subject: Re: Linux audit performance impact
Write your own program to receive audit events directly without using auditd...
That should be faster ....
Auditd will log the events to disk causing more I/o than u need...
On Wednesday, January 28, 2015, Viswanath, Logeswari P (MCOU OSTL) <logeswari.pv@hp.com<mailto:logeswari.pv@hp.com>> wrote:
Hi Steve,
I am Logeswari working for HP.
We want to know audit performance impact on RHEL and Suse linux to help us evaluate linux audit as data source for our host based IDS.
When we ran our own performance test with a test audispd plugin, we found if a system can perform 200000 open/close system calls per second without auditing, system can perform only 3000 open/close system calls auditing is enabled for open/close system call which is a HUGE impact on the system performance. It would be great if anyone can help us answering the following questions.
1) Is this performance impact expected? If yes, what is the reason behind it and can we fix it?
2) Have anyone done any benchmarking for performance impact? If yes, can you please share the numbers and also the steps/programs used the run the same.
3) Help us validating the performance test we have done in our test setup using the steps mentioned along with the results attached.
Attached test program (loader.c) to invoke open and close system calls.
Attached idskerndsp is the audispd plugin program.
We used time command to determine how much time the system took to complete 50000 open/close system calls without (results attached Without-auditing) and with auditing enabled on the system (With-auditing-NOLOG-audispd-plugin and With-auditing-RAW)
System details:
1 CPU machine
OS Version
RHEL 6.5
Kernel Version
uname –r
2.6.32-431.el6.x86_64
Note: auditd was occupying 35% of CPU and was sleeping for most of the time whereas kauditd was occupying 20% of the CPU.
Thanks & Regards,
Logeswari.
--
Please Donate to www.wikipedia.org<http://www.wikipedia.org>
[-- Attachment #1.2: Type: text/html, Size: 8416 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox