Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp677342pxb; Wed, 27 Jan 2021 18:54:34 -0800 (PST) X-Google-Smtp-Source: ABdhPJxuxC68PH+tmanlSSNWvFBId9UdxrwyHfOyU0hFrqIbDJlkQLtfb1YqYUISWGdv/Rvp9ATo X-Received: by 2002:a17:906:6087:: with SMTP id t7mr9384048ejj.90.1611802474076; Wed, 27 Jan 2021 18:54:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611802474; cv=none; d=google.com; s=arc-20160816; b=dZWCjepMRwf2OvOhPBAvarzq8sx6ZU/tS449GLSVuLi+CL1rMLL01pbGxTTpTdl5u+ +btmAqvAg0q8yiKT4lwZ+yMwtb5ECx30+7VkMjqGB8+FMQEhc7CDFCtXsMJmSa6ViWQy qkhp1UFZeQ8a4y6FbpIKzZZOrxb+kz7JNbodboXjC4LARiZPMZum23LtpZx3yosKCE7M ngDGICOI1a7EMKiQL0DxvriJhxEcy/hkaitMb6jAY5V9w4SRJuYdQYmPuVZq6GoVpjR7 6x6pjavq6gkPb4pUBQw8wRfdKSIK8tbMST70OgD9H3qCU96hqReawHzpIqq/z7GCq2Wy ASAg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=SpQaqfgxd7HJasSj0lTbCtNGSUTspubqoBTb1LMXVRM=; b=N+hvWKYSeNrbNgVgHBk4WEZm0YhqTV6sLZmmItTaqFVk8zAU85jGYV9WM4AQwmLCx1 To6bIYI8IZZjyz52ut4yfUGJAMTL8y6g2f9E5b2A54XgcqLpmMHfaiofa6f9T0fLLsZu lnIIvgPMjMm1uROYI5h9cgsqG9WLl90ILr7o43hDlfWFI+QGZNHL/VAsEfsTsf0gjLZq 9z8nZsfkBU/qADQ2KBNx5s5SLIcg8AVy0gYvdd8PzIUntM7uZR97q4/m/fdsk+NgjRL7 IvoVD+UNwHE6/ba7rzUobmHt+7UXKV7rVEk+pOrJOQsKagNqSiMoegXf2HeAMKb+mNM8 nxRw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@paul-moore-com.20150623.gappssmtp.com header.s=20150623 header.b=NnGpVeSq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y9si44859edm.453.2021.01.27.18.54.09; Wed, 27 Jan 2021 18:54:34 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@paul-moore-com.20150623.gappssmtp.com header.s=20150623 header.b=NnGpVeSq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231178AbhA1Cwn (ORCPT + 99 others); Wed, 27 Jan 2021 21:52:43 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34804 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229747AbhA1Cwk (ORCPT ); Wed, 27 Jan 2021 21:52:40 -0500 Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E529BC061573 for ; Wed, 27 Jan 2021 18:51:59 -0800 (PST) Received: by mail-ed1-x534.google.com with SMTP id a14so4895942edu.7 for ; Wed, 27 Jan 2021 18:51:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paul-moore-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SpQaqfgxd7HJasSj0lTbCtNGSUTspubqoBTb1LMXVRM=; b=NnGpVeSqtPgrJgZIm930ZFHJoqoTXILyr0S82daUWTGBNJaaiM327+reTyu7uBvBmj Z8xjmu2Fy/SAUf2zI2rW4yt1AB9R4gmZQ5vKMqg+7Z7kiDhxsMEEh13MGIfSTgocfCiK FJ2llM/eYKEK++Bc7K7k9DiJov12Fptz89vTPOf86EaBD33OGm/CgsNjkypRCo8vYY+C c6zzT6VfEiJSk/dcd6pW8/XqNS4zZiYtLT9mL8FkH6wkoF9AxWEPLaU6GmXzW+4dggWh t+Fmk6/m3Yi6bI0WwKHQesQbEsviHMjbPDplLIuiSikTp6UtQ/3XYWNiNsOo1JTHBhjW GX5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SpQaqfgxd7HJasSj0lTbCtNGSUTspubqoBTb1LMXVRM=; b=tTCDLoZ9zD7muuOPRS+p3FaJtpVU773yn1O0GH8Z2pQD7D+NJ4ttgsA/dbWvi8U55V rjnAOGy3kbwyweb6iFnKA1eig3XCto3POEQaQkC/ThSJGSD3R6imhETJC6c9o0CSj0ov 23zrQsVibCqp5GMwUqomnTpmfhg7YEkXhmoexmekcojs7OJBLsEBkopBGHHO95oI5OF5 EuxHxstIRGmtOT5/M6HdOns8o24K2UvPy5LTXvEqFfQRAvxP/lN9Iv3GCi/kdpuuD+g5 i/imzFWP29hmiielkdUJJgGddkm9ZwwnYUw7XdyctHZ9SHy7LAtRvigb/Fep8Sfbk4xM azSw== X-Gm-Message-State: AOAM5333HUzD8IEK9gp52PXPNb7G2gm2z/MXqKhTzyaVV1hzKR6jBN1j uSJ21WJEEXFVy4e4V5Bue0+P3+jDdHojiYzIjmBXEteclVWIxnI= X-Received: by 2002:a05:6402:1bcd:: with SMTP id ch13mr11572381edb.31.1611802318522; Wed, 27 Jan 2021 18:51:58 -0800 (PST) MIME-Version: 1.0 References: <202101242104019221924@zte.com.cn> In-Reply-To: <202101242104019221924@zte.com.cn> From: Paul Moore Date: Wed, 27 Jan 2021 21:51:47 -0500 Message-ID: Subject: Re: [RFC,v3,1/1] audit: speed up syscall rule filtering To: yang.yang29@zte.com.cn Cc: linux-audit@redhat.com, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Jan 24, 2021 at 8:04 AM wrote: > > From 85b3eccf7f12b091b78cc5ba8abfaf759cf0334e Mon Sep 17 00:00:00 2001 > From: Yang Yang > Date: Sun, 24 Jan 2021 20:40:50 +0800 > Subject: [PATCH] audit: speed up syscall rule filtering > 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) > calculates when rule changes, and ease the burden of audit_filter_syscall(). > > Define audit_rule_syscall_mask[NR_syscalls], every element stands for > one syscall.audit_rule_syscall_mask[n] == 0 indicates no rule cares about > syscall n, so we can avoid unnecessary calling audit_filter_syscall(). > audit_rule_syscall_mask[n] > 0 indicates at least one rule cares about > syscall n, then calls audit_filter_syscall(). Update > audit_rule_syscall_mask[n] when syscall rule changes. > > Signed-off-by: Yang Yang > --- > include/linux/audit.h | 3 +++ > kernel/auditfilter.c | 4 ++++ > kernel/auditsc.c | 36 ++++++++++++++++++++++++++++++++---- > 3 files changed, 39 insertions(+), 4 deletions(-) ... > diff --git a/kernel/auditsc.c b/kernel/auditsc.c > index ce8c9e2..1b8ff4e 100644 > --- a/kernel/auditsc.c > +++ b/kernel/auditsc.c > @@ -1627,8 +1653,9 @@ void __audit_free(struct task_struct *tsk) > context->return_valid = AUDITSC_INVALID; > context->return_code = 0; > > - audit_filter_syscall(tsk, context, > - &audit_filter_list[AUDIT_FILTER_EXIT]); > + if (unlikely(audit_rule_syscall_mask[context->major])) > + audit_filter_syscall(tsk, context, > + &audit_filter_list[AUDIT_FILTER_EXIT]); > audit_filter_inodes(tsk, context); > if (context->current_state == AUDIT_RECORD_CONTEXT) > audit_log_exit(); > @@ -1735,8 +1762,9 @@ void __audit_syscall_exit(int success, long return_code) > else > context->return_code = return_code; > > - audit_filter_syscall(current, context, > - &audit_filter_list[AUDIT_FILTER_EXIT]); > + if (unlikely(audit_rule_syscall_mask[context->major])) > + audit_filter_syscall(current, context, > + &audit_filter_list[AUDIT_FILTER_EXIT]); > audit_filter_inodes(current, context); > if (context->current_state == AUDIT_RECORD_CONTEXT) > audit_log_exit(); Looking at this revision I believe I may not have been as clear as I should have been with my last suggestion. Let me try to do better here. Thus far I'm not very happy with the audit_rule_syscall_mask[] additions; it looks both wasteful and inelegant to me at the moment. I would much rather see if we can improve the existing code by fixing inefficiencies in how we handle the rule filtering. This is why my previous comments suggested looking at the audit_filter_syscall() and audit_filter_inodes() calls in __audit_free() and __audit_syscall_exit(), the latter of course being more important due to its frequency. In both cases an audit_filter_inode() AUDIT_RECORD_CONTEXT decision takes precedence over any audit_filter_syscall() decision due to the code being structured as so: audit_filter_syscall(...); audit_filter_inodes(...); if (state == AUDIT_RECORD_CONTEXT) audit_log_exit(); ... my suggestion is to investigate what performance benefits might be had by leveraging this precedence, for example: audit_filter_inodes(...); if (state != AUDIT_RECORD_CONTEXT) audit_filter_syscall(...); if (state == AUDIT_RECORD_CONTEXT) audit_log_exit(); ... of course I would expect the performance to be roughly the same when there is no matching rule, but I think there would be a performance when in those cases where a watched inode triggers an audit rule. Beyond that, there is probably work we could do to combine some aspects of audit_filter_syscall() and audit_filter_inodes() to eliminate some redundancy, e.g. reduce the number of audit_in_mask() calls. Actually looking a bit closer there are a number of improvements that could likely be made, some might have some performance impacts. Let me know if you are going to pursue the suggestion above about reordering the audit_filter_*() functions as I'll hold off on the other changes. -- paul moore www.paul-moore.com