On Wed, Sep 10, 2014 at 4:35 AM, Daniel Borkmann <dborkman@xxxxxxxxxx> wrote: > > Since we already have an extensive BPF test suite, that is, lib/test_bpf.c, > which currently also does sanity checks for the classic BPF verifier, is > there a reason these verifier test cases cannot be extended/integrated there > as well but have to go to kernel/bpf/test_stub.c resp. > samples/bpf/test_verifier.c ? > I don't like that we put testing code into kernel/bpf/ whereas we already > have a BPF test infrastructure in the kernel elsewhere. yes. there is a reason. Verifier needs to be tested from user space, since it works on fds. Process local map_fd are part of the eBPF programs. Therefore one is testing things from kernel and another from userspace. We definitely need both. Currently there is no use case to call verifier from inside the kernel. I'm not sure there will be one. Verifier's main purpose is to check user supplied programs and provide humans an understandable error messages of what is 'unsafe' in particular program. Eventually we will integrate this verifier messages with program compilation. Like, the user would write a program in C then invoke a wrapper of compiler and verifier, which will point to lines in C code which are doing something wrong like loops or out of bounds access. Currently verifier complains about particular 'unsafe' instruction, but humans have hard time correlating asm to C. -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
