On Wed, 2022-12-21 at 09:54 -0500, Paul Moore wrote:
On Wed, Dec 21, 2022 at 9:44 AM Paul Moore
<paul(a)paul-moore.com> wrote:
> On Tue, Dec 20, 2022 at 7:02 PM Burn Alting <burn.alting(a)iinet.net.au> wrote:
> > And to cap this off, the program id will always be zero on an UNLOAD, asthe
> > 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 shouldfix as soon
> as we can. I'll take a look during the holiday and seewhat we can do to fix
> this; looking quickly at it now I don't think itwill be too bad, but one never
> knows for sure ...
I'm still just looking at the code, but I think we can also do abetter 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).