Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
swananan opened this issue May 28, 2024 · 4 comments
Open

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

swananan opened this issue May 28, 2024 · 4 comments

Comments

@swananan
Copy link
Contributor

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
Copy link
Contributor Author

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 (#970 and #968) are working on the second solution, and I am very much looking forward to using it.

@martinsoees
Copy link

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
Copy link
Contributor Author

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.

@harisudarsan1
Copy link

harisudarsan1 commented Nov 17, 2024

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.

I think for ringbuf support the only requirement is kernel version above 5.8 (correct me If I'm wrong) in that case can you do a runtime check for the kernel version before loading the ringbuf?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants