[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrWhZ5ermtpfMt6UdLAC0M9mv7L_TsTfErGStPxznz-AWg@mail.gmail.com>
Date: Wed, 7 Mar 2018 16:40:16 +0000
From: Andy Lutomirski <luto@...nel.org>
To: Jiri Kosina <jikos@...nel.org>, Oleg Nesterov <oleg@...hat.com>
Cc: Paul Moore <paul@...l-moore.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Michal Hocko <mhocko@...e.com>,
Andy Lutomirski <luto@...nel.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] audit: set TIF_AUDIT_SYSCALL only if audit filter has
been populated
On Wed, Mar 7, 2018 at 10:32 AM, Jiri Kosina <jikos@...nel.org> wrote:
> From: Jiri Kosina <jkosina@...e.cz>
>
> There is no point going through all the audit slow path syscall entry/exit
> in case the audit daemon is running, but hasn't populated the audit filter
> with any rules whatsoever.
>
> Only set TIF_AUDIT_SYSCALL in case the number of populated audit rules is
> non-zero.
>
> Originally-by: Andy Lutomirski <luto@...nel.org>
> Signed-off-by: Jiri Kosina <jkosina@...e.cz>
> ---
>
> This is basically resurrection / rebase of patch Andi Lutomirski sent some
> time back in 2014 or so.
>
> Andi, is there any reason this hasn't been pursued further? I think we
> still want to get some of the slow path performance back.
>
Wow, this was a long time ago. From memory and a bit of email diving,
there are two reasons.
1. The probably was partially solved (by Oleg, IIRC) by making
auditctl -a task,never cause newly spawned tasks to not suck. Yes,
it's a very partial solution. After considerable nagging, I got Fedora
to default to -a task,never.
2. This patch, as is, may be a bit problematic. In particular, if one
task changes the audit rules while another task is in the middle of
the syscall, then it's too late to audit that syscall correctly. This
could be seen as a bug or it could be seen as being just fine.
--Andy
Powered by blists - more mailing lists