All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: Daniel Borkmann <daniel@iogearbox.net>
Cc: ast@kernel.org, netdev@vger.kernel.org, brouer@redhat.com,
	Jiri Olsa <jolsa@kernel.org>,
	acme@kernel.org
Subject: Re: [PATCH bpf-next] bpf: emit audit messages upon successful prog load and unload
Date: Thu, 4 Oct 2018 10:11:43 -0700	[thread overview]
Message-ID: <20181004171141.tsggdqnh65x2si4d@ast-mbp.dhcp.thefacebook.com> (raw)
In-Reply-To: <20181004135038.2876-1-daniel@iogearbox.net>

On Thu, Oct 04, 2018 at 03:50:38PM +0200, Daniel Borkmann wrote:
> Allow for audit messages to be emitted upon BPF program load and
> unload for having a timeline of events. The load itself is in
> syscall context, so additional info about the process initiating
> the BPF prog creation can be logged and later directly correlated
> to the unload event.
> 
> The only info really needed from BPF side is the globally unique
> prog ID where then audit user space tooling can query / dump all
> info needed about the specific BPF program right upon load event
> and enrich the record, thus these changes needed here can be kept
> small and non-intrusive to the core.

The above description is correct, but the commit log doesn't explain
_why_ this audit logging is needed and _why_ for load/unload.
My understanding of audit subsystem that it's very heavy weight
and absolutely not suitable for high frequency events.
Audit suppose to log the events that alter security of the system.
I don't see how loading/unloading bpf program influences security
at the time of the load.
The actions that program may take later (like dropping a packet
in XDP due to firewalling reasons) can be considered security
related, but not at the time of prog load.

Classic bpf for sockets and seccomp has been around for long time,
but seccomp audit messages don't trigger on bpf load/unload,
but rather on events like killing a process due to seccomp bpf return value.

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.
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/

Essentially we need perf binary to see bpf prog load/unload events with
single argument bpf_prog_id to be able to do its job.

I think from bpf kernel side there should be only one mechanism for user space
notifications and perf ring buffer fits the best, since amount
of load/unload in the system can be very large.
Anything but ring buffer will likely choke under volume of events.
Audit is not suitable for such notifications.

If in the future we have something other than seccomp killing
task via bpf return values, such code points would be good candidates
for audit logging.

  reply	other threads:[~2018-10-05  0:05 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-04 13:50 [PATCH bpf-next] bpf: emit audit messages upon successful prog load and unload Daniel Borkmann
2018-10-04 17:11 ` Alexei Starovoitov [this message]
2018-10-04 18:39   ` Jesper Dangaard Brouer
2018-10-04 19:41     ` Daniel Borkmann
2018-10-04 20:22       ` Jesper Dangaard Brouer
2018-10-04 22:10         ` Alexei Starovoitov
2018-10-05  6:14           ` Jiri Olsa
2018-10-05 18:44             ` Alexei Starovoitov
2018-10-05 19:42               ` Arnaldo Carvalho de Melo
2018-10-05 20:26                 ` Alexei Starovoitov
2018-10-05 22:05               ` Jiri Olsa
2018-10-07 16:19                 ` Jesper Dangaard Brouer
2018-10-18 19:53                   ` Richard Guy Briggs
2018-10-18 22:09                     ` Steve Grubb
2018-10-08 11:57           ` Jiri Olsa
2018-10-10 19:53             ` Alexei Starovoitov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181004171141.tsggdqnh65x2si4d@ast-mbp.dhcp.thefacebook.com \
    --to=alexei.starovoitov@gmail.com \
    --cc=acme@kernel.org \
    --cc=ast@kernel.org \
    --cc=brouer@redhat.com \
    --cc=daniel@iogearbox.net \
    --cc=jolsa@kernel.org \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.