Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3855622imu; Mon, 28 Jan 2019 12:05:26 -0800 (PST) X-Google-Smtp-Source: ALg8bN4N/DgTaVRoNQkmXdJHhiavL5INQIuU887NnNAFqNGldBPnU67qvl1aVnGZbumYxkW5Vl6B X-Received: by 2002:a17:902:b48b:: with SMTP id y11mr22227871plr.200.1548705926396; Mon, 28 Jan 2019 12:05:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548705926; cv=none; d=google.com; s=arc-20160816; b=jTCibGf24lGb1tHcFLwH2KKZuhqJWviiQpybqihjDz5+YEN6ohctPvRF/k5uej1osp Q+7u1fnXyafi/iDzEmjnRJrq3Aq+8t+gNuJrQ1RRw//yDCz5kb0xiWvzBKGLMlkF7Hx8 fOUW2GsgjEBKz+AZLaXCn3lUfp/ErCO05zTKJuFOuoINgohBUiGkuNg8jke+yvdVtdSc g/XCfk/6EjrBu+qpq90aIA/4zdzYSrk6HDmhUBneanYjUhlaa8A8PzWA8lGyxqAXuCPE flUXe5ov4pPxqhvFmcrBZRk4FXqqhG6OEkpNXTS03dHlqflre2Ocb33R8qIonRvxDMQN Mivw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=N7Q/bhSOarDjBUn+VjxXi1ojKmywdmKrwnr7t4YR2Eo=; b=Lrytlj4nZJePuZWnVNmaJDIm/+r1WU7DiixlUvTh2jjaaBQYeqcnDff0/X5bj6vba+ vALmI23uIr9GjUW1pXc/Lqv7VWWCED4x88AA5EAalxzWmpWJ2/XnZauPUu/l+x9X9i0m VK3cd16JzzN94MEMYi2TEe3c5AVKm/lt8HVFezOc21ejI2YbejoGoY/vN3oYtvWlJtS/ VQ8orXto/B2AJ7ioP5WAbstlxHLWFf9u8pM++QB6bxx0ye/JQPbFtjTHuzyfluY5zjT1 /IzSpeS2qZ5UO0MHbwudWQJV5/pbpMEnWwu8O/K+MZ4KNZR6k/txxEjyQ/4r+R34Rlb4 CoqA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 126si32826667pff.77.2019.01.28.12.05.10; Mon, 28 Jan 2019 12:05:26 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727381AbfA1UD1 (ORCPT + 99 others); Mon, 28 Jan 2019 15:03:27 -0500 Received: from mx1.redhat.com ([209.132.183.28]:49594 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726661AbfA1UD1 (ORCPT ); Mon, 28 Jan 2019 15:03:27 -0500 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B593A88E70; Mon, 28 Jan 2019 20:03:26 +0000 (UTC) Received: from ivy-bridge (ovpn-204-44.brq.redhat.com [10.40.204.44]) by smtp.corp.redhat.com (Postfix) with ESMTP id 983071001943; Mon, 28 Jan 2019 20:03:21 +0000 (UTC) Date: Mon, 28 Jan 2019 21:03:28 +0100 From: Steve Grubb To: Paul Moore Cc: "Sverdlin, Alexander (Nokia - DE/Ulm)" , Daniel Borkmann , Greg Kroah-Hartman , "linux-kernel@vger.kernel.org" , Alexei Starovoitov , "linux-audit@redhat.com" , Richard Guy Briggs Subject: Re: [PATCH] audit: always enable syscall auditing when supported and audit is enabled Message-ID: <20190128210328.64b7719c@ivy-bridge> In-Reply-To: References: <20151208164237.15736.42955.stgit@localhost> <5490ae28-251b-bfda-38a6-5be201a4a8d8@nokia.com> <4fb6def1-a1d9-8af0-394c-f92224884d18@nokia.com> <8bf5d613-9b27-381d-283b-c8892483f424@nokia.com> Organization: Red Hat MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Mon, 28 Jan 2019 20:03:26 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 28 Jan 2019 11:26:51 -0500 Paul Moore wrote: > On Mon, Jan 28, 2019 at 10:38 AM Sverdlin, Alexander (Nokia - DE/Ulm) > wrote: > > Hello Paul, > > > > On 28/01/2019 15:52, Paul Moore wrote: > > >>>>> time also enables syscall auditing; this patch simplifies the > > >>>>> Kconfig menus by removing the option to disable syscall > > >>>>> auditing when audit is selected and the target arch supports > > >>>>> it. > > >>>>> > > >>>>> Signed-off-by: Paul Moore > > >>>> this patch is responsible for massive performance degradation > > >>>> for those who used only CONFIG_SECURITY_APPARMOR. > > >>>> > > >>>> And the numbers are, take the following test for instance: > > >>>> > > >>>> dd if=/dev/zero of=/dev/null count=2M > > >>>> > > >>>> ARM64: 500MB/s -> 350MB/s > > >>>> ARM: 400MB/s -> 300MB/s > > >>> Hi there. > > >>> > > >>> Out of curiosity, what kernel/distribution are you running, or > > >>> is this a custom kernel compile? Can you also share the output > > >>> of 'auditctl > > >> This test was carried out with Linux 4.9. Custom built. > > > I suspected that was the case, thanks. > > > > > >>> -l' from your system? The general approach taken by everyone to > > >>> turn-off the per-syscall audit overhead is to add the "-a > > >>> never,task" rule to their audit configuration: > > >>> > > >>> # auditctl -a never,task > > >>> > > >>> If you are using Fedora/CentOS/RHEL, or a similarly configured > > >>> system, > > >> This is an embedded distribution. We are not using auditctl or > > >> any other audit-related user-space packages. > > >> > > >>> you can find this configuration in the /etc/audit/audit.rules > > >>> file (be warned, that file is automatically generated based on > > >>> /etc/audit/rules.d). > > >> I suppose in this case rule list must be empty. Is there a way > > >> to check this without extra user-space packages? > > > Yes, unless you are loading rules through some other method I > > > would expect that your audit rule list is empty. > > > > > > I'm not aware of any other tools besides auditctl to load audit > > > rules into the kernel, although I haven't ever had a need for > > > another tool so I haven't looked very hard. If you didn't want > > > to bring auditctl into your distribution, I expect it would be a > > > rather trivial task to create a small tool to load a single "-a > > > never,task" into the kernel. > > > > I've done a quick test on my x86_64 PC and got the following > > results: > > ... > > > Which brings me to an idea, that the subject patch should have been > > accompanied by a default "never,task" rule inside the kernel, > > otherwise you require an extra user-space package (audit) just to > > bring Linux 4.5+ to 4.4 performance levels. > > [NOTE: I dropped pmoore@redhat.com from the To/CC line, I left Red Hat > for greener pastures several months ago.] > > Well, it generally hasn't been an issue as 1) most people that enable > audit also enable syscall auditing and 2) most people that enable > audit have some sort of audit userspace tools to work with the audit > logs (and configure audit if necessary). I don't want to diminish > your report, but this change was made several years ago and we really > haven't heard of many issues surrounding the change. If we can ever > get all of the different arches to support syscall auditing, I'd love > to get rid of the syscall auditing Kconfig knob entirely. > > If you wanted to put together a patch that added a single "-a > never,task" rule on boot I could get behind that, just make it default > to off. That will make processes unauditable for everyone. That's how it gets a speedup is not entering into the audit machinery. I suppose its possible that people may want MAC hardwired events but no syscall events. I don't know if there are other kconfig audit options. but maybe getting it down to audit enabled and syscall auditing as the only choices is probably the most performant. -Steve