From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jesper Dangaard Brouer Subject: Re: [PATCH bpf-next] bpf: emit audit messages upon successful prog load and unload Date: Sun, 7 Oct 2018 18:19:39 +0200 Message-ID: <20181007181939.38742d42@redhat.com> References: <20181004135038.2876-1-daniel@iogearbox.net> <20181004171141.tsggdqnh65x2si4d@ast-mbp.dhcp.thefacebook.com> <20181004203949.388e9a38@redhat.com> <36266cde-3aa0-aeb4-9888-5e3f0e4d1911@iogearbox.net> <20181004222231.2edd5add@redhat.com> <20181004221013.o3c5junwfyaasuxo@ast-mbp.dhcp.thefacebook.com> <20181005061409.GA15872@krava> <20181005184434.uphwrbqkfx2isbx4@ast-mbp.dhcp.thefacebook.com> <20181005220522.GA16292@krava> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Alexei Starovoitov , Daniel Borkmann , ast@kernel.org, netdev@vger.kernel.org, Jiri Olsa , acme@kernel.org, brouer@redhat.com, Richard Guy Briggs To: Jiri Olsa Return-path: Received: from mx1.redhat.com ([209.132.183.28]:60992 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726616AbeJGX1f (ORCPT ); Sun, 7 Oct 2018 19:27:35 -0400 In-Reply-To: <20181005220522.GA16292@krava> Sender: netdev-owner@vger.kernel.org List-ID: On Sat, 6 Oct 2018 00:05:22 +0200 Jiri Olsa wrote: > On Fri, Oct 05, 2018 at 11:44:35AM -0700, Alexei Starovoitov wrote: > > On Fri, Oct 05, 2018 at 08:14:09AM +0200, Jiri Olsa wrote: > > > On Thu, Oct 04, 2018 at 03:10:15PM -0700, Alexei Starovoitov wrote: > > > > On Thu, Oct 04, 2018 at 10:22:31PM +0200, Jesper Dangaard Brouer wrote: > > > > > On Thu, 4 Oct 2018 21:41:17 +0200 Daniel Borkmann wrote: > > > > > > > > > > > On 10/04/2018 08:39 PM, Jesper Dangaard Brouer wrote: > > > > > > > On Thu, 4 Oct 2018 10:11:43 -0700 Alexei Starovoitov wrote: > > > > > > >> On Thu, Oct 04, 2018 at 03:50:38PM +0200, Daniel Borkmann wrote: > > > > > [...] > > > > > > >> > > > > > > >> If the purpose of the patch is to give user space visibility into > > > > > > >> bpf prog load/unload as a notification, then I completely agree that > > > > > > >> some notification mechanism is necessary. > > > > > > > > > > > > Yeah, I did only regard it as only that, nothing more. Some means > > > > > > of timeline and notification that can be kept in a record in user > > > > > > space and later retrieved e.g. for introspection on what has been > > > > > > loaded. > > > > > > > > > > > > >> I've started working on such mechanism via perf ring buffer which is > > > > > > >> the fastest mechanism we have in the kernel so far. > > > > > > >> See long discussion here: https://patchwork.ozlabs.org/patch/971970/ > > > [...] > > > > > > > > > > > > That one is definitely needed in any case to resolve the kallsyms > > > > > > limitations, and it does have overlap in that in either case we > > > > > > want to look at past BPF programs that have been unloaded in the > > > > > > meantime, so I don't have a strong preference either way, and the > > > > > > former is needed in any case. Though thought was that audit might > > > > > > be an option for those not running profiling daemons 24/7, but > > > > > > presumably bpftool could be extended to record these events as > > > > > > well if we don't want to reuse audit infra. > > > > > > > > > > Yes, exactly, I don't want to run a profiling daemon 24/7 to record > > > > > these events. I do acknowledge that this perf event is relevant, > > > > > especially for catching the kernel symbols (I need that myself), but it > > > > > does not cover my use-case. > > > > > > > > > > My use-case is to 24/7 collect and keep records in userspace, and have a > > > > > timeline of these notifications, for later retrieval. The idea is that > > > > > our support engineers can look at these records when troubleshooting > > > > > the system. And the plan is also to collect these records as part of > > > > > our sosreport tool, which is part of the support case. > > > > > > > > I don't think you're implying that prog load/unload should be spamming dmesg > > > > and auditd not even running... > > > > > > I think the problem Jesper implied is that in order to collect > > > those logs you'll need perf tool running all the time.. which > > > it's not equipped for yet > > > > I'm not proposing to run 'perf' binary all the time. > > Setting up perf ring buffer just for these new bpf prog load/unload events > > and epolling it is simple enough to do from any application including auditd. > > selftests/bpf/ do it for bpf output events. > > ok, did not think about the possibility to teach auditd talk to perf, > time to get that tool evsel/evlist/rb library ready ;-) Interesting, I also didn't consider teaching auditd to gets its 'bpf' events from a separate perf ring-buffer, that might work. I do wonder how the audit people will take this suggestion. -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer