On Mon, Dec 02, 2019 at 11:57:22PM -0500, Steve Grubb wrote:

On Monday, December 2, 2019 6:00:14 PM EST Paul Moore wrote:

quoted

On Thu, Nov 28, 2019 at 4:16 AM Jiri Olsa [off-list ref] wrote:

quoted

From: Daniel Borkmann <daniel@iogearbox.net>

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.

SNIP

quoted

I think you would probably also want to check the results of
audit_dummy_context() here as well, see all the various audit_XXX()
functions in include/linux/audit.h as an example.  You'll see a
pattern similar to the following:

static inline void audit_foo(...)
{
  if (unlikely(!audit_dummy_context()))
    __audit_foo(...)
}

quoted

+       ab = audit_log_start(audit_context(), GFP_ATOMIC, AUDIT_BPF);
+       if (unlikely(!ab))
+               return;
+       audit_log_format(ab, "prog-id=%u op=%s",
+                        prog->aux->id, bpf_audit_str[op]);

Is it worth putting some checks in here to make sure that you don't
blow past the end of the bpf_audit_str array?

I am wondering if prog-id was really the only information that was needed? Is 
it meaningful to other tools? Does that correlate to anything in /proc? In 
earlier discussion, it sounded like more information was needed to be sure 
what was happening.

yep, as David mentions in the changelog the global ID is enough,
because you can get all the other bpf program info based on that

jirka