by tyoma on 5/18/2023, 4:50:27 PM
by eyakubovich on 5/18/2023, 9:23:08 PM
In my experience, the hardest part of developing with eBPF is dealing with the multiple kernel versions and configurations that the target machines may have. It's a challenge not only because eBPF features were added gradually but because the internal data structures are not stable. While CO-RE finally makes it possible to be offset agnostic and allows for dealing with things like missing struct members, it's still very much a game of finding out when the code is deployed in the wild. Unit testing is important but I long for a way to easily test across a large matrix of kernel versions/configs (here at EdgeBit, we would be happy to pay for such a service).
by danobi on 5/18/2023, 4:23:18 PM
BPF_PROG_RUN is great but unfortunately depends on the running kernel version. To that end, I wrote `vmtest` (https://dxuuu.xyz/vmtest.html) which is designed for the BPF_PROG_RUN use case.
by alexeldeib on 5/19/2023, 1:16:10 AM
Beyond the content, kudos to the author for crisply and clearly laying out the intent of the article and prerequisites, referring to prior art for larger questions. Really enjoy the style.
by ranting-moth on 5/18/2023, 4:43:19 PM
Pardon my ignorance, is clang needed to build eBPF programs like it says in the article?
by hugatest on 5/18/2023, 8:37:22 PM
If your unit test needs root privileges, then it's not really a unit test in all but very few exceptional cases. It means you are interacting with the actually running kernel, which means you are integration testing, not unit testing.
This past summer one of the Trail of Bits interns worked on a project to test BPF programs from userspace, independent of kernel version: https://blog.trailofbits.com/2023/01/19/ebpf-verifier-harnes...
It is still very much a proof of concept but could be a starting point to make future BPF testing easier.