OBI Integration (Phase 1): unify eBPF programs

[MrAlias]

Our ultimate goal is to unify overlapping dependencies with the obi project. The following has been identified as the first step in this process.

We need to unify how we configure, operate and interact with eBPF programs across projects. The notable differences identified in a PoC are:

• Offsets table per executable
• Adding process information to events
• Sharing maps using file descriptor rewrite for avoiding BPF file system SYS_ADMIN requirements

Proposal

1. Start with a single probe.
   • The database probe has been identified as the simplist while still comprehensively needing the above issues addressed.
2. Update the probe code so it both works in this project and can be vendored into the obi project
3. Reuse the probe in both projects

Follow-up

From this process we will have a blueprint for other probes to be updated in a similar fashion. We will build tasks for each update when this step is complete.

Additionally, we plan to have a better understanding of the differences between the Manager and the OBI `Tracer. The tracking issue will be updated with these differences and we will develop a unification plan for that and a probe API from this learning..

[grcevski]

To follow-up on the development plan for the first probe, here are couple of tasks that we can start with:

• Introduce a new style of constant passing from the user-space to the BPF side, such that the constants are per executable, that is, by inode number. We can call this an offsets table.
  • Create a shareable index of field definitions between the eBPF side and user-space for the purpose of mapping offsets.
  • Introduce an offsets table in the BPF side and change the Go SQL probe to use this offsets table.
  • Populate the offsets table at the time we load constants in the user-space side of the SQL probe.
  • Switch the SQL probe code to use the offsets table
• Add process information to the SQL event data structure
• Refactor the parent context information code if necessary to ensure minimal dependencies, so that the parent information can be supplied from OBI as well as from go-auto.