Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933807AbbGGVVu (ORCPT ); Tue, 7 Jul 2015 17:21:50 -0400 Received: from mail-pa0-f43.google.com ([209.85.220.43]:36536 "EHLO mail-pa0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932868AbbGGVVl (ORCPT ); Tue, 7 Jul 2015 17:21:41 -0400 Date: Tue, 7 Jul 2015 14:21:38 -0700 From: Alexei Starovoitov To: Vince Weaver Cc: Masami Hiramatsu , linux-kernel@vger.kernel.org, Ananth N Mavinakayanahalli , Anil S Keshavamurthy , "David S. Miller" , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Steven Rostedt Subject: Re: perf, kprobes: fuzzer generates huge number of WARNings Message-ID: <20150707212137.GA6287@Alexeis-MacBook-Pro.local> References: <559B3899.5040802@hitachi.com> <20150707191839.GB6040@Alexeis-MBP.westell.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2454 Lines: 49 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. > > > 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). 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. -- 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/