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:
> > On Thu, Nov 28, 2019 at 4:16 AM Jiri Olsa <jolsa@xxxxxxxxxx> wrote:
> > > From: Daniel Borkmann <daniel@xxxxxxxxxxxxx>
> > >
> > > 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
> > 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(...)
> > }
> >
> > > + 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
