linux-kernel - Re: [RFC,v2,1/1] audit: speed up syscall rule match while exiting syscall

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:   Fri, 22 Jan 2021 12:02:35 -0500
From:   Paul Moore <paul@...l-moore.com>
To:     yang.yang29@....com.cn
Cc:     linux-audit@...hat.com, linux-kernel@...r.kernel.org
Subject: Re: [RFC,v2,1/1] audit: speed up syscall rule match while exiting syscall

On Thu, Jan 21, 2021 at 8:54 AM <yang.yang29@....com.cn> wrote:
>
> From 72f3ecde58edb03d76cb359607fef98c1663d481 Mon Sep 17 00:00:00 2001
> From: Yang Yang <yang.yang29@....com.cn>
> Date: Thu, 21 Jan 2021 21:05:04 +0800
> Subject: [PATCH] [RFC,v2,1/1] speed up syscall rule match while exiting syscall
>  audit_filter_syscall() traverses struct list_head audit_filter_list to find
>  out whether current syscall match one rule. This takes o(n), which is not
>  necessary, specially for user who add a very few syscall rules. On the other
>  hand, user may not much care about rule add/delete speed. So do o(n)
>  calculate at rule changing, and ease the burden of audit_filter_syscall().
>
>  Define audit_syscall[NR_syscalls], every element stands for one syscall.
>  audit_filter_syscall() checks audit_syscall[NR_syscalls].
>  audit_syscall[n] == 0 indicates no rule audit syscall n, do a quick exit.
>  audit_syscall[n] > 0 indicates at least one rule audit syscall n.
>  audit_syscall[n] update when syscall rule changes.
>
> Signed-off-by: Yang Yang <yang.yang29@....com.cn>
> ---
>  include/linux/audit.h |  2 ++
>  kernel/audit.c        |  4 ++++
>  kernel/auditfilter.c  | 30 ++++++++++++++++++++++++++++++
>  kernel/auditsc.c      |  5 ++++-
>  4 files changed, 40 insertions(+), 1 deletion(-)

...

> diff --git a/kernel/auditfilter.c b/kernel/auditfilter.c
> index 333b3bc..9d3e703 100644
> --- a/kernel/auditfilter.c
> +++ b/kernel/auditfilter.c
> @@ -926,6 +926,28 @@ static struct audit_entry *audit_find_rule(struct audit_entry *entry,
>  static u64 prio_low = ~0ULL/2;
>  static u64 prio_high = ~0ULL/2 - 1;
>
> +#ifdef CONFIG_AUDITSYSCALL
> +static inline void update_auditing_syscall(struct audit_krule rule, bool add)
> +{
> +    int i;
> +
> +    /* syscall rule with type AUDIT_FILTER_EXIT */
> +    if (rule.listnr == AUDIT_FILTER_EXIT && !rule.watch && !rule.tree) {
> +        for (i = 0; i < NR_syscalls; i++) {
> +            /* whether this rule include one syscall */
> +            if (unlikely(audit_in_mask(&rule, i))) {
> +                if (add == true)
> +                    auditing_syscall[i]++;
> +                else
> +                    auditing_syscall[i]--;
> +            }
> +        }
> +    }
> +
> +    return;
> +}
> +#endif
> +
>  /* Add rule to given filterlist if not a duplicate. */
>  static inline int audit_add_rule(struct audit_entry *entry)
>  {
> @@ -957,6 +979,10 @@ static inline int audit_add_rule(struct audit_entry *entry)
>                 return err;
>         }
>
> +#ifdef CONFIG_AUDITSYSCALL
> +    update_auditing_syscall(entry->rule, true);
> +#endif

I'm going to reply to your other email where we are discussing the
performance of this patch, but I wanted to make one comment about the
approach you've taken with the update_auditing_syscall() here.

First, naming things is hard, but the chosen name is not a good one in
my opinion.  Something like audit_rule_syscall_mask_update() would
probably be a better fit.

Second, in order to minimize preprocessor clutter, it is better to use
the following pattern:

  #ifdef CONFIG_FOO
  int func(int arg)
  {
    /* important stuff */
  }
  #else
  int func(int arg)
  {
    return 0; /* appropriate return value */
  }
  #endif

There are probably a few other comments on this patch, but I want us
to discuss the performance impacts of this first as I'm not convinced
this is a solution we want upstream.

-- 
paul moore
www.paul-moore.com