Open rafaeldtinoco opened 1 year ago
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?
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:
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).
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).
This is a spin off from https://github.com/aquasecurity/tracee/issues/2991 for a single foundation need of the API server: enabling multiple eBPF objects to be loaded/unloaded on-demand per picked/filtered event.