WIP: auto-attach tracepoints based on SEC() data

[Ablu]

This is mostly a conversation starter. The work originated in me asking about this on Discord [1].

I can try to flesh this out to a full solution, but I have some questions on what the ideal solution looks like:

Question 1: Currently I am mostly seeing these SEC() annotations in C bpf programs. The automatic template generator of the aya-ebpf tracepoints does not seem to populate the fields (tough it looks like they are supported!). Should we populate those fields there too?
libbpf-tools generates those .skel.h headers that allow automating the attach. I find that a nice QoL improvement over manually having to attach all the probes.

Question 2: I assume we also want to expose public getters for these fields?

Question 3: Do we want to extend this to all of the other "well-known" SEC() annotations that libbpf-tools uses? This would allow us to have a central auto_attach() that simply iterates over all programs and attaches them all?

Open TODOs:

• tests
• better documentation
• review contribution guidelines in detail

[1] https://discord.com/channels/855676609003651072/855676609003651075/1288759816612741120

---

This change is 

[netlify]

✅ Deploy Preview for aya-rs-docs ready!

Built without sensitive environment variables

Name	Link
🔨 Latest commit	ef73d65
🔍 Latest deploy log	https://app.netlify.com/sites/aya-rs-docs/deploys/678ab76f79105a00082f46b9
😎 Deploy Preview	https://deploy-preview-1057--aya-rs-docs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[alessandrod]

This is mostly a conversation starter. The work originated in me asking about this on Discord [1].

Hey! Thanks for the PR!

I can try to flesh this out to a full solution, but I have some questions on what the ideal solution looks like:

Question 1: Currently I am mostly seeing these SEC() annotations in C bpf programs. The automatic template generator of the aya-ebpf tracepoints does not seem to populate the fields (tough it looks like they are supported!). Should we populate those fields there too? libbpf-tools generates those .skel.h headers that allow automating the attach. I find that a nice QoL improvement over manually having to attach all the probes.

For things where it makes sense - for example tracepoints that in most cases have exactly 1 attach target - yes I think it makes sense.

Question 2: I assume we also want to expose public getters for these fields?

Yes, see CgroupSkb where we expose already https://docs.rs/aya/latest/aya/programs/cgroup_skb/struct.CgroupSkb.html#method.expected_attach_type

Question 3: Do we want to extend this to all of the other "well-known" SEC() annotations that libbpf-tools uses?

This for sure - we want to be as compatible with libbpf as possible.

This would allow us to have a central auto_attach() that simply iterates over all programs and attaches them all?

This is a separate question, and I think it requires a bit more thinking, eg:

let ebpf = Ebpf::load(...);
ebpf.auto_attach()?; // what happens to the programs that _can't_ be auto attached? 

I think it's counter intuitive that some programs wouldn't get attached. Not sure what the solution would be. What does libbpf do?

[Ablu]

For things where it makes sense - for example tracepoints that in most cases have exactly 1 attach target - yes I think it makes sense.

I would add k(ret)probe's to the list then :). I can do some research on which programs can be auto-attached in libbpf.

I think it's counter intuitive that some programs wouldn't get attached. Not sure what the solution would be. What does libbpf do?

The code is here: https://github.com/libbpf/libbpf/blob/7984737fbf3b2a14a86321387bb62abb16cfc4ed/src/libbpf.c#L12365-L12404

So it looks like some conventions to prevent autoattachment: https://github.com/libbpf/libbpf/blob/7984737fbf3b2a14a86321387bb62abb16cfc4ed/src/libbpf.c#L747-L757 and some program types are simply not autoattached. Otherwise, a fail to auto-attach will simply cause an error.

That overall seems like reasonable to me!

[alessandrod]

For things where it makes sense - for example tracepoints that in most cases have exactly 1 attach target - yes I think it makes sense.

I would add k(ret)probe's to the list then :). I can do some research on which programs can be auto-attached in libbpf.

Yep for sure - ideally we get to 100% libbpf compatibility.

I think it's counter intuitive that some programs wouldn't get attached. Not sure what the solution would be. What does libbpf do?

The code is here: https://github.com/libbpf/libbpf/blob/7984737fbf3b2a14a86321387bb62abb16cfc4ed/src/libbpf.c#L12365-L12404

So it looks like some conventions to prevent autoattachment: https://github.com/libbpf/libbpf/blob/7984737fbf3b2a14a86321387bb62abb16cfc4ed/src/libbpf.c#L747-L757 and some program types are simply not autoattached. Otherwise, a fail to auto-attach will simply cause an error.

That overall seems like reasonable to me!

I don't like that in the case of auto_attach() failure some things might remain attached, but I don't have a solution, and I like being "more compatible" with libbpf. If we do implement auto_attach(), we should also add program.links() and program.links_mut() so one can retrieve the attached links and detach.

[mergify]

@Ablu, this pull request is now in conflict and requires a rebase.

[Ablu]

I gave this a bit more of a try over the last days... But I keep hitting a few things that cause some frustration and leave me with no particular nice solution:

• I end up with a lot of duplication across ProgramSection and Program
• I end up with a lot of duplication between the individual entries within the section enum structs... To support the ?kprobe/foo opt-out of auto-attaching I need to put some no_auto_attach flag into each struct. I feel like it may be better a property on ALL ProgramSections (maybe along with sleepable?).
• A lot of boilerplate code to actually route the auto_attach to all the Program variants.

I am starting to wonder if moving the Program to a trait makes sense... Then they could be treated as equals without a lot of the enum variant routing...

Has this ever been explored? Or am I overthinking this and the duplication is not too bad?