From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3427 invoked by alias); 5 Dec 2013 13:08:15 -0000 Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org Received: (qmail 3418 invoked by uid 89); 5 Dec 2013 13:08:14 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-we0-f180.google.com Received: from Unknown (HELO mail-we0-f180.google.com) (74.125.82.180) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Thu, 05 Dec 2013 13:08:14 +0000 Received: by mail-we0-f180.google.com with SMTP id t61so10992627wes.11 for ; Thu, 05 Dec 2013 05:08:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=18u54uh/TvUfPubL/yDfNj/09C/4J2GtyDEwbu+6Rj4=; b=kOLvSRMXmjsDliFiUmKQhidvBin9jKEvKF+26SN/pJY++g9yKNPyv9oIG1hmrqCe7o hQncu30bv9kYtTNPyAhb4nYNg4DUdc8KwLqyboF0ckaLvdNH6aSLAg96s31ZtdoM6ICt UOAeQnszQ7LDfbNWTb2nelAZ06oPEI7hgnacWk5EQSa0dfdAXDuiXNzrv/ftzu7XEPyI 8uEC+ArNmBTSCnwhHX4uY5blcEkpQc6CSTUB47kvgrCHVPsshCxGhRCdIlfFH+kkjZKF znOzW04yrfrUgx2xPIX+egm1abOX90z0ljIHw9iLfm+5hBopPPyDielVsCeY2nuesaL3 3vJw== X-Gm-Message-State: ALoCoQkSXHovbyyAMJnHIy1++7amprs9LyE+Sxj77CVmsSnEfS0B1HoXeZnNElX7IECtV8TAgPbv MIME-Version: 1.0 X-Received: by 10.194.89.233 with SMTP id br9mr67930013wjb.15.1386248884786; Thu, 05 Dec 2013 05:08:04 -0800 (PST) Received: by 10.194.219.7 with HTTP; Thu, 5 Dec 2013 05:08:04 -0800 (PST) In-Reply-To: <529FBA71.6070107@hitachi.com> References: <20131204012841.22118.82992.stgit@kbuild-fedora.novalocal> <20131204084551.GA31772@gmail.com> <529FBA71.6070107@hitachi.com> Date: Thu, 05 Dec 2013 13:08:00 -0000 Message-ID: Subject: Re: [PATCH -tip v4 0/6] kprobes: introduce NOKPROBE_SYMBOL() and fixes crash bugs From: Sandeepa Prabhu To: Masami Hiramatsu Cc: Ingo Molnar , Ananth N Mavinakayanahalli , x86@kernel.org, lkml , "Steven Rostedt (Red Hat)" , systemtap@sourceware.org, "David S. Miller" Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes X-SW-Source: 2013-q4/txt/msg00335.txt.bz2 > OK, I think the kprobe is like a strong medicine, not a toy, > since it can intercept most of the kernel functions which > may process a sensitive user private data. Thus even if we > fix all bugs and make it safe, I don't think we can open > it for all users (of course, there should be a knob to open > for any or restricted users.) > >> So we need both a maintainable and a sane/safe solution, and I'd like >> to apply the whole thing at once and be at ease that the solution is >> round. We should have done this years ago. > > For the safeness of kprobes, I have an idea; introduce a whitelist > for dynamic events. AFAICS, the biggest unstable issue of kprobes > comes from putting *many* probes on the functions called from tracers. > > It doesn't crash the kernel but slows down so much, because every > probes hit many other nested miss-hit probes. This gives us a big > performance impact. However, on the other side, this kind of feature > can be used *for debugging* static trace events by dynamic one if we > carefully use a small number of probes on such functions. :) > > Thus, I think we can restrict users from probing such functions by > using a whitelist which ftrace does already have; > available_filter_functions :) I am not sure if this question is related, uprobes or ftrace code does not define __kprobes, so is it safe to place kprobe on uprobes or ftrace code? Is it expected from arch code to support such cases? Thanks, Sandeepa