Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964828AbbGHNMJ (ORCPT ); Wed, 8 Jul 2015 09:12:09 -0400 Received: from mail4.hitachi.co.jp ([133.145.228.5]:34840 "EHLO mail4.hitachi.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756953AbbGHNMF (ORCPT ); Wed, 8 Jul 2015 09:12:05 -0400 Message-ID: <559D219D.1090507@hitachi.com> Date: Wed, 08 Jul 2015 22:11:57 +0900 From: Masami Hiramatsu Organization: Hitachi, Ltd., Japan User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Alexei Starovoitov , Vince Weaver CC: 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: Re: perf, kprobes: fuzzer generates huge number of WARNings References: <559B3899.5040802@hitachi.com> <20150707191839.GB6040@Alexeis-MBP.westell.com> <20150707212137.GA6287@Alexeis-MacBook-Pro.local> In-Reply-To: <20150707212137.GA6287@Alexeis-MacBook-Pro.local> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3188 Lines: 69 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/