All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Paris <eparis@redhat.com>
To: Michael Neuling <mikey@neuling.org>
Cc: linux-audit@redhat.com, linux-kernel@vger.kernel.org,
	Al Viro <viro@zeniv.linux.org.uk>,
	anton@samba.org
Subject: Re: [PATCH] audit: speedup for syscalls when auditing is disabled
Date: Mon, 23 Aug 2010 13:56:17 -0400	[thread overview]
Message-ID: <1282586177.2681.43.camel@localhost.localdomain> (raw)
In-Reply-To: <29151.1282270393@neuling.org>

On Fri, 2010-08-20 at 12:13 +1000, Michael Neuling wrote:
> We found that when auditing is disabled using "auditctl -D", that
> there's still a significant overhead when doing syscalls.  This overhead
> is not present when a single never rule is inserted using "auditctl -a
> task,never".  
> 
> Using Anton's null syscall microbenchmark from
> http://ozlabs.org/~anton/junkcode/null_syscall.c we currently have on a
> powerpc machine:
> 
>   # auditctl -D
>   No rules
>   # ./null_syscall
> 	  null_syscall:     739.03 cycles     100.00%
>   # auditctl -a task,never
>   # ./null_syscall
> 	  null_syscall:     204.63 cycles     100.00%
> 
> This doesn't seem right, as we'd hope that auditing would have the same
> minimal impact when disabled via -D as when we have a single never rule.
> 
> The patch below creates a fast path when initialising a task.  If the
> rules list for tasks is empty (the disabled -D option), we mark auditing
> as disabled for this task.  
> 
> When this is applied, our null syscall benchmark improves in the
> disabled case to match the single never rule case.
> 
>   # auditctl -D
>   No rules
>   # ./null_syscall
> 	  null_syscall:     204.62 cycles     100.00%
>   # auditctl -a task,never
>   # ./null_syscall
> 	  null_syscall:     204.63 cycles     100.00%
> 
> Reported-by: Anton Blanchard <anton@samba.org>
> Signed-off-by: Michael Neuling <mikey@neuling.org>
> ---
> I'm not familiar with the auditing code/infrastructure so I may have
> misunderstood something here
> 
> diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> index 1b31c13..1cd6ec7 100644
> --- a/kernel/auditsc.c
> +++ b/kernel/auditsc.c
> @@ -666,6 +666,11 @@ static enum audit_state audit_filter_task(struct task_struct *tsk, char **key)
>  	enum audit_state   state;
>  
>  	rcu_read_lock();
> +	/* Fast path.  If the list is empty, disable auditing */
> +	if (list_empty(&audit_filter_list[AUDIT_FILTER_TASK])) {
> +		rcu_read_unlock();
> +		return AUDIT_DISABLED;
> +	}
>  	list_for_each_entry_rcu(e, &audit_filter_list[AUDIT_FILTER_TASK], list) {
>  		if (audit_filter_rules(tsk, &e->rule, NULL, NULL, &state)) {
>  			if (state == AUDIT_RECORD_CONTEXT)

I don't think this works at all.  I don't see how syscall audit'ing can
work.  What if I have nothing in the AUDIT_FILTER_TASK list but I want
to audit all 'open(2)' syscalls?  This patch is going to leave the task
in the DISABLED state and we won't ever be able to match on the syscall
rules.


I wonder if you could get much back, in terms of performance, by moving
the
         context->dummy = !audit_n_rules;
line to the top and just returning if context->dummy == 1;

I'll play a bit, but I thought that was supposed to be a safe thing to
do....



  reply	other threads:[~2010-08-23 17:56 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-20  2:13 [PATCH] audit: speedup for syscalls when auditing is disabled Michael Neuling
2010-08-23 17:56 ` Eric Paris [this message]
2010-08-24  2:11   ` Michael Neuling
2010-08-24  3:43     ` Eric Paris
2010-08-24  5:56       ` Michael Neuling
2010-08-24  5:56       ` Michael Neuling
2010-08-24 20:06         ` Eric Paris
2010-08-24 20:06           ` Eric Paris
2010-08-24 15:14       ` Miloslav Trmac
2010-08-24 15:17         ` Eric Paris
2010-08-25  3:11       ` Michael Neuling
2010-08-25 11:59         ` Eric Paris
2010-08-26  3:34           ` Anton Blanchard
2010-08-27 17:49             ` Eric Paris
2010-08-27 17:49               ` Eric Paris
2010-08-24  2:16   ` Anton Blanchard
2010-08-24  3:51     ` Eric Paris

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1282586177.2681.43.camel@localhost.localdomain \
    --to=eparis@redhat.com \
    --cc=anton@samba.org \
    --cc=linux-audit@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mikey@neuling.org \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.