wip: feature(scap): allow custom tracepoints on ebpf probe

[Molter73]

What type of PR is this?

/kind feature

Any specific area of the project related to this PR?

/area libscap

Does this PR require a change in the driver versions?

What this PR does / why we need it:

This change allows eBPF probes created with tracepoints other than the ones used by Falco to be directly attached and detached. This is useful for adopters that might want to go through the additional effort of attaching directly to the syscalls they care about, excluding sys_enter and sys_exit which could add extra computing effort, even for ignored syscalls. Because adopters need to go the extra mile to compile a probe from their own source code, I don't think a separate mechanism for controlling whether the custom tracepoints are attached or not is needed, simply finding such a tracepoint means we want it attached.

Which issue(s) this PR fixes:

Fixes #

Special notes for your reviewer:

Does this PR introduce a user-facing change?:

NONE

[poiana]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: Molter73

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [Molter73]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[Molter73]

I'll open an issue for discussing this in a minute, wanted to have the draft PR so I could point to it as a possible implementation that could work for our use case.

[incertum]

Suggestions:

• Approval of these changes is contingent upon the majority of libs maintainers being in favor [DECISION/VOTE]: Clarify acceptability of a BPF probe-centric approach for custom driver management #1527.
• Implement custom name prefixes in the form of custom/<...> to address some concerns raised in Allow loading tracepoints other than the ones needed by Falco #1376 (comment) (@erthalion implement your suggestion basically).
• Add comments throughout the code to emphasize that the custom program loading mechanisms may undergo refactors and are primarily intended for custom libs adoption, and not (yet) for the Falco use case.
• Related to above, consider linking to or describing example use cases and considerations to be aware of (essentially, as outlined by @Stringy in Allow loading tracepoints other than the ones needed by Falco #1376 (comment) aka emphasizing importance of following the libscap event schema).
• General Note: Defer modern_bpf until libpman has been removed.

[incertum]

@gnosek made some great suggestions here #1527 (comment)

[poiana]

Issues go stale after 90d of inactivity.

Mark the issue as fresh with /remove-lifecycle stale.

Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle stale

[FedeDP]

/remove-lifecycle stale