Messages in this thread |  | | Date | Thu, 5 Dec 2013 18:38:04 +0530 | Subject | Re: [PATCH -tip v4 0/6] kprobes: introduce NOKPROBE_SYMBOL() and fixes crash bugs | From | Sandeepa Prabhu <> |
| |
> 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
|  |