[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1577244734.11604.1521222781948.JavaMail.zimbra@efficios.com>
Date: Fri, 16 Mar 2018 13:53:01 -0400 (EDT)
From: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To: rostedt <rostedt@...dmis.org>
Cc: Francis Deslauriers <francis.deslauriers@...icios.com>,
Masami Hiramatsu <mhiramat@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH 2/2] kprobe: fix: Add ftrace_ops_assist_func to kprobe
blacklist
----- On Mar 16, 2018, at 12:48 PM, rostedt rostedt@...dmis.org wrote:
> On Fri, 16 Mar 2018 12:41:34 -0400
> Steven Rostedt <rostedt@...dmis.org> wrote:
>
>> Yes, kprobes are dangerous. I'm not saying it shouldn't be fixed, I'm
>> saying that I don't have time to fix it now, but would be happy to
>> accept patches if someone else does so.
>
> And looking at what I replied before for the original patch. It would
> probably be a good idea to blacklist directories. Like we do with
> function tracing. We probably should black list both kernel/tracing and
> kernel/events from being probed.
>
> Did this come up at plumbers? You were there too, I don't remember
> discussing it there.
I don't remember this coming up last Plumbers nor KS neither, given
that we were focused on other topics.
Would the general approach you envision be based on emitting all code
generated by compilation of all objects under kernel/tracing and
kernel/events into a specific "nokprobes" text section of the kernel ?
Perhaps we could create a specific linker scripts for those directories,
or do you have in mind a neater way to do this ?
Thanks,
Mathieu
>
> -- Steve
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
Powered by blists - more mailing lists