On Wed, 2022-12-21 at 09:54 -0500, Paul Moore wrote:
On Wed, Dec 21, 2022 at 9:44 AM Paul Moore <
paul@paul-moore.com
> wrote:
On Tue, Dec 20, 2022 at 7:02 PM Burn Alting <
burn.alting@iinet.net.au
> wrote:
And to cap this off, the program id will always be zero on an UNLOAD, as
the routine that sets it to zero, kernel/bpf/syscall.c:bpf_prog_free_id(),
is called before the emit audit event routine, kernel/bpf/syscall.c:bpf_audit_prog().

So a bug!

Ooof :/  Independent of the other issues this is something we should
fix as soon as we can.  I'll take a look during the holiday and see
what we can do to fix this; looking quickly at it now I don't think it
will be too bad, but one never knows for sure ...

I'm still just looking at the code, but I think we can also do a
better job associating eBPF UNLOAD operations
As Steve suggests, it would have value to provide more information (name, tag, uid) and I don't know if it's possible
but relate it to the bpf syscall's file descriptor for the map created or program loaded (the exit value).