From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnaldo Carvalho de Melo Subject: Re: [PATCH bpf-next] bpf: emit audit messages upon successful prog load and unload Date: Fri, 5 Oct 2018 16:42:49 -0300 Message-ID: <20181005194249.GF20250@kernel.org> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jiri Olsa , Jesper Dangaard Brouer , Daniel Borkmann , ast@kernel.org, netdev@vger.kernel.org, Jiri Olsa To: Alexei Starovoitov Return-path: Received: from mail.kernel.org ([198.145.29.99]:57432 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728381AbeJFCnE (ORCPT ); Fri, 5 Oct 2018 22:43:04 -0400 Content-Disposition: inline In-Reply-To: <20181005184434.uphwrbqkfx2isbx4@ast-mbp.dhcp.thefacebook.com> Sender: netdev-owner@vger.kernel.org List-ID: Em Fri, Oct 05, 2018 at 11:44:35AM -0700, Alexei Starovoitov escreveu: > 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: > > > > 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. I think Jiri just said that one would have to run something all the time to get all the records, see below > 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. I think he is talking about the preexisting loaded BPF programs. We have the same problem with mmaps, where the perf tool will, with races, enumerate the existing mmaps as PERF_RECORD_MMAP synthesized from /proc/PIDS/smaps. There was talk in the past to ask the kernel to emit PERF_RECORD_MMAP into the ring buffer for those pre-existing entries, reducing a bit the races, but as there doesn't seem to have a good way of doing it, we continued with the synthesizing from procfs. Is there a way for us to synthesize those prog load/unload for preexisting loaded bpf objects? - Arnaldo