On Tue, 7 Jul 2015, Alexei Starovoitov wrote: > On Tue, Jul 07, 2015 at 12:00:12AM -0400, Vince Weaver wrote: > > > > Well the BPF hack is in the fuzzer, not the kernel. And it's not really a > > hack, it just turned out to be a huge pain to figure out how to > > manually create a valid BPF program in conjunction with a valid kprobe > > event. > > You mean automatically generating valid bpf program? That's definitely hard. > If you mean just few hardcoded programs then take them from samples or > from test_bpf ?
there's already code in trinity that in theory autogenerates bpf programs, but for now I was just trying to hook up a short known valid one. it might not be possible to really test things though, as you need to be root to create a kprobe and attach a BPF program, but my fuzzer when run as root often does all kinds of other stuff that will crash a machine. Is it ever planned to allow using bpf/kprobes without requiring full CAP_ADMIN privledges? > > I did have to sprinkle printks in the kprobe and bpf code to find out > > where various EINVAL returns were coming from, so potentially this is just > > a problem of printks happening where they shouldn't. I'll remove those > > changes and try to reproduce this tomorrow. > > could you please elaborate on this further. Which EINVALs you talking about? When you are trying to create a kprobe and bpf file there's about 10 different ways to get EINVAL as a return value and no way of knowing which one you are hitting. I added printks so I could know what issue was causing the einval. (from memory, the problems I hit were not zeroing out the attr structure, having a wrong instruction count, and a few others). Vince -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
