| Message ID | 20190724080328.16145-1-rpalethorpe@suse.com |
|---|---|
| Headers | show |
| Series | BPF testing | expand |
Hi Richie, > Hello, > This patch set introduces a very basic test which kicks the tires of the bpf > system call. It doesn't actually load a eBPF program, I will create another > test for that. However I have some concerns which I will discuss while doing > that. Good start, great. > There are already extensive BPF tests in the kernel selftests. These appear to > be quite complex and test a variety of functionality. They also are far less > structured than LTP's modern tests and are tied to the kernel tree which makes > using them in QA a pain. There are also some tests in the BCC project, which > may test the kernel as a byproduct. Yep, this is true for other tests in kselftest tree. > So there are a number of options which are not necessarily mutually exclusive: > 1) Port (some of) the selftests to the LTP. > 2) Port the LTP library to the selftests. > 3) Focus the LTP's BPF tests on reproducing specific high impact bugs. > This patch set copies in the necessary headers so that we have zero external > dependencies. > I will also use raw byte code for the program test which is at > least acceptable for trivial programs. So we do not need BCC or Clang/LLVM > with eBPF support or matching kernel sources to generate offsets into internal > structures. +1 > For the time being atleast my preference would be for (3) while avoiding > taking on any dependencies to ensure those tests are run by users mostly > ignorant of BPF, but are still exposed to critical bugs in the BPF stack. +1 Kind regards, Petr
Hi! > This patch set introduces a very basic test which kicks the tires of the bpf > system call. It doesn't actually load a eBPF program, I will create another > test for that. However I have some concerns which I will discuss while doing > that. > > There are already extensive BPF tests in the kernel selftests. These appear to > be quite complex and test a variety of functionality. They also are far less > structured than LTP's modern tests and are tied to the kernel tree which makes > using them in QA a pain. There are also some tests in the BCC project, which > may test the kernel as a byproduct. > > So there are a number of options which are not necessarily mutually exclusive: > > 1) Port (some of) the selftests to the LTP. > 2) Port the LTP library to the selftests. > 3) Focus the LTP's BPF tests on reproducing specific high impact bugs. The option 3 sounds good, just FYI there are CVEs some with POCs for BPF, just by googling "ebpf CVE" you got some: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-16995 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-7308 Also cloudfare blog seems to be very relevant: https://blog.cloudflare.com/ebpf-cant-count/ And there are some test stuffed in linux/samples/bpf/ as well.
Hello, Cyril Hrubis <chrubis@suse.cz> writes: > Hi! >> This patch set introduces a very basic test which kicks the tires of the bpf >> system call. It doesn't actually load a eBPF program, I will create another >> test for that. However I have some concerns which I will discuss while doing >> that. >> >> There are already extensive BPF tests in the kernel selftests. These appear to >> be quite complex and test a variety of functionality. They also are far less >> structured than LTP's modern tests and are tied to the kernel tree which makes >> using them in QA a pain. There are also some tests in the BCC project, which >> may test the kernel as a byproduct. >> >> So there are a number of options which are not necessarily mutually exclusive: >> >> 1) Port (some of) the selftests to the LTP. >> 2) Port the LTP library to the selftests. >> 3) Focus the LTP's BPF tests on reproducing specific high impact bugs. > > The option 3 sounds good, just FYI there are CVEs some with POCs for BPF, > just by googling "ebpf CVE" you got some: > > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-16995 > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-7308 > > Also cloudfare blog seems to be very relevant: > > https://blog.cloudflare.com/ebpf-cant-count/ > > And there are some test stuffed in linux/samples/bpf/ as well. Ah, something I didn't realise is that various types of eBPF program can be run without CAP_SYS_ADMIN because the man page is out of date. I will send a patch for that. -- Thank you, Richard.