search for: kprobe

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 a...

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 a...

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 defin...

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 defin...

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...

.entry.text is a code area which is used for interrupt/syscall entries, and there are many sensitive codes. Thus, it is better to prohibit 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. Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt at hitachi.com> Cc: Thomas Gleixner <tglx at linutronix.de> Cc: Ingo Molnar <mingo at redhat.com> Cc: "H. Peter Anvin" <hpa at zytor.com> Cc: Ananth N Mavina...

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...

(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 > righ...

...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,...

...>> - 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 bla...

...atsu.pt at hitachi.com> wrote: > .entry.text is a code area which is used for interrupt/syscall > entries, and there are many sensitive codes. > Thus, it is better to prohibit 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'...

...>> - 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 bla...

...atsu.pt at hitachi.com> wrote: > .entry.text is a code area which is used for interrupt/syscall > entries, and there are many sensitive codes. > Thus, it is better to prohibit 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'...

...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...

...ote: > [...] 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. [...] Does this new blacklist cover enough that the kernel now survives a broadly wildcarded perf-probe, e.g. over e.g. all of its kallsyms? - FChE

...ote: > [...] 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. [...] Does this new blacklist cover enough that the kernel now survives a broadly wildcarded perf-probe, e.g. over e.g. all of its kallsyms? - FChE

...- 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...