search for: kprobes

Hi, Here is the version 3 of NOKPORBE_SYMBOL series. Currently the blacklist is maintained by hand in kprobes.c which is separated from the function definition and is hard to catch up the kernel update. To solve this issue, I've introduced NOKPROBE_SYMBOL() macro for making kprobe blacklist at build time. Since the NOKPROBE_SYMBOL() macros can be placed right after the function is defined (as like as...

Hi, Here is the version 3 of NOKPORBE_SYMBOL series. Currently the blacklist is maintained by hand in kprobes.c which is separated from the function definition and is hard to catch up the kernel update. To solve this issue, I've introduced NOKPROBE_SYMBOL() macro for making kprobe blacklist at build time. Since the NOKPROBE_SYMBOL() macros can be placed right after the function is defined (as like as...

Currently the blacklist is maintained by hand in kprobes.c which is separated from the function definition and is hard to catch up the kernel update. To solve this issue, I've tried to implement new NOKPROBE_SYMBOL() macro for making kprobe blacklist at build time. Since the NOKPROBE_SYMBOL() macros can be placed right after the function is define...

Currently the blacklist is maintained by hand in kprobes.c which is separated from the function definition and is hard to catch up the kernel update. To solve this issue, I've tried to implement new NOKPROBE_SYMBOL() macro for making kprobe blacklist at build time. Since the NOKPROBE_SYMBOL() macros can be placed right after the function is define...

Currently the blacklist is maintained by hand in kprobes.c which is separated from the function definition and is hard to catch up the kernel update. To solve this issue, I've tried to implement new NOKPROBE_SYMBOL() macro for making kprobe blacklist at build time. Since the NOKPROBE_SYMBOL() macros can be placed right after the function is defined...

Currently the blacklist is maintained by hand in kprobes.c which is separated from the function definition and is hard to catch up the kernel update. To solve this issue, I've tried to implement new NOKPROBE_SYMBOL() macro for making kprobe blacklist at build time. Since the NOKPROBE_SYMBOL() macros can be placed right after the function is defined...

...g.uk> Cc: Seiji Aguchi <seiji.aguchi at hds.com> Cc: Peter Zijlstra <peterz at infradead.org> Cc: Frederic Weisbecker <fweisbec at gmail.com> --- arch/x86/kernel/entry_32.S | 33 --------------------------------- arch/x86/kernel/entry_64.S | 20 -------------------- kernel/kprobes.c | 10 +++++----- 3 files changed, 5 insertions(+), 58 deletions(-) diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S index 51e2988..02c2fef 100644 --- a/arch/x86/kernel/entry_32.S +++ b/arch/x86/kernel/entry_32.S @@ -315,10 +315,6 @@ ENTRY(ret_from_kernel_thread)...

Introduce NOKPROBE_SYMBOL() macro which builds a kprobe blacklist in build time. The usage of this macro is similar to the EXPORT_SYMBOL, put the NOKPROBE_SYMBOL(function); just after the function definition. If CONFIG_KPROBES=y, the macro is expanded to the definition of a static data structure of kprobe_blackpoint which is initialized for the function and put the address of the data structure in the "_kprobe_blacklist" section. Since the data structures are not fully initialized by the macro (because there i...

(2013/11/11 20:16), Ingo Molnar wrote: > > * Masami Hiramatsu <masami.hiramatsu.pt at hitachi.com> wrote: > >> Currently the blacklist is maintained by hand in kprobes.c >> which is separated from the function definition and is hard >> to catch up the kernel update. >> To solve this issue, I've tried to implement new >> NOKPROBE_SYMBOL() macro for making kprobe blacklist at >> build time. Since the NOKPROBE_SYMBOL() macros can...

(2013/11/11 20:16), Ingo Molnar wrote: > > * Masami Hiramatsu <masami.hiramatsu.pt at hitachi.com> wrote: > >> Currently the blacklist is maintained by hand in kprobes.c >> which is separated from the function definition and is hard >> to catch up the kernel update. >> To solve this issue, I've tried to implement new >> NOKPROBE_SYMBOL() macro for making kprobe blacklist at >> build time. Since the NOKPROBE_SYMBOL() macros can...

* Masami Hiramatsu <masami.hiramatsu.pt at hitachi.com> wrote: > Currently the blacklist is maintained by hand in kprobes.c > which is separated from the function definition and is hard > to catch up the kernel update. > To solve this issue, I've tried to implement new > NOKPROBE_SYMBOL() macro for making kprobe blacklist at > build time. Since the NOKPROBE_SYMBOL() macros can be placed > right...

...mset > >> - native_load_sp0 and some other native functions (need to be clear) > >> - restore > >> - trace_graph_return > >> - trace_hardirqs_off_thunk, trace_hardirqs_on_thunk > >> - This list still be not perfect. I just enabled/disabled kprobes > >> one by one. There might be combined bugs (combination of several > >> kprobes). > >> - Some of them are hard to specify by NOKPROBE_SYMBOL because they are > >> defined in assembly file. > >> > >> Anyway, to fix all of them, I...

...>> - memcpy, memset >> - native_load_sp0 and some other native functions (need to be clear) >> - restore >> - trace_graph_return >> - trace_hardirqs_off_thunk, trace_hardirqs_on_thunk >> - This list still be not perfect. I just enabled/disabled kprobes >> one by one. There might be combined bugs (combination of several >> kprobes). >> - Some of them are hard to specify by NOKPROBE_SYMBOL because they are >> defined in assembly file. >> >> Anyway, to fix all of them, I think we need file-based blac...

...bit probing on all of such codes > instead of a part of that. > Since some symbols are already registered on kprobe blacklist, > this also removes them from the blacklist. This change only works with x86. On other archs, I get this: kernel/built-in.o: In function `register_kprobe': (.kprobes.text+0x9f4): undefined reference to `__entry_text_start' kernel/built-in.o: In function `register_kprobe': (.kprobes.text+0x9f8): undefined reference to `__entry_text_end' make[1]: *** [vmlinux] Error 1 make: *** [sub-make] Error 2 -- Steve

...>> - memcpy, memset >> - native_load_sp0 and some other native functions (need to be clear) >> - restore >> - trace_graph_return >> - trace_hardirqs_off_thunk, trace_hardirqs_on_thunk >> - This list still be not perfect. I just enabled/disabled kprobes >> one by one. There might be combined bugs (combination of several >> kprobes). >> - Some of them are hard to specify by NOKPROBE_SYMBOL because they are >> defined in assembly file. >> >> Anyway, to fix all of them, I think we need file-based blac...

...bit probing on all of such codes > instead of a part of that. > Since some symbols are already registered on kprobe blacklist, > this also removes them from the blacklist. This change only works with x86. On other archs, I get this: kernel/built-in.o: In function `register_kprobe': (.kprobes.text+0x9f4): undefined reference to `__entry_text_start' kernel/built-in.o: In function `register_kprobe': (.kprobes.text+0x9f8): undefined reference to `__entry_text_end' make[1]: *** [vmlinux] Error 1 make: *** [sub-make] Error 2 -- Steve

...ot be able to be probed. > - memcpy, memset > - native_load_sp0 and some other native functions (need to be clear) > - restore > - trace_graph_return > - trace_hardirqs_off_thunk, trace_hardirqs_on_thunk > - This list still be not perfect. I just enabled/disabled kprobes > one by one. There might be combined bugs (combination of several > kprobes). > - Some of them are hard to specify by NOKPROBE_SYMBOL because they are > defined in assembly file. > > Anyway, to fix all of them, I think we need file-based blacklist > especially f...

masami.hiramatsu.pt wrote: > [...] This series also includes a change which prohibits probing on > the address in .entry.text because the code is used for very > low-level sensitive interrupt/syscall entries. Probing such code may > cause unexpected result (actually most of that area is already in > the kprobe blacklist). So I've decide to prohibit probing all of > them.

masami.hiramatsu.pt wrote: > [...] This series also includes a change which prohibits probing on > the address in .entry.text because the code is used for very > low-level sensitive interrupt/syscall entries. Probing such code may > cause unexpected result (actually most of that area is already in > the kprobe blacklist). So I've decide to prohibit probing all of > them.

...- following functions should not be able to be probed. - memcpy, memset - native_load_sp0 and some other native functions (need to be clear) - restore - trace_graph_return - trace_hardirqs_off_thunk, trace_hardirqs_on_thunk - This list still be not perfect. I just enabled/disabled kprobes one by one. There might be combined bugs (combination of several kprobes). - Some of them are hard to specify by NOKPROBE_SYMBOL because they are defined in assembly file. Anyway, to fix all of them, I think we need file-based blacklist especially for assembler symbols. For example,...