Could we have access to Module links?

[geyslan]

Currently Module structure maintains links slice but keeping it private to the lib.

https://github.com/aquasecurity/libbpfgo/blob/main/libbpfgo.go#L213-L218

How about to make it public so other implementations could make use of them directly?

I mean I'm on an implementation like this:

type KABPFManager struct {
	objs          map[KABPFObjFileName]*lbpf.KABPFObject
	maps          map[KABPFMapName]*lbpf.KABPFMap
	progs         map[KABPFProgName]*lbpf.KABPFProgram
	links         map[KABPFLinkName]*lbpf.KABPFLink
	objsMapsPath  string
	objsProgsPath string
}

I'm having to keep track of the data that is already inside the lbpf.KABPFObject (libbpfgo.Module wrapper).

It can be make public from a Module.Links().

[yanivagman]

I'm not sure I understand the purpose of this request.
Whenever a user calls one of the attach functions, we return a pointer to the created BPFLink, which can then be saved by the user in whatever way he wants.
In addition, the Module structure only keeps track of the created BPFLinks just so it can destroy them on module.Close(). This is something we do internaly in libbpfgo, and the implementation might change in the future (for example, using a map instead of a slice to hold these links) - so why should we expose this field?

[geyslan]

I'm not sure I understand the purpose of this request.

Initially it would just be to check if there are any links in a program, like this:

if len(BPFProg.GetModule().Links()) == 0 {
    // Can close the the Program or the Module
}

Whenever a user calls one of the attach functions, we return a pointer to the created BPFLink, which can then be saved by the user in whatever way he wants.

That's what we're doing, duplicating the references and the maintenance logic:

https://github.com/kubearmor/KubeArmor/blob/event-auditor/KubeArmor/eventAuditor/ebpfManager.go

In addition, the Module structure only keeps track of the created BPFLinks just so it can destroy them on module.Close(). This is something we do internaly in libbpfgo, and the implementation might change in the future (for example, using a map instead of a slice to hold these links)

I got your point about the internal use and possible changes.

so why should we expose this field?

Along with my initial example, we're also thinking about detaching links in the future: #66

Let's say that the consumer wants to detach all the links of a Module keeping the respective programs in memory :

for l := range Module.Links() {
    l.Detach()
}

[yanivagman]

Along with my initial example, we're also thinking about detaching links in the future: #66

Adding detach functionality is definitely something we should do. After doing that, we can consider expanding the API by providing module.DetachAll() (this is somehow equivalent to libbpf's bpf_object__detach_skeleton()) or even prog.Detach() to detach the links of a specific program.

[rafaeldtinoco]

Along with my initial example, we're also thinking about detaching links in the future: #66

Adding detach functionality is definitely something we should do. After doing that, we can consider expanding the API by providing module.DetachAll() (this is somehow equivalent to libbpf's bpf_object__detach_skeleton()) or even prog.Detach() to detach the links of a specific program.

Agreed, and, since we're not using skeleton in libbpfgo, we would have to keep the link references somewhere within libbpfgo itself (as the references are currently held by bpf_object_skeleton). Be aware that there might be some special conditions like:

https://x-lore.kernel.org/bpf/20210801051123.3822498-1-rafaeldtinoco@gmail.com/

 static int bpf_link_perf_detach(struct bpf_link *link)
@@ -9002,6 +9048,10 @@ static int bpf_link_perf_detach(struct bpf_link *link)
 		close(perf_link->perf_event_fd);
 	close(link->fd);
 
+	/* legacy kprobe needs to be removed after perf event fd closure */
+	if (perf_link->legacy_name)
+		remove_kprobe_event_legacy(perf_link->legacy_name, perf_link->is_retprobe);
+
 	return libbpf_err(err);
 }

so my suggestion for such approach would be always to try to make libbpf to do the most amount of dirty job as possible (as it will handle un-attachment, ioctls and file descriptor closure logic for all cases, including legacy kprobe, which is the example Im showing here).