Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1179791

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

Show all headers | View raw

On 2015/07/08 6:21, Alexei Starovoitov wrote:
> On Tue, Jul 07, 2015 at 05:08:51PM -0400, Vince Weaver wrote:
>> 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 suspect kprobes will forever be root only, whereas for bpf I'm thinking
> to introduce CAP_BPF, but before that we need to finish constant blinding
> and add address leak prevention. So not soon.

Currently I don't plan to do that. Actually systemtap allows that, but
with much bigger blacklist. I think we can make a tool which also
allows user to add new events on the limited functions (white-list).
But anyway, since these can expose kernel function addresses to users,
it is highly recommended to limit users by some capabilities.

>>>> 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).

Hmm I must fix some parts of kprobes by changing retval or showing more
precise messages.

Thanks!

> I see. I guess anyone trying to use syscall directly will be facing such
> issues, but libbpf that is being developed to be used by perf and others
> should solve these problems.



-- 
Masami HIRAMATSU
Linux Technology Research Center, System Productivity Research Dept.
Center for Technology Innovation - Systems Engineering
Hitachi, Ltd., Research & Development Group
E-mail: masami.hiramatsu.pt@hitachi.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

perf, kprobes: fuzzer generates huge number of WARNings Vince Weaver <vincent.weaver@maine.edu> - 2015-07-06 23:30 +0200
  Re: perf, kprobes: fuzzer generates huge number of WARNings Steven Rostedt <rostedt@goodmis.org> - 2015-07-06 23:30 +0200
  Re: perf, kprobes: fuzzer generates huge number of WARNings Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> - 2015-07-07 12:40 +0200
    Re: perf, kprobes: fuzzer generates huge number of WARNings Vince Weaver <vincent.weaver@maine.edu> - 2015-07-07 20:10 +0200
  Re: Re: perf, kprobes: fuzzer generates huge number of WARNings Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> - 2015-07-08 15:20 +0200

csiph-web