Tracee multiple eBPF objects support (per enabled/filtered event).

[rafaeldtinoco]

This is a spin off from #2991 for a single foundation need of the API server: enabling multiple eBPF objects to be loaded/unloaded on-demand per picked/filtered event.

[NDStrahilevitz]

Do you mean that each event's program, for example security_file_open and security_socket_connect will be it's own object, or that related events will be clustered into smaller ebpf objects with multiple programs?

[rafaeldtinoco]

will be it's own object, or that related events will be clustered into smaller ebpf objects with multiple programs?

---

I haven't made up my mind on that yet but I'm thinking on splitting some concepts and treating them as inter-dependendant.

My initial idea is to have ebpf map elf objects and ebpf probe elf objects and associate them as dependencies to each event (similar to what we do with events <-> probes currently).

The question you may ask is:

1. what about probes that serve 2 events" for example? I believe we could allow that to happen in the beginning (same object used for 2 events but loaded just once).

But, in the "final" approach, I think each "plugin" will end up having its own objects, no matter what (and we can either use tailcalls to share the same probe points OR even attach 2 or more eBPF objects to the same probe points, which is totally fine but needs overhead checking).

2. what about "general usage" probes? and general usage maps ?

I believe in the beginning there will be many "general" usage probes and maps that will always be enabled, no matter which event is being traced, and that might reduce as long as we walk to a plugin like architecture.

No final decision, mostly me thinking out loud here.

I'll have some code for us to discuss ideas, no worries. I want also to have ebpf objects and maps to be "constructed", "destructed" AND "pinned" among diff executions (that will allow us to clean things up for dynamic signature loading/unloading for those logics that need it).