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 <dan...@iogearbox.net> > > wrote: > > > > > On 10/04/2018 08:39 PM, Jesper Dangaard Brouer wrote: > > > > On Thu, 4 Oct 2018 10:11:43 -0700 Alexei Starovoitov > > > > <alexei.starovoi...@gmail.com> 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/
cool, could you please CC me if there's another version of that patchset? > > > > > > 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 jirka > Also auditd has to be changed to support retrieving prog related info (like > license) > via sys_bpf system call when it sees prog_id. > Since it has to change it can just as easily use perf ring buffer > to receive notifications. > So we solve notification problem once and all user space tools can use it. >
