[EPIC] Migrate from libbpf-rs to aya-rs

[vadorovsky]

Aya allows to write BPF programs in Rust which is natively compiled by Rust compiler.

https://github.com/aya-rs/aya

TODO

Upstream

• Implement Raw Tracepoints and LSM Probes aya-rs/aya#9
• Refactor to do all formatting in userspace aya-rs/aya-log#4
• Add support for BPF_MAP_TYPE_LPM_TRIE aya-rs/aya#128

Downstream

First steps, which can be done now:

• Try to use aya only in userspce (as the 1st step) #135
• [aya] Rewrite sched_process_fork and clone_audit programs in Rust #136
• [aya] Rewrite syslog_audit in Rust #137

Items blocked by upstream:

• [aya] Rewrite sb_mount in Rust #138
• [aya] Rewrite open_audit in Rust #139

[willfindlay]

I think the main blocker for this is now my context arguments patch. I'll be submitting a draft PR to aya later today.

[vadorovsky]

Bumping priority of this. Things on aya side are mostly done and we could start an initial rewrite as soon as as any developer has free cycles.

It would be especially nice to get this done before starting writing any new BPF programs.

[willfindlay]

I can get started on this as early as this weekend.

[anakryiko]

Pardon my curiosity, but would it be ok to ask what exactly is so appealing about writing BPF program source code in Rust compared to C. BPF programs can certainly get quite complicated, but so far I haven't found it restrictive and counter-productive to have to write it in C. C actually lends itself quite nicely to a verifiable, somewhat low-level code that BPF verifier expects.

I've seen lots of production applications using libbpf/libbpf-rs, and Go BPF libraries writing BPF programs using C, and using language of their choice (C++, Rust, Go, what have you) for user-space parts. And I haven't seen much complains about the fact that it's C and not some other language (it's rather compiler doing too clever code transformations and optimizations that's constantly causing troubles, but that's not C fault per se and I'd imagine Rust compiler would try to be as clever as well). On the other hand, all the kernel BPF development and all the new BPF features are always considered along the lines on how they are going to be exposed through C into BPF programs. Same goes for BPF CO-RE and extra C language extensions (mostly through built-ins) are first and foremost designed with the C language in mind. BPF CO-RE is more than field offset relocations, there is an entire family of built-ins that power bpf_core_field_exists(), bpf_core_type_exists(), and a bunch of others (see https://nakryiko.com/posts/bpf-core-reference-guide/#dealing-with-kernel-changes-and-feature-detection for full list). Are those exposed through Rust for BPF program source code?

I'm in no way trying to convince you to stick to C, but I'm just curious what drives people away from the most supported (by kernel BPF developers) and full-featured language frontend (C) into writing that code with Rust, where I suspect a bunch of things might not work or will work not as expected (I'm talking about the BPF program side, mind you)? Honest curiosity, would really appreciate a comprehensive list of reasons. Thank you!

[vadorovsky]

Hi @anakryiko. The reasons why I'm considering switching from libbpf to aya are:

• no dependency on LLVM (it can use the internal LLVM of Rust), everything can be done with Cargo
• no need to use bindgen/FFI to have shared structures between userspace and BPF code
• aya only has to use bindgen/FFI to generate bindings to kernel structures, but that's mostly hidden from developers using aya
• I like aya-log and no necessity for boilerplate code to handle logging with perf event buffer

Same goes for BPF CO-RE and extra C language extensions (mostly through built-ins) are first and foremost designed with the C language in mind. BPF CO-RE is more than field offset relocations, there is an entire family of built-ins that power bpf_core_field_exists(), bpf_core_type_exists(), and a bunch of others (see https://nakryiko.com/posts/bpf-core-reference-guide/#dealing-with-kernel-changes-and-feature-detection for full list). Are those exposed through Rust for BPF program source code?

bpf_core_field_exists() and bpf_core_type_exists() type of macros are not currently in aya, as far as I know. There is a general support for CO-RE - that means, all bindings to kernel headers made (automatically) in aya have CO-RE support. I think porting all those macros to aya would be a good idea. Especially because aya already uses BPF_FIELD_EXISTS and BPF_TYPE_EXISTS in relocation code.