search

aya-rs / aya

Aya is an eBPF library for the Rust programming language, built with a focus on developer experience and operability.
https://aya-rs.dev/book/
Apache License 2.0
3.06k stars 268 forks source link

How to Detect Support for Ringbuf in Rust eBPF Code? #957

Open swananan opened 3 months ago

swananan commented 3 months ago

Hi, I encountered a problem with my eBPF program written in Rust. I’m using the ringbuf, but it fails to run on the lower version kernel, presumably due to a lack of ringbuf support in the eBPF implementation of those kernels.

I was considering using Rust compile-time macros to conditionally use ringbuf based on kernel support, but this approach would result in multiple binaries, which I want to avoid.

So I did some research, I found that eBPF CO-RE and the bpf_core_enum_value_exists(enum bpf_func_id, BPF_FUNC_ringbuf_reserve) function can help detect the existence of ringbuf support without complaints from the eBPF verifier. However, I noticed that this API isn't available in the aya helper library. I guess bpf_core_enum_value_exists relies on LLVM eBPF functions, which might explain its absence in aya. If I understand it incorrectly, please let me know.

Is there a better solution for detecting ringbuf or other features support in Rust eBPF code other than using Rust compile-time macros? Any guidance or suggestions would be greatly appreciated.

swananan commented 2 months ago

Update: Refer to this link here. We have two potential solutions. The first is bpf_core_enum_value_exists, which Aya does not yet support. The second solution involves checking for support in user space and using an eBPF global value to control eBPF code. This approach needs to allow the loader or kernel to remove dead code and unnecessary maps from the eBPF code. It looks like these PRs (https://github.com/aya-rs/aya/pull/970 and https://github.com/aya-rs/aya/pull/968) are working on the second solution, and I am very much looking forward to using it.

martinsoees commented 2 months ago

Hi @swananan.

I closed #970 because scope changed based on a conversation in the Discord channel. The new approach will take longer to implement, but will offer the same functionality (i.e. detect kernel features from user space) and used with #968 it will relocate maps away prior to loading, so the verifier will see it as dead code (like the link you showed).

Hopefully #968 will pass review soon. I have no timeline for the user space features right now.

swananan commented 2 months ago

Hi @swananan.

I closed #970 because scope changed based on a conversation in the Discord channel. The new approach will take longer to implement, but will offer the same functionality (i.e. detect kernel features from user space) and used with #968 it will relocate maps away prior to loading, so the verifier will see it as dead code (like the link you showed).

Hopefully #968 will pass review soon. I have no timeline for the user space features right now.

Thank you for the quick reply. I completely understand that it might take longer to implement, as it seems like a refactoring job. Thanks again for your work.