search for: kprobe_blacklist

Displaying 10 results from an estimated 10 matches for "kprobe_blacklist".

2013 Nov 20
0
[PATCH -tip v3 02/23] kprobes: Introduce NOKPROBE_SYMBOL() macro for blacklist
...ar 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 is no "size" information), those are re-initialized at boot time by using kallsyms. Changes from previous version: - Rename in_nokprobes_functions to within_kprobe_blacklist and it return...
2013 Nov 08
4
[PATCH -tip RFC 0/2] kprobes: introduce NOKPROBE_SYMBOL() and prohibit probing on .entry.text
...r the symbols which is listed in kprobes.c. As we discussed in previous thread, if the gcc accepts to introduce new annotation to store the function address (and size) at somewhere, we can easily move onto that by replacing NOKPROBE_SYMBOL() with nokprobe annotation (and just modifying the populate_kprobe_blacklist() a bit). 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...
2013 Nov 08
4
[PATCH -tip RFC 0/2] kprobes: introduce NOKPROBE_SYMBOL() and prohibit probing on .entry.text
...r the symbols which is listed in kprobes.c. As we discussed in previous thread, if the gcc accepts to introduce new annotation to store the function address (and size) at somewhere, we can easily move onto that by replacing NOKPROBE_SYMBOL() with nokprobe annotation (and just modifying the populate_kprobe_blacklist() a bit). 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...
2013 Nov 20
28
[PATCH -tip v3 00/23] kprobes: introduce NOKPROBE_SYMBOL() and general cleaning of kprobe blacklist
...y in the kprobe blacklist). So I've decide to prohibit probing all of them. Finally, I got an empty .kprobes.text on x86 :) $ grep kprobes_text System.map ffffffff81604980 T __kprobes_text_end ffffffff81604980 T __kprobes_text_start Thank you, Changes from v2 to v3: - Introduce arch_within_kprobe_blacklist() which checks the address is within the .kprobes.text (generic,x86) or .entry.text (x86), for fixing build issue on !x86. - Rename in_nokprobes_functions to within_kprobe_blacklist and it returns a bool value istead of an error. - Fix the type of kprobe_blacklist_seq_stop(). - Use blac...
2013 Nov 20
28
[PATCH -tip v3 00/23] kprobes: introduce NOKPROBE_SYMBOL() and general cleaning of kprobe blacklist
...y in the kprobe blacklist). So I've decide to prohibit probing all of them. Finally, I got an empty .kprobes.text on x86 :) $ grep kprobes_text System.map ffffffff81604980 T __kprobes_text_end ffffffff81604980 T __kprobes_text_start Thank you, Changes from v2 to v3: - Introduce arch_within_kprobe_blacklist() which checks the address is within the .kprobes.text (generic,x86) or .entry.text (x86), for fixing build issue on !x86. - Rename in_nokprobes_functions to within_kprobe_blacklist and it returns a bool value istead of an error. - Fix the type of kprobe_blacklist_seq_stop(). - Use blac...
2013 Nov 15
23
[PATCH -tip RFC v2 00/22] kprobes: introduce NOKPROBE_SYMBOL() and general cleaning of kprobe blacklist
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, it is easy to maintain. This series
2013 Nov 15
23
[PATCH -tip RFC v2 00/22] kprobes: introduce NOKPROBE_SYMBOL() and general cleaning of kprobe blacklist
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, it is easy to maintain. This series
2013 Nov 15
0
[PATCH -tip RFC v2 01/22] kprobes: Prohibit probing on .entry.text code
...et) -/* - * End of kprobes section - */ - .popsection diff --git a/kernel/kprobes.c b/kernel/kprobes.c index a0d367a..ec0dbc7 100644 --- a/kernel/kprobes.c +++ b/kernel/kprobes.c @@ -96,9 +96,6 @@ static raw_spinlock_t *kretprobe_table_lock_ptr(unsigned long hash) static struct kprobe_blackpoint kprobe_blacklist[] = { {"preempt_schedule",}, {"native_get_debugreg",}, - {"irq_entries_start",}, - {"common_interrupt",}, - {"mcount",}, /* mcount can be called from everywhere */ {NULL} /* Terminator */ }; @@ -1328,8 +1325,11 @@ static int __kprobes in...
2013 Nov 27
1
[PATCH -tip v3 02/23] kprobes: Introduce NOKPROBE_SYMBOL() macro for blacklist
...#define __NOKPROBE_SYMBOL(fname) \ > +static struct kprobe_blackpoint __used \ > + _kprobe_bp_##fname = { \ > + .name = #fname, \ > + .start_addr = (unsigned long)fname, \ > + }; \ > +static struct kprobe_blackpoint __used \ > + __attribute__((section("_kprobe_blacklist"))) \ > + *_p_kprobe_bp_##fname = &_kprobe_bp_##fname; 'kprobe_blackpoint' sounds a bit weird - how about 'kprobe_blacklist_entry' ? also, _kprobe_blacklist probably wants to be _kprobes_blacklist, right? Thanks, Ingo
2013 Nov 27
1
[PATCH -tip v3 02/23] kprobes: Introduce NOKPROBE_SYMBOL() macro for blacklist
...#define __NOKPROBE_SYMBOL(fname) \ > +static struct kprobe_blackpoint __used \ > + _kprobe_bp_##fname = { \ > + .name = #fname, \ > + .start_addr = (unsigned long)fname, \ > + }; \ > +static struct kprobe_blackpoint __used \ > + __attribute__((section("_kprobe_blacklist"))) \ > + *_p_kprobe_bp_##fname = &_kprobe_bp_##fname; 'kprobe_blackpoint' sounds a bit weird - how about 'kprobe_blacklist_entry' ? also, _kprobe_blacklist probably wants to be _kprobes_blacklist, right? Thanks, Ingo