From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17324 invoked by alias); 4 Dec 2013 23:28:02 -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 17314 invoked by uid 89); 4 Dec 2013 23:28:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.8 required=5.0 tests=AWL,BAYES_50,RDNS_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no version=3.3.2 X-HELO: mail7.hitachi.co.jp Received: from Unknown (HELO mail7.hitachi.co.jp) (133.145.228.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 04 Dec 2013 23:28:00 +0000 Received: from mlsv5.hitachi.co.jp (unknown [133.144.234.166]) by mail7.hitachi.co.jp (Postfix) with ESMTP id 6C68537AC3; Thu, 5 Dec 2013 08:27:52 +0900 (JST) Received: from mfilter04.hitachi.co.jp by mlsv5.hitachi.co.jp (8.13.1/8.13.1) id rB4NRq0k012983; Thu, 5 Dec 2013 08:27:52 +0900 Received: from vshuts01.hitachi.co.jp (vshuts01.hitachi.co.jp [10.201.6.83]) by mfilter04.hitachi.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id rB4NRppx021700; Thu, 5 Dec 2013 08:27:51 +0900 Received: from gxml20a.ad.clb.hitachi.co.jp (unknown [158.213.157.160]) by vshuts01.hitachi.co.jp (Postfix) with ESMTP id C32922F003A; Thu, 5 Dec 2013 08:27:50 +0900 (JST) Received: from [10.198.208.101] by gxml20a.ad.clb.hitachi.co.jp (Switch-3.1.10/Switch-3.1.9) id 5B4N1REF400002690; Thu, 05 Dec 2013 08:27:50 +0900 Message-ID: <529FBA71.6070107@hitachi.com> Date: Wed, 04 Dec 2013 23:28:00 -0000 From: Masami Hiramatsu User-Agent: Mozilla/5.0 (Windows NT 5.2; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Ingo Molnar Cc: Ananth N Mavinakayanahalli , Sandeepa Prabhu , x86@kernel.org, lkml , "Steven Rostedt (Red Hat)" , systemtap@sourceware.org, "David S. Miller" Subject: Re: [PATCH -tip v4 0/6] kprobes: introduce NOKPROBE_SYMBOL() and fixes crash bugs References: <20131204012841.22118.82992.stgit@kbuild-fedora.novalocal> <20131204084551.GA31772@gmail.com> In-Reply-To: <20131204084551.GA31772@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2013-q4/txt/msg00331.txt.bz2 (2013/12/04 17:45), Ingo Molnar wrote: > > * Masami Hiramatsu wrote: > >> Hi, >> Here is the version 4 of NOKPORBE_SYMBOL series. >> >> In this version, I removed the cleanup patches and >> add bugfixes I've found, since those bugs will be >> critical. >> >> Rest of the cleanup and visible blacklists will be proposed later in >> another series. > > Ok, let me make it clear: we need _both_ the conceptual cleanups and > the bug fixes. I see. Why I split this out is because it includes an RFC patch, and for easier review. I still have a series of cleanups :) > Right now kprobes are restricted to root, and they are unsafe and > buggy, and rather fundamentally so, because probing cannot be done > safely without potentially crashing the kernel. So there's no > 'regression' to be fixed, it's mostly about pre-existing bugs - so > there's no requirement for them to come before maintainability > cleanups. 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 :) Then, I'd like to propose this new whitelist feature in kprobe-tracer (not raw kprobe itself). And a sysctl knob for disabling the whitelist. That knob will be /proc/sys/debug/kprobe-event-whitelist and disabling it will mark kernel tainted so that we can check it from bug reports. > So could you please send a whole series that I can apply to -tip as a > work in progress tree, and then we can see what is left to be solved? Sure. :) BTW, would I better fold the cleanups for reducing the number of patches? Thank you, -- Masami HIRAMATSU IT Management Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu.pt@hitachi.com