Re: perf, kprobes: fuzzer generates huge number of WARNings

[Vince Weaver]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/